Installation error on ISO created with ImgBurn.

[Johnhc]

I have created a number of Windows XP x64 Install ISOs with ImgBurn with no problems. A week ago, I burned one to a DVD and about half way through text mode of installing on my new machine I got the message "File cdrom.sys cannot be found". A search of the DVD showed that there were two copies of this file - one in the AMD64 folder and one in the Driver.cab in the AMD64 folder. I then connected the ISO to my VMware Server VM and got the same error when I tried to install it. I accepted all the parameters except for the Character Set. I used ASCII instead of DOS, because I don't want all my file names changed to upper case. I opened a suggestion here. That was where I learned about the ASCII option. I did not report the error last week because I could not repeat the error. Today I can. I hope someone can help with a workaround for this. Right now, I use mkisofs.exe through nLite to create my ISOs and it does not have a problem (it also preserves my file name case, but the label length is severely limited). BTW, is there an easy way to erase an R/W DVD in ImgBurn? Thanks much, John.

Edited October 27, 2009 by Johnhc

[ianymaty]

The easy way to erase a disc is just start burning and ImgBurn will prompt that you should erase the disc prior to burn. Hit OK and it will care the rest.

 

The other way is: In any Mode go to Tools/Drive/Erase Disc

[LIGHTNING UK!]

Does your mkisofs image/disc also use the Joliet file system? ImgBurn would only try to use ISO9660.

 

If the installer wants uppercase and you want lowercase, the only way to do it (so far as I can tell) is to use 2 file systems - but configure the ISO9660 part correctly so it uses the DOS character set.

[Johnhc]

ianymaty, thanks much - missed the Tools path.

 

LIGHTNING UK!, thanks, but I do not know what mkisofs.exe uses. It is an option in nLite (used to make Windows installations). The Default one in nLite started making bad ISOs (missing file/folders) when my source got large (>2.6 GB).

If the installer wants uppercase and you want lowercase, the only way to do it (so far as I can tell) is to use 2 file systems - but configure the ISO9660 part correctly so it uses the DOS character set.

I do not understand what you are suggesting here as far as how I use ImgBurn. What scares me is that some ISOs I create are just fine and others display the 'cdrom.sys missing' message. I do not know what is the reason for this sometime behavior. Thanks, John.

[LIGHTNING UK!]

Open the working image/disc from mkisofs in IsoBuster and see which file systems are listed.

 

You could even open the image/disc in ImgBurn and get the same info.

 

If you add the same source folder into ImgBurn twice, one where you use ALL the recommended settings to create an image and another where you then change the character set to ASCII, does the one using ALL the recommended settings work ok?

[Johnhc]

LIGHTNING UK!, I do not know IsoBuster, but I opened ImgBurn on the failing ImgBurn ISO and it says it is "ISO (Bootable)" , on the mkisofs ISO "ISO (Bootable), Joliet"

If you add the same source folder into ImgBurn twice, one where you use ALL the recommended settings to create an image and another where you then change the character set to ASCII, does the one using ALL the recommended settings work ok?

I have not run this experiment but will. I had to move my source because I needed to make some changes. I will need to create an ISO on the moved folder and see if it fails with ASCII, then try DOS. The reason I have not tried this is because I really don't want all upper case file/folder names but will if it will help to get at the problem. When I started using ImgBurn, I used all the recommended and never had a bad ISO. I will edit this reply when I have some results. Thanks much, John.

 

EDIT: I am unable to recreate the error, even with the copy of folder. This is how evanescent the problem is. I will use ImgBurn for my ISOs and if the error does come back, I will run some experiments. Thanks much.

Edited October 25, 2009 by Johnhc

[Johnhc]

LIGHTNING UK!, I have recreated the problem. I went back to DOS and corrected the problem. I also tried ISO9660+Joliet and ASCII, which gave me the mixed case I wanted but had the 'cannot find cdrom.sys' problem. I have returned to mkisofs to created ISOs. I would much prefer to use ImgBurn, so let me know if you have a suggestion for a work around or experiment you would like me to run. Thanks, John.

[LIGHTNING UK!]

Use ISO9660 + Joliet and the DOS character set. (I did tell you that in post 3!)

[Johnhc]

LIGHTNING UK!, thanks for your reply. I will try ISO9660+Joliet with DOS, but not until tomorrow. I am currently on my new HW.

(I did tell you that in post 3!)

I did see your earlier suggestion, but in my defense, please see my reply in post 4.

I did notice that the label on my DVD was the shorter one (Joliet) not the one I really wanted - correctable? Thanks again - will report my results. Enjoy, John.

[LIGHTNING UK!]

No, Joliet is limited to 16 characters (32 bytes available in the descriptor, divide it by 2 because each character takes 2 bytes and you end up with room for 16 characters) - no 2 ways about it.

 

Your mkisofs discs would have exactly the same problem.

 

The installer is only going to use the ISO9660 file system.

 

Explorer will display the files in the best file system. So if UDF is present it'll use that. If it's not but Joliet is, it'll use that.

 

So in theory, you can get long names and a long volume label by including UDF. It's up to you if you want to include Joliet too. I'm not sure I'd bother personally as ISO9660 + UDF should cover all the bases.

[Johnhc]

LIGHTNING UK!,, I have created an ISO with ISO9660+UDF and DOS. It boots and goes through text mode 'copy files' with no problems. The label is as I desire and the file/folder name case is also. I am making a new source now to install on my HW. I expect it to work OK. Thanks so much for your patient help. I really appreciate it and ImgBurn. I will reply again if I have any further problems. Thanks, John.