Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

UDF breaks NTLDR

- - - - -

  • Please log in to reply
21 replies to this topic

#1
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts
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 by Mexxi, 11 January 2010 - 02:41 PM.



How to remove advertisement from MSFN

#2
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts
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/...pid-902469.html

Another approach to XP32 / XP64 layout
http://www.msfn.org/...vd-t126480.html

A approach to create a sort list file, single boot so far.
mkISO_RAMload_sort.cmd http://www.msfn.org/.../7-t137714.html


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

#3
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts
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 by Mexxi, 11 January 2010 - 06:40 PM.


#4
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts
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....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.

#5
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts

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.techar...ems/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.sevenforu...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:

Posted Image


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 by Mexxi, 12 January 2010 - 12:22 PM.


#6
jaclaz

jaclaz

    The Finder

  • Developers
  • 13,382 posts
  • OS:none specified
  • Country: Country Flag
Actually -iso-level 4 is normally used in 1.x PE's, AFAIK:
http://www.msfn.org/...ofs-t95805.html

jaclaz

P.S.:
And yes, the -R should be a -r ;)

Edited by jaclaz, 12 January 2010 - 12:48 PM.


#7
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts

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.

#8
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts
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 by Mexxi, 12 January 2010 - 03:25 PM.


#9
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts

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.micro...243(WS.10).aspx
http://www.msfn.org/...p...st&p=856888
Does oscdimg support full path only? What about directories and wild cards?

#10
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts

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?

#11
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts
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 :)

#12
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts

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/...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.

#13
jaclaz

jaclaz

    The Finder

  • Developers
  • 13,382 posts
  • OS:none specified
  • Country: Country Flag

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

#14
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts

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

#15
jaclaz

jaclaz

    The Finder

  • Developers
  • 13,382 posts
  • OS:none specified
  • Country: Country Flag

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 :yes: : both nlite and iso level 4 are can then be acquitted on the grounds of not having committed the crime. ;)

jaclaz

#16
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts

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.

Sorry for the confusion. Yes, directories are not sorted themselves.
There are Path Table Records at ISO9660.
ECMA 119 is also approved as ISO9660. http://www.ecma-inte...ds/Ecma-119.htm
6.9.1 Order of Path Table Records request the sort order.
Some hardware rely at this sort order. As far as I know all applications create the Path Table Records to the specification.

I'm used to set a weight at directory level, mkisofs set this level to all files within this directory and all sub directories.
E.g. a weight to I386 includes all files from I386, I386\ASMS\1, I386\ASMS\10 and I386\ASMS\1000
Textmode boot files are sorted in addition.
Example: part of sort.txt by mkISO_RAMload_sort.cmd
./boot.catalog 10000./bootsect.bin 9990./WIN* 9978./AMD64/* 1100./AMD64/SYSTEM32 9000./AMD64/COMPDATA 20./AMD64/LANG 1000./AMD64/WINNTUPG 1000./I386/* 1100./I386/SYSTEM32 9000./I386/COMPDATA 20./I386/LANG 1000./I386/WIN9XMIG 1000./I386/WIN9XUPG 1000./I386/WINNTUPG 1000./DOCS -1000./DOTNETFX -1000./WIN51IP 9899./WIN51IP.SP3 9898./BOOTFONT.BIN 9897./I386/*.SY? 9010add_copy_sort_files -1./I386/_DEFAULT.PI_ 7999./I386/1394.IN_ 7998./I386/1394BUS.SY_ 7997./I386/1394VDBG.IN_ 7996./I386/1394VDBG.SY_ 7995./I386/8514FIX.FO_ 7994./I386/8514OEM.FO_ 7993./I386/8514SYS.FO_ 7992./I386/61883.IN_ 7991./I386/12520437.CP_ 7990./I386/12520850.CP_ 7989add_boot_sort_files -1./I386/SPCMDCON.SYS 9896./I386/TXTSETUP.SIF 9895./I386/BIOSINFO.INF 9894./I386/NTKRNLMP.EX_ 9893./I386/NTOSKRNL.EX_ 9892./I386/BOOTVID.DL_ 9891./I386/SETUPDD.SY_ 9890./I386/SPDDLANG.SY_ 9889./I386/SETUPP.INI 9888./I386/KDCOM.DL_ 9887./I386/SETUPREG.HIV 9886./I386/CTYPE.NL_ 9885./I386/LOCALE.NL_ 9884./I386/L_INTL.NL_ 9883./I386/SORTKEY.NL_ 9882./I386/SORTTBLS.NL_ 9881./I386/UNICODE.NL_ 9880./I386/SETUPLDR.BIN 9600./I386/WINNT.SIF 9599./I386/BOOTFIX.BIN 9598./I386/BOOTFONT.BIN 9597./I386/NTDETECT.COM 9596./I386/SYSTEM32/$OEM$/* 9596./OEM/* 200./$OEM$/* 100./$OEM$/TEXTMODE/* 9950

Just wondering: Did you ever try reading such a disc in Win9x or DOS?

Given a ISO9660:1999 disk:
MS DOS mscdex.exe find 8.0 upper case directory names and 8.3 upper case file names, longer names are not acessible. Basically all DOS files are accessible.
FreeDOS shsucdx does find long ISO9660:1999 names, lower case is possible.
No idea about Win9x.

I hope this won't change in the future.

Well, I hope this too.
Contrary as you indicated already oscdimage with ISO9660, Joliet and UDF is another working approach.
Maybe I'm forced to use this file system mix in future.

#17
jaclaz

jaclaz

    The Finder

  • Developers
  • 13,382 posts
  • OS:none specified
  • Country: Country Flag

MS DOS mscdex.exe find 8.0 upper case directory names and 8.3 upper case file names, longer names are not acessible. Basically all DOS files are accessible.
FreeDOS shsucdx does find long ISO9660:1999 names, lower case is possible.
No idea about Win9x.


I may add:
  • mscdex reads iso-level 3 and partially iso-level 4 as detailed above
  • shsucdx (that can be used under MS-DOS allright) reads iso-level 4 allright
  • NT/2K NTLDR/SETUPLDR.BIN read iso-level 3 but has usually problems with iso-level 4
  • XP SETUPLDR/NTLDR read iso-level 4 allright


jaclaz

#18
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts

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


:lol:



I'm used to set a weight at directory level, mkisofs set this level to all files within this directory and all sub directories.


Interesting method. I once tried sorting with wildcards sicne the documentation said that mkisofs supported that, but it didn't work for me. May be I did it wrong, may be the compile was just buggy. In any case it's nice having seen an example. This should really speed things up for creating sort-files for multi-boot projects.



Contrary as you indicated already oscdimage with ISO9660, Joliet and UDF is another working approach.
Maybe I'm forced to use this file system mix in future.


Well. I don't mind using Joliet. It's pretty efficient for the features it offers, but UDF is just terrible. It created a 35MB TOC for my ISO which had only 15.000 TOC-entries. After having maxed out a DVD-R's capacity this really was a blow. The bad thing about UDF is that it isn't flexible enough. It reserves the same space for meta-information for every file, even if none is available. You'd think that those oh so clever engineers who developed this format would have thought of wasting another few bits to implement flags to signal the length of the following meta-data. This way each entry could have a variable length which would have made UDF quite a good filesystem.


Thanks for the very specific in-depth info on the readability of iso level 4 discs guys :)

Edited by Mexxi, 14 January 2010 - 04:17 PM.


#19
Innocent Devil

Innocent Devil

    Senior Member

  • Members
  • PipPipPipPip
  • 632 posts
i had no problem with doin XP vista multiboot. http://www.msfn.org/...sta-t99823.html

only thing u need a UDF bridge filesystem for Vista/7 and joliet extesions for XP
This command works nicely (i didnt tried mkisofs)
cdimage -lXP_Vista -j1 -u1 -e -m -h -bD:\vista-l\boot\etfsboot.com D:\vista-l d:\xp-vista.iso
note -j1 -u1

Edited by Innocent Devil, 14 January 2010 - 10:24 PM.


#20
cdob

cdob

    Friend of MSFN

  • Members
  • PipPipPipPipPip
  • 951 posts

[*]NT/2K NTLDR/SETUPLDR.BIN read iso-level 3 but has usually problems with iso-level 4

I've different experience:
NT4 SP1 boot sector and setupldr.bin does work at -iso-level 4. The installation does complete.
2000 SP1 boot sector and setupldr.bin does work at -iso-level 4. The installation does complete.

only thing u need a UDF bridge filesystem for Vista/7 and joliet extesions for XP

No, you do NOT need UFD bridge for Windows 7. ISO9660 is sufficient.
Yes, the -j1 -u1 is another solution. However this require addional space.

#21
jaclaz

jaclaz

    The Finder

  • Developers
  • 13,382 posts
  • OS:none specified
  • Country: Country Flag

[*]NT/2K NTLDR/SETUPLDR.BIN read iso-level 3 but has usually problems with iso-level 4

I've different experience:
NT4 SP1 boot sector and setupldr.bin does work at -iso-level 4. The installation does complete.
2000 SP1 boot sector and setupldr.bin does work at -iso-level 4. The installation does complete.


I take for good your report :), maybe it's just NTLDR (and not SETUPLDR.BIN) that has problems or maybe I remembered about SP0, you know how my memory is fading away ;) and it is a bit of time since I experimented.

It can also be that since the NT and 2K install files are "kosher" 8.3 CAPITAL LETTERS, the iso-level on a "plain" install CD does not make any difference, and the problems I seem to remember were on some more multiboot/complex thingies. :unsure:

jaclaz

#22
Mexxi

Mexxi

    Newbie

  • Members
  • 35 posts

This command works nicely (i didnt tried mkisofs)

cdimage -lXP_Vista -j1 -u1 -e -m -h -bD:\vista-l\boot\etfsboot.com D:\vista-l d:\xp-vista.iso
note -j1 -u1


I know, I used that switch too. In fact, I already posted earlier in this thread that CDimage and OSCDimg can create valid UDF-bridges. I can see that you don't use any sort order, which is the most crucial thing when booting more than just a couple of operating systems. I needed to boot 6 entries for example which didn't work with CDimage's native way of sorting files (at least not all of them). Cdimage 2.54 and OSCDimg 2.55 support sort-files but seem to be buggy as building an image takes hours, so mkisofs ftw.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN