Mexxi Posted January 11, 2010 Share Posted January 11, 2010 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 stuffThis 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 versionMy 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 withworking 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 slipstreameddrivers 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 hadto go through, then it was worth posting it. Link to comment Share on other sites More sharing options...
jaclaz Posted January 11, 2010 Share Posted January 11, 2010 Maybe it's late, but probably loading the ERD50 as .iso or .img (with grub4dos or memdisk) would have solved you more than a few of the problems.Just in case:http://www.boot-land.net/forums/index.php?showtopic=9740As well, mkisofs.exe allows for a "sort.txt" file where you give a "weight" or priority to files, this is used besides avoiding the "gaps" that may make files needed for booting beyond reach of the bootsector/bootloader, to speed up things (files burned in the same order they are booted).http://www.911cd.net/forums//index.php?sho...20248&st=15http://www.boot-land.net/forums/index.php?showtopic=8049http://www.911cd.net/forums/index.php?show...c=8053&st=2jaclaz Link to comment Share on other sites More sharing options...
Mexxi Posted January 11, 2010 Author Share Posted January 11, 2010 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now