8 replies to this topic

[ronen]

can you fix Kon-Boot plz?

By the way thanks for the excellent software

[shamurshamur]

Konboot is not supported in XBoot.
As far as i can guess , Konboot should work with Grub4dos ISO emulation, but i have not tested it so can not be sure.

How did you add the Konboot to multiboot USB/ISO.?
what error did you got exactly?

[ronen]

Konboot is not supported in XBoot.
As far as i can guess , Konboot should work with Grub4dos ISO emulation, but i have not tested it so can not be sure.

How did you add the Konboot to multiboot USB/ISO.?
what error did you got exactly?

I added the kon-boot with Grub4dos ISO emulation.

He works until the point that he should get into the system and then he brings me back to USB menu.

[Icecube]

See Me Only's post (#4):
http://reboot.pro/8155/

If your USB stick is seen as hard drive by the BIOS, you need to remap your internal drive to (hd0).
If it is seen as floppy drive, there is no need to remap the internal drive (should be (hd0) already).

title KONBOOT

map --mem /konboot/konboot.img (fd0)

# If current grub4dos root drive (UDF)(stored at 0x8280 in memory) is 0x80 (=hd0), remap (hd0) to (hd1), else do nothing

checkrange 0x80 read 0x8280 && map (hd0) (hd1)

# If current grub4dos root drive (UDF) (stored at 0x8280 in memory) is 0x80 (=hd0), remap (hd1) (=internal hard drive) to (hd0), else do nothing

checkrange 0x80 read 0x8280 && map (hd1) (hd0)

map --hook

chainloader (fd0)+1

rootnoverify (fd0)

[surviver]

I just don't get the point of checkrange in konboot. Well, it looks for the UDF-device-number, but... why
What if the Windows device you need to boot is not hd1? - The example above won't work... will it?

My method seems way more easy and functional to me. But please let know if I'm wrong.
This is my konboot entry:

title Kon-Boot

find --set-root --ignore-floppies --ignore-cd /bootfiles/konFLOPPY.img

map --mem /bootfiles/konFLOPPY.img (fd0)

map --hook

chainloader (fd0)+1

find --set-root --devices=h /ntldr && map () (hd0)

find --set-root --devices=h /bootmgr && map () (hd0)

map --hook

rootnoverify (fd0)

This one is able to konboot proper, no matter which (hdX) the UDF or Windows-device is, and even if Plop was loaded. At least for me.
Hope this is usefull, and someone maybe can verify this.

whoops, this post actualy should have been posted here:
http://reboot.pro/16...ge__hl__konboot

Xboot seems not the correct section. Maybe someone can move this.

Edited by surviver, 28 May 2012 - 01:41 PM.

[Wonko the Sane]

This one is able to konboot proper, no matter which (hdX) the UDF or Windows-device is, and even if Plop was loaded. At least for me.
Hope this is usefull, and someone maybe can verify this.

Not really-really (in the sense that BOTH the one posted by Icecube and by you may fail on some particular configuration).
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").
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).
The issue with Icecube's approach might be that you will anyway map first disk (first disk without the UFD connected) to (hd0).
BOTH will work in all most common setups though let's say conventionally on 99.91% of setups .
BTW IMHO what we still miss (unless I am mistaken and it has been added lately ) is a "SHIFT" and "circular stack", that might become handy in a number of situations, compare with this:
http://reboot.pro/12449/



Wonko

[surviver]

Well, I think a full exchange of the drives can be done like...

title Kon-Boot

find --set-root --ignore-floppies --ignore-cd /bootfiles/konFLOPPY.img

map --mem /bootfiles/konFLOPPY.img (fd0)

map --hook

chainloader (fd0)+1

find --set-root --devices=h /ntldr && map () (hd0) | map (hd0) ()

find --set-root --devices=h /bootmgr && map () (hd0) | map (hd0) ()

map --hook

rootnoverify (fd0)

so nothing gets lost?!
In what I've tried, the 2nd mapping-step seems not needed. Once the OS is booted, all drives are available.
This way I also got the possibility to choose between XP and Vista, in case of both are installed. (Just edit'n delete the "find /bootmgr" line, to boot XP)
Of course you're free to split it into single entries for XP and Vista as well.
I emulated a range of configurations in VMware and tried different physical ones. For me, this works on a wider range.
(Yes not every, on some idiotic cfg it does not, at least not XP)

About your suggested feature... yeh, this may simplify some mapping situations.
I would like also to see something like "find --skip=(hdx)" or --skip-usb-connected. And a map --reset could save the one or other reboot.
So far...

[steve6375]

map reset can be done with this

map --unhook

map --unmap=0:0xff

Sometimes this seems to a take quite a few seconds though (for some reason).

[surviver]

Very nice... thanks!