Jump to content











Photo

Kon-Boot not working


  • Please log in to reply
8 replies to this topic

#1 ronen

ronen
  • Members
  • 3 posts
  •  
    Israel

Posted 24 January 2011 - 11:00 PM

can you fix Kon-Boot plz?

By the way thanks for the excellent software

#2 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 25 January 2011 - 11:51 AM

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?

#3 ronen

ronen
  • Members
  • 3 posts
  •  
    Israel

Posted 25 January 2011 - 01:01 PM

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.

#4 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1062 posts
  •  
    Belgium

Posted 25 January 2011 - 02:39 PM

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)


#5 surviver

surviver

    Member

  • Members
  • 33 posts

Posted 28 May 2012 - 01:21 PM

I just don't get the point of checkrange in konboot. Well, it looks for the UDF-device-number, but... why :dubbio:
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.


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14758 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 May 2012 - 04:30 PM

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 :ph34r: /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 :thumbsup: 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 :dubbio:) is a "SHIFT" and "circular stack", that might become handy in a number of situations, compare with this:
http://reboot.pro/12449/


:cheers:
Wonko

#7 surviver

surviver

    Member

  • Members
  • 33 posts

Posted 28 May 2012 - 07:36 PM

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...

#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 6935 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 28 May 2012 - 09:24 PM

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 likes this

#9 surviver

surviver

    Member

  • Members
  • 33 posts

Posted 28 May 2012 - 09:48 PM

Very nice... thanks! :fine:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users