QUOTE (jaclaz @ Jul 15 2008, 01:29 PM)
It may be unrelated, but usually PE .iso don't "like" being "edited", it is much better to re-run the builder and create a new .iso from modified source.
Well, where's the difference in "editing" an ISO (which results in a full re-write of the whole ISO, anyway, because I use ISO commander) and re-building it ?
Since the system boots up fine and shows no other issues except not regarding the migrate.inf or declaring the edited setupreg.hiv as invalid, I don't see any problems with that.
[edit: except ... but see below !]
Try the setdrive app, it is possible that somehow you edited setupreg.hiv in a way that made it corrupted.
I almost did the same, only, since the USB stick is plugged into the same computer, I loaded setupreg.hiv into hklm\setupreg (the name is arbitrary), then created a System\MountedDevices key, and below created the REG_BINARY \DosDevices\U: into which I copy/pasted the binary data contained in the H: entry of the host computer. Then I unloaded the hive to have the file updated.
At least that was my intention - but after loading, I can't access the setupreg path: Cannot open setupreg: Error while opening key. I guess there's some problem with the access rights defined in that hive file - means that somehow, the original setupreg.hiv is corrupted (but readable by the BartPE boot ...) - strange.
Therefore, I performed the same stunt from a running BartPE (with the USB stick connected), and there the hive was accessable. Only, it resulted in the error described.
But I don't give up (yet ...):
I took the setupreg.hiv file from the original BartPE build sources - loads and opens in regedit without any problems. I inserted the U: entry as described before (manually), and to give it a first try, I put it on the Stick for direct boot - YEP !! The stick is now mounted as U:, as I defined (instead of beeing mounted as X: as defined in BartPE). It only messes up some other parts of the installation expecting the stuff hardcoded on X:, but I don't intend to keep it this way, since I don't want the BartPE system drive moved, only the drive letter of the stick's native file system. I also added the signature of my USB HDD as drive V: and if I boot off the HDD, it is moved to V:
Remark: If the bartPE is "directly booted", and the device defined in setupreg.hiv is the same as the one used for booting, it messes up the drive letter defined in BartPE (i.e. moves the BartPE boot drive), since the entry is valid and the BartPE "Direct boot" files reside in the same (native) file system of the stick.
Anyway, I "inserted" it again into the ISO and did a boot: Invalid setupreg.inv, code 14 ! Grmbll !!
The same file, mind ?! It works in native mode, but fails inside an ISO ... !
[... going into heavy brain usage mode for some hours ...]
Considering what you first said about "inserting" stuff into an existing ISO - I did not expect that to happen, but it seems that ISO Commander V1.6 is _CRAP_ for writing back an ISO image (aka "inserting" a file). I simply dumped it and tried the same editing with UltraISO instead, just for the change - YES, IT WORKS NOW
... funny how little details make differences. (yes, I know, I didn't listen to "why don't you re-build the ISO from BartPE sources" ... blame me for that !)
Still, there has been a double error: The initially corrupt setupreg.hiv file (could not access it in regedit), and the ISO creation problem.
Anyway, after the success with the setupreg.hiv file (for which windows gives an error if not readable at startup !), I re-reconsidered the usage of MIGRATE.INF, reversed to the original ISO, inserted the original .INF file into the ISO at \I386\SYSTEM32 with UltraISO - and again, IT WORKS !!
the USB Stick appears as U: and I can see all registry entries which are in the migrate.inf file (the U: and the V: entries)
Several lessons learned here:
- Never trust any ISO-creating software to be compatible with what MS expects if the ISO is mounted as ramdisk ...
- If the migrate.inf is not readable at startup, windooze will not give any error, but simply ignore it !
- And, last but not least, NEVER GIVE UP TO SOON !
- you can combine "direct boot" and "ISO/Ramdisk Boot" on one single media (stick/HDD) !
The presence of a correct winnt.sif in the root (next to ntldr) tells the boot loader whether to load/mount the ISO or use the \I386 directory to start
- \I386 is used for CDROM (read only ?), \minint for disk style (writeable ?) media
- ntldr can be patched to avoid the \minint and rename it into \I386 to allow identical directories in ISO and direct boot.
- The MIGRATE.INF works only for the ISO boot - for direct boot, it has no effect ?!
If that is desired, only setupreg.hiv can be used (pay attention not to conflict with the drive letter X: assigned by BartPE, this might fool any progs expecting X: as BartPE drive)
So, contrary to what was discussed in earlier postings, the result is as follows:For avoiding that any USB stick or drive will mess up the sequence of assigned drive letters in BartPE (and possibly any other PE-based system), use the following procedure:
- Use a existing computer running WinXP
- Connect the drive(s) you want to use to hold the BartPE ISO (USB Stick = UFD, or USB HDD)
- Note the drive letter which is assigned to that drive
- Use MKMIGRATE.CMD drive: to create the MIGRATE.INF
- For several drives, do the same for each device (drive) into a separate migrate.inf, then combine the INF files into one as shown in the example below
- Put the resuting INF into the ISO at \I386\SYSTEM32\MIGRATE.INF
- Use the ISO/Ramdisk boot procedure to load BartPE
contents of my MIGRATE.INF
Signature = "$Windows NT$"
Device U: is the USB Stick signature, V: is the signature of my USB HDD. If another HDD is used, the signature has to be adapted (either in migrate.inf or on the HDD)
Further things to check:
- What happens if a different USB stick is used ? Is any media signature contained in the INF ?
- Include the migrate.inf on a real CD to avoid any USB sticks connected during boot to interfere with the drive letters
- Verify the same for netboot (PXE boot)
So, finally, thanks a lot to cdob and jaclaz for your assistance and patience !
PS: sorry for the detailed post, but I simply hate all forum threads that go like
1) someone's asking a question
2) some expert or enthusiast gives an answer and makes a suggestion
3) the thread dies and is never replied to by the original poster
4) the expert and the public keep wondering whether the solution was useful, or may assume that the dope asking initially killed himself while applying the suggested solution.