UDF breaks NTLDR

[Mexxi]

I'm trying to multiboot a disc with XP and Win7 on it. I realized that whenever I used UDF (plus Joliet and ISO9660) XP would error out with "NTDETECT Failed", but Windows 7 worked. If I leave out UDF and only use Joliet and ISO9660 then XP boots, but Windows 7 complains about not being able to find winload.exe when loading setup. I'm using the latest win32 compile of mkisofs (cdrtools-2.01.01a71) and my commandline is as follows:

mkisofs -follow-links -cache-inodes -volid test -allow-multidot -no-iso-translate -relaxed-filenames -allow-leading-dots -udf -N -l -d -D -joliet-long -no-emul-boot -b bcdwboot.bin -gui -o c:\test.iso -sort FileListsort3.txt c:/final

Is there a switch I'm missing? Also, is there a way to use a less space-hogging way of implementing UDF? Adding UDF wastes a whopping 30MB of mostly empty sectors and I'd like to keep that to a minimum. Can I force XP to ignore UDF and read the ISO/Joliet-part instead?

Edited January 11, 2010 by Mexxi

[cdob]

Yes, setupldr.bin/ntdetect.com dosn't like -udf.

Just croschecked

bin\mkisofs -volid test -allow-multidot -no-iso-translate -relaxed-filenames -allow-leading-dots -N -l -d -D -joliet-long -no-emul-boot -b bootmgr -o test.iso ../W7

Windows 7 does intall fine.

Maybe there is another reason.

I'm using the latest win32 compile of mkisofs (cdrtools-2.01.01a71)

There is a72 ftp://ftp.berlios.de/pub/cdrecord/alpha/

Did you compile the version? Do you use cygwin or mingw32 environment?

-follow-links and -cache-inodes is default enabled since several years at cygwin environemnt.

Isn't winload.exe part of boot.wim? When do you get the missing winload.exe?

Do you sort boot.wim too?

Setupldr.bin access first 4 GB of media. No idea about bootmgr.

What's your final ISO file size?

http://www.msfn.org/board/multiboot-erd-co...pid-902469.html

Another approach to XP32 / XP64 layout

http://www.msfn.org/board/windows-xp-profe...vd-t126480.html

A approach to create a sort list file, single boot so far.

mkISO_RAMload_sort.cmd http://www.msfn.org/board/7-t137714.html

BTW: -iso-level 3 and up support files greater 4GB.

[Mexxi]

Thank you for your quick reply.

There is a72 ftp://ftp.berlios.de/pub/cdrecord/alpha/

Did you compile the version? Do you use cygwin or mingw32 environment?

Unfortunately, I'm not savvy enough to compile my own versions. At least all open source programs I tried had problems compiling. I'm too much of a rookie when it comes to coding to make my own compiles.

I downloaded the a71-version pre-compiled off a webpage. Since it doesn't require cygwin to run I guess it uses mingw32.

Isn't winload.exe part of boot.wim? When do you get the missing winload.exe?

Do you sort boot.wim too?

I can only assume that winload is a part of boot.wim, because the error contains a full path including "windows\system32..." which is not present in the sources-folder.

I get the error about the time, after the initial setup loader of Win 7 has finished loading files for the gui-based setup and just before starting it. I guess at

that time, the loader switches from iso-reading to UDF-reading. This must be a static pre-coded change since the path to the "missing" winload.exe is fully iso9660-compliant.

I never heard about the method of sorting wim-files, so no it's in its original state.

What's your final ISO file size?

4.38GB. Nothing out of the extraordinary. I also made sure that the loaders for the included operating systems are placed at the front part of the disc.

The sorting can't be the culprit since my test with and without UDF uses the exact same commandline with the exact same sort-method.

Thanks for the hint with the 4GB-support. My install.wim is only 2.7GB and I even splitted it to make sure to keep my disc as compliant as possible, so

file size is not the problem.

As a test I switched to CDimage and created a UDF-bridge-based image with its "u1"-switch. UDF-bridge is a mix-format of ISO 9660 and UDF and is used to ensure

compatibility of discs towards older and newer devices. While mkisofs supports specifying certain complexity levels for ISO9660, Joliet and RR, it only supports

UDF-bridge 1.02. According to wikipedia all operating systems from Windows 2000 on need at least UDF 1.50, which luckily is the version that CDimage produces.

I guess that is the reason why mkisofs' UDF breaks WinXP. CDimage's iso is compatible though and allows me to boot XP and Windows 7, but it introduces two

new issues: it doesn't support file sorting and it breaks ERD Commander 2005... I can live without file-sorting. In fact, I already renamed my directories to

resemble the sorting I used with mkisofs sort-switch. I guess for ERD I'll have to switch to RAM-loading. May be this will finally allow me to finish this pain-in-the-

neck project...after a couple more days... It would be so much easier if there was an mkisofs with support for newer UDF...

Thanks for your links. They'll hopefully come in handy when I try to iso-load ERD

Edit: Just checked out cdrtools a72 and the readme mentions nothing about any added UDF-features. This version only offers two minor fixes which are not related

to this problem. May be I should try growiso for a change.

Edited January 12, 2010 by Mexxi

[cdob]

Previously file system ISO9660 and Joliet did work: Windows 7 setup did complete.

Tried again: file system plain ISO9660:

added one big 5GB dummy file, sorted between boot.wim and install.wim.

Install.wim is at end of a 8GB ISO image.

Setup does load boot.wim and finish loading files for the gui-based setup.

Next there is a error message, no DVD drive found, load drivers.

Shift-F10 shows the mounted DVD drive d:

big 5GB dummy file added, sorted at end of media.

Install.wim is after boot.wim, within first 4GB of media.

Windows 7 setup does fully install Windows 7.

Windows 7 setup does not require Joliet or UDF. Plain ISO9660 is sufficient.

Sort order is importand!

4.38GB.

Try create a ISO file below 4GB.

I already renamed my directories to resemble the sorting I used with mkisofs sort-switch.

Be aware: Cdimage sort by directory deep, Win32 ASMS files goes to end of media.

According to wikipedia all operating systems from Windows 2000 on need at least UDF 1.50

Do you have a link?

http://en.wikipedia.org/wiki/Universal_Dis...tive_OS_support

Windows 98 can read UDF 1.02.

Windows 2000 file system driver udfs.sys can read UDF up to 1.50. This includes UDF 1.02.

Windows 2000 udfs.sys can't read UDF 2.0 and up.

A DVD-Video uses UDF 1.02. Windows 2000 can read a UDF at a DVD-Video.

Thanks for your links. They'll hopefully come in handy when I try to iso-load ERD

The firadisk floppy image should work at ERD.

[Mexxi]

Windows 7 setup does not require Joliet or UDF. Plain ISO9660 is sufficient.

Sort order is importand!

Interesting, but you certainly did not use "plain" ISO9660, but rather ISO level 4

and while that might work for Windows 7 it breaks bootability of XP and ERD.

The fact why you couldn't have used the true ISO-standard is because the Win7

installation folder contains files like these:

"microsoft-windows-iis-clientcertificatemappingauthentication-deployment-dl.man"

This file has 74 characters in its name plus a file ending. This goes against any ISO-

standard there is (unless you use level 4). Also, there are tons of forums out there

were people complain about MS requiring UDF to make it bootable:

http://forums.techarena.in/operating-systems/1098166.htm

Quote from that link:

windows vista bootable requires UDF file system & the above command creates the iso image with UDF file system.

Also, in the RC was a readme that said: "This disc contains a "UDF" file system and requires an operating system that supports the ISO-13346 "UDF" file system specification."

http://www.sevenforums.com/installation-se...udf-format.html

May be Microsoft used UDF because it is a standard contrary to ISO level 4. I assume you made this iso with

mkisofs. Did you try to include an XP-setup? Did it boot? Did you check the iso in Isobuster to verify that the iso-maker

in fact only used an ISO-filesystem?

I don't think that the sort order is my problem, because the Win7 setup starts at around 1.5GB which is way below

the 4GB limit. Since my install.wim is split, the very first install.swm is also within the 4GB range, so that's no problem.

Be aware: Cdimage sort by directory deep, Win32 ASMS files goes to end of media.

Thanks for the tip. I realized that when I tried to figure out why ERD wouldn't boot. Although the directory

was the first alphabetically, it was spread all over the disc. OSCimg does the same.

According to wikipedia all operating systems from Windows 2000 on need at least UDF 1.50

Do you have a link?

It was on german wikipedia. Unfortunately I don't have access to the site. For some reason it has been timing out

for the last couple of hours. But I have something better. The built-in help of the latest OSCDimg contains information

about the UDF-support by Windows:

I might have mixed up the version numbers, but on second thought that info doesn't mean much. The question is

which filesystems Windows supports during installation and booting and not after it has been installed, because then

you can support virtually all kinds of filesystems if you have the drivers. I doubt that the udf-driver is loaded during

install to ensure readability of UDF-based discs. The fact remains that mkisofs' UDF 1.02 doesn't work with Windows 7,

while CDimage's and OSCDimg's UDF 1.5 miraculously fix all errors.

The firadisk floppy image should work at ERD.

I checked out the post. I haven't worked with anything else than BCDW yet, except for some meddling with

CDshell that lead me nowhere, so the learning curve for me to get started with grub4dos or other loaders that

support firadisk or other RAM-loading mechanism would be pretty high. I'd like to see that only as a last resort

and would rather get into this method for my next project, unless there was a sure-fire easy-peasy way for dummies

to implement that in a couple of minutes

I would like to use your iso-settings if they also work with with XP/ERD, especially due to the massive overhead that

UDF creates. Could you please test your settings with an XP-install? In one of my attempts I tried to use compliant

ISO for XP and an extended Joliet format for Win 7 and that didn't work, so if ISO Level 4 is incompatible with XP's

setup then UDF should be the only choice left. For further tests I updated OSCDimg

to version 2.55 which finally supports not just UDF much better than mkisofs and also allows to load a sort-

file. I'm currently compiling an iso with it. Speed is painstakingly slow, but if it works then that's all that counts.

Edited January 12, 2010 by Mexxi

[jaclaz]

Actually -iso-level 4 is normally used in 1.x PE's, AFAIK:

http://www.msfn.org/board/create-iso-file-...ofs-t95805.html

jaclaz

P.S.:

And yes, the -R should be a -r

Edited January 12, 2010 by jaclaz

[cdob]

Interesting, but you certainly did not use "plain" ISO9660, but rather ISO level 4 and while that might work for Windows 7 it breaks bootability of XP and ERD.

Well I'm using draft ISO9660:1999 since several years.

There hasn't been a issue so far. I feel free to name draft ISO9660:1999 as plain.

Also, there are tons of forums out there were people complain about MS requiring UDF to make it bootable:

Granted MS uses UDF as default. Maybe most people use this setting too.

Well, I prefer own testings. There is no need for UDF so far.

I assume you made this iso with mkisofs. Did you try to include an XP-setup? Did it boot? Did you check the iso in Isobuster to verify that the iso-maker in fact only used an ISO-filesystem?

NT4, 2000, XP (32bit and 64bit), 2003 and Windows 7 does boot and install from a -iso-level 4 media.

Yes, there is ISO-filesystem only.

Setupldr.bin and bootmgr find uppercased file names at ISO9660 only.

Uppercase required directory and file names.

Bootmgr find lowercase file names at UDF.

I don't think that the sort order is my problem, because the Win7 setup starts at around 1.5GB which is way below the 4GB limit. Since my install.wim is split, the very first install.swm is also within the 4GB range, so that's no problem.

I don't have a explanation. Are both files fully within the 4GB range?

why ERD wouldn't boot

Which ERD do you use at all?

Most likely there is no UDF driver loaded at boot. This may cause a error too, if you use UDF filesystem.

A serupldr.bin ERD does work with -iso-level 4.

The RAM laod approach may get different results.

A 2003 SP1 setupldr.bin based ERD support RAM loading. Add a proper winnt.sif.

Or don't use UDF, but sort required files.

[Mexxi]

Thanks guys for your replies. Since iso-level 4 worked for you I gave it another shot while OSCDimg is still compiling a UDF-based image. Result:

Using iso-level 4 allowed me to start my XP-setup, but I experienced tons of reading errors, because it couldn't find the I386-directory. ERD didn't work any more ("Insert Disc to resume installation of Server 2003"-error). I also have a RAM-loading version with Flyakite's SETUPLDR.RAM trick and it tells me NTLDR DETECT error...

Starting Windows 7 starts Windows XP setup. So basically everything is screwed and nothing works. I made another test-build where I omitted iso-level 4 using only I9660 with relaxed naming conventions and suddenly Windows 7 started properly again. This time without crashing. Thanks to cdob's hint I gave the sort order another look-see. Install2.swm was placed before install.swm. Also some of the dll-files in the root of the source-directory were placed behind these files, so that was the reason for the error. I didn't try the installation yet and aborted it at the edition select screen, so I don't know if it would work flawlessly without iso-level 4, but i'll try it as soon as I find a way to make erd and xp behave correctly again.

Which ERD do you use at all?

I use the 2005 edition.

The RAM laod approach may get different results.

Possibly. It would certainly help stopping OSCDimg and CDimage from cluttering up the OS if you use them without sort-option.

As a side question: Does anyone have experience with OSCDimg's sort option? The program only crawls with this option and even stops working while the command window stays open signaling progress.

Edited January 12, 2010 by Mexxi

[cdob]

Using iso-level 4 allowed me to start my XP-setup, but I experienced tons of reading errors, because it couldn't find the I386-directory.

Do you have lower case names? i386 is not I386

Filecase.exe can uppercase directories and files at hard disk. Create the ISO image next.

-iso-level 4 use this names then.

http://www.stevemiller.net/apps/

Simple approach: uppercase whole \I386\, \BOOT\ and \SOURCES\ and sub directories.

As a side question: Does anyone have experience with OSCDimg's sort option?

Sorry, only open questions.

http://technet.microsoft.com/en-us/library...243(WS.10).aspx

http://www.msfn.org/board/index.php?s=&amp...st&p=856888

Does oscdimg support full path only? What about directories and wild cards?

[Mexxi]

Do you have lower case names? i386 is not I386

Filecase.exe can uppercase directories and files at hard disk. Create the ISO image next.

Everything is uppercase. I already used filecase at the very beginning to avoid this problem. I guess I'll start over with this setup and see if I can make it work.

The strange thing is that I'm using a full XP and an nlited version. The full XP installs fine, the nlited one fails due to not finding the I386-directory. Due to

optimization the files for both versions have the exact same sort order (well they are practically the same files) yet the install fails even though it worked before.

Does oscdimg support full path only? What about directories and wild cards?

In regard to the sort function? Not as far as I know. The help only lists the sort-file as an option and no wildcards.

What specific feature do you have in mind regarding directories?

[Mexxi]

Finally! Everything seems to work now with pure ISO and I'm not even using level 4

The last problems I had were due to massive path changes in sif-files which I hadn't updated

after renaming my folders once more to influence OSCDimg's sort order (the old one that didn't have

that option yet). I just installed Windows 7 successfully and I couldn't be happier

There's only one thing I have to work on. Mkisofs cropped some filenames of some Windows 7

manifest-files. I guess using the level 4 switch should remedy that. Thanks for all your patience cdob

[cdob]

What specific feature do you have in mind regarding directories?

Old habits: basic sort at directory level. Special sort at file level in addition.

The last problems I had were due to massive path changes in sif-files

I prefer to change as less as possible: set SetupSourcePath and BootPath

http://www.msfn.org/board/windows-xp-profe...vd-t126480.html

BootPath Mkisofs cropped some filenames of some Windows 7 manifest-files. I guess using the level 4 switch should remedy that.

ISO9660:1999 allows a path up to 207 chars. Windows 7 default names are within this limit.

If you add custom names longer 207 chars, use UDF.

NT4 and up does read ISO9660:1999. ISO9660:1999 dosn't bite you and won't harm.

[jaclaz]

The strange thing is that I'm using a full XP and an nlited version. The full XP installs fine, the nlited one fails due to not finding the I386-directory.

It is possible that nlite edits a path somewhere (.sif or similar files) using lower case characters.

jaclaz

[Mexxi]

Old habits: basic sort at directory level. Special sort at file level in addition.

I'm not sure if I understand what you mean. Mkisofs places all directories at the beginning of an image and then appends the files according to the specified sort order. You make it sound like there was a way to specify a sort order for directories too, but that wouldn't have much impact.

I prefer to change as less as possible: set SetupSourcePath and BootPath

Same here. May be "massive" was a bit of an exaggeration. I merely replaced I386 with my new folder name. It did help solving some boot errors, so this trick was essential.

ISO9660:1999 allows a path up to 207 chars. Windows 7 default names are within this limit.

If you add custom names longer 207 chars, use UDF.

NT4 and up does read ISO9660:1999. ISO9660:1999 dosn't bite you and won't harm.

Good to know. I hope this won't change in the future. Just wondering: Did you ever try reading such a disc in Win9x or DOS?

It is possible that nlite edits a path somewhere (.sif or similar files) using lower case characters.

Thanks for the hint jaclaz. In this case it was my own fault. I had edited the file and forgot about updating it after changing the folder name

[jaclaz]

Thanks for the hint jaclaz. In this case it was my own fault. I had edited the file and forgot about updating it after changing the folder name

Pheew : both nlite and iso level 4 are can then be acquitted on the grounds of not having committed the crime.

jaclaz