Mexxi

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

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

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

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

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. I use the 2005 edition. 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.

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

Thank you for your quick reply. 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. 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. 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.

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?

Thanks for the heads up Jaclaz. I'll make sure to load ERD Commander as an iso next time. I also used mkisof's sort function to get rid of the loading errors. However, my sort list wasn't optimized for boot order so thanks for the links

Hi everybody, I have been multi-booting discs for years and never had many problems. However, my latest project ventured into realms that don't seem to be documented on the internet yet (or I just missed them), so I want to share my experience with you in the hope that it will be useful for people with similar problems. Some of the symptoms I experienced were dealt with online already, yet not successfully and the answers were far from what solved the problems for me. Anyway, here it goes: My plan was to put the following stuff on a disc: - 64bit version of Windows XP Professional - nlited version of above XP - ERD Commander 2005 - Windows 7 x64 - UBCD and other small stuff This was my rough plan of the directory layout: Root\ \AMDFL\ <<< AMD64 of XP full version \AMDLT\ <<< AMD64 of XP lite version \I386\ <<< ERD Commander 2005 \Sources\ <<< Windows 7 installation folder \XPFL\ <<< I386 of XP full version \XPLT\ <<< I386 of XP lite version My bootloader of choice was BCDW 1.5. Getting Win 7, UBCD and all the other small things to boot was no problem at all. Only XP and ERD gave me major headaches. As you know, the x64-versions of XP have two installation folders: I386 and AMD64. To rename them, I hacked setupldr.bin and used the h2060 crack. Nothing new here. However, when I tried to boot either the full XP or the lite version, setup told me that it couldn't find the previous Windows version for the upgrade. This was a full XP version so I was surprised. I tried messing with the WIN51S-files, but that didn't help. I found out pretty soon, that despite the proper renaming of I386 and AMD64 in setupldr, setup was still trying to access the AMD64-folder where it supposedly wanted to read the subdirectories there. I started to update all path references to the old folder names in txtsetup.sif with the new ones, but that didn't help. A file content search revealed that only DOSNET.INF held further path information that might have mislead the setup. Editing the file did nothing, so I assume that a compressed INF-file that is loaded at the beginning needs to be edited. I also wondered why this problem wasn't experienced by the people who tried to rename the source folders of this XP-version. Since mine was rather new, I assumed that Microsoft had changed the setup routine slightly so that newer versions would need an extra edit to work as described in MSFN's tutorial from 2005. My solution was to keep the AMD64-folder of the full XP-version and to rename the I386-folders of both XPs. Doing that fixed the above described error for both setups. Even though my lite XP used a renamed AMD64- folder, I'm pretty sure that it only accessed the folder of the full XP. Anyway, both installations worked flawlessly. This workaround is rather inelegant, because it only worked thanks to both XP-versions being the same. If I had tried to boot several versions of 2003 Server x64 with XP x64 then I'm sure some of the files would have had differed from each other, rendering this method useless. The only way would be to find that hidden path query. As soon as I had this problem figured out, ERD started to act up big time. I had started to boot this one first and it worked, but after adding both XPs and not laying a hand on the ERD-folder, PE wouldn't boot any more. Instead, upon choosing it in BCDW, XPs setup started. As it turns out, ERD 2005 seems to have been built from a x86/x64-hybrid (or Winternal modded it itself). ERD's setupldr contains two references to the AMD64-folder, so thanks to my above workaround, ERD would access this folder every single time and would suddenly turn into an XP-setup (it even worked nicely). I replaced the two references in the bin with "BLANK" and ERD stopped venturing into the forbidden AMD64-folder. Once this problem was dealt with, a new one popped up: ERD complained about "Line 1 of WINPEOEM.INF" not being readable. It turned out that my version of Mkisofs was screwing up ERD's loading mechanism. For testing, I usually used Nero 8 for a quick and dirty compile which I then tested with VirtualBox. Nero's isos worked fine, so when I finally made the move to mkisofs to profit from dupe-removal and other essential goodies a whole batch of new problems started and the inf-reading problem of the ERD Commander was one of them. I experienced "NTLDR not found"-errors just as much as setup freezing while scanning for my hardware and all just because of a different ISO-creator. I also tried CDimage and OSCDimg and while they were able to either make ERD or the XPs run, one of the operating systems stayed broken. It took me half a week to figure out the reason that kept me from finishing this disc: The placement of the files is extremely important, especially if you're dealing with bigger mediums than CDs. In my case, I used a DVD-r. As you can see from my directory layout above, the XP-folders were basically ripped apart. Since all image-makers place files alphabetically, the amd-folders were placed first on the disc, followed by the 3GB directory of Windows 7 and then finally the XP-folders. This placement resulted it a 4GB-gap between the bootloader and the I386-folders of XP. Thanks to that, the boot process just froze (scanning hardware screen) when trying to load NTLDR even though the access time to the iso through VirtualBox was much lower than any time a DVD-drive could have achieved. Anyway, After manually changing the sort order the XP-setups as well as ERD booted fine. This was my file-placement: Root\ \Bootmenu\ \I386\ \XPFL\ \XPLT\ \AMDFL\ \AMDLT\ \other stuff\ \Sources\ This also explains why my isos worked in Nero. Nero refused to load the 2.7GB install.wim of Windows 7, so the files weren't so far spread among the image. I experienced the same phenomenon when I switched to nlite's mkisofs version, which also refused to process this file which resulted in a smaller image with working XPs and ERD. I eventually splitted install.wim just to get rid of this 2GB-problem. As if this hadn't been stressful enough already, I ran into another problem... This time the setup of the full XP complained about not finding files. Not just one or two, but a whole bunch of them. I realized that those were all located in the XPFL-folder (originally I386). Due to my experience with Erd trying to sniff out places where it didn't belong to, I assumed that XP was reading ERD's I386-directory instead of its own. That was rather confusing, because the bootbin jumped to the correct SETUPLDR which in return moved over to the corrent AMD64-folder. It must have been there where the setup went off track. I suppose replacing the I386-path in the txtsetup.sif-folder for the source disks might have done the job, but I went the easy way out by renaming I386 to ERDC and using the now free folder name for XPFL. This corrected my last big problem. One thing worth mentioning is that XP Lite did not try to access the I386-folder, so I assume that some slipstreamed drivers in the full XP-version caused that extra call to I386. This concludes my little story. I had far more problems inbetween, such as the dreaded nlite.exe-error, or syssbck-copy problems, but I stuck to the stuff where I couldn't find much information about. Let me sum up what I learned from this project: - You need to kill the queries in ERD's setupldr to the AMD64-folder (2 queries) - The I386-folders are not allowed to be too far away from the boot.bins, or else the boot-process will freeze while trying to access NTLDR/SETUPLDR - Just renaming all queries in the boot.bin and setupldr might not be enough to route all access to the new folders, so if you encounter a file not found error, then check if the setup is trying to access the original folders. Sorry for the lengthy write up, but if it only helps a single guy not going through all these trial and error steps I had to go through, then it was worth posting it.