Jump to content

Multiboot ERD Commander + XP x64 = an almost neverending story


Mexxi

Recommended Posts

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.

Link to comment
Share on other sites


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=9740

As 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=15

http://www.boot-land.net/forums/index.php?showtopic=8049

http://www.911cd.net/forums/index.php?show...c=8053&st=2

jaclaz

Link to comment
Share on other sites

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...