The issue with Icecube's approach might be that you will anyway map first disk (first disk without the UFD connected) to (hd0).īOTH will work in all most common setups though let's say conventionally on 99.91% of setups.
#KON BOOT 2.3 USB INSTALL#
The issue with your approach is that since you are "looking" for a bootloader file that may be on different disks, the disk where bootmgr is will alway "prevail" on the one hosting ntldr, thus you might be unable to recover the NT/2K/XP/2003 install (but access the Vista /Server 2008/7 one).
Theoretically the Icecube one's is "better" as it provides an Exchange for the disks, whilst yours re-maps just the "found" disk to (hd0) (and the actual original first disk becomes "nowhereland"). Not really-really (in the sense that BOTH the one posted by Icecube and by you may fail on some particular configuration). Whoops, this post actualy should have been posted here: Hope this is usefull, and someone maybe can verify this. This one is able to konboot proper, no matter which (hdX) the UDF or Windows-device is, and even if Plop was loaded. But please let know if I'm wrong.įind -set-root -ignore-floppies -ignore-cd /bootfiles/konFLOPPY.imgįind -set-root -devices=h /ntldr & map () (hd0)įind -set-root -devices=h /bootmgr & map () (hd0) My method seems way more easy and functional to me.
#KON BOOT 2.3 USB WINDOWS#
What if the Windows device you need to boot is not hd1? - The example above won't work. Well, it looks for the UDF-device-number, but. I just don't get the point of checkrange in konboot.
0 kommentar(er)
