[syslinux] [PATCH] ifmemdsk.c32: Allow boot options based on presence of MEMDISK

[Bernd Blaauw]

Op 10-8-2011 23:27, Shao Miller schreef:
> Ok, we've discussed your use case more since this e-mail.

yep. Warning: only going to respond selectively as you're responding to 
an entire set of conversations :)


> I don't know; haven't tested ReactOS' recently-changed FreeLdr.

I'll try to find time to verify this myself, as floppy booting seems to 
(partially) work again since they switched to Cmake build system.
[ http://www.reactos.org/bugzilla/show_bug.cgi?id=6342 ]

Should chain.c32 work then I can remove the bootsector file for FreeLoader.

> I don't know; haven't really used 'isohybrid'.

Me neither, as simple Windows user.

> diskette image if Memdisk already loaded," do you mean a _second_
> MEMDISK? If we have a program to test for MEMDISK (such as
> 'ifmemdsk.c32'), that means the very MEMDISK(s) it detects has(/have)
> been booted at some point since power-on.

There's no direct way to boot DOS from CD, so emulation mode has to be 
used, either El-Torito direct emulation for floppy or hdd, or Memdisk. 
Choosing for MEMDISK results in a double memdisk indeed.

1:Isolinux -> memdisk (fdboot.img)
2:Isolinux -> memdisk (fdbootcd.iso) -> isolinux -> memdisk (fdboot.img)

(and yes this means the FDBOOT.IMG floppy image is twice on the same 
disk..one time visible as part of outside ISO, another time as part of 
inner ISO).


> Both ISOLINUX and PXELINUX can use [vesa]menu.c32 to provide menus to a
> user. I don't quite follow you, here.

As PXE-booting seems to involve fetching an image anyway, I thought it 
wiser to auto-download the ISO from server to system's memory, boot that 
and only then show the menu.

> Aha. I get it. You can line up 20 computers and swap your only disc from
> one to the next until they've all been booted to a RAM-disk.

It also seems faster to just duplicate a disk to system memory if it's 
not too large (relying on sequential reading), rather than being stuck 
to access times of optical media when installing lots of small files.

> On this last point: Are you suggesting that ReactOS' FreeLdr does not
> use INT 0x13 to access disks? One of the strong points of MEMDISK is
> that it provides an INT 0x13 hook. As far as I know, FreeLdr would have
> to use a full disk driver if it didn't use INT 0x13, but I'm not sure
> that's the case... I could be mistaken.

I'm not entirely sure anymore. My testing got confused by 'freeldr.ini' 
config file not being found, which I assumed the memory device couldn't 
be read. I'll have to verify int13 support again though. It turns out 
Multiboot-booted FreeLDR expects its configuration file in a *different* 
location compared to bootsector-loaded FreeLDR.
the 'root' (or 'rootnoverify') command can fix this, but that's only 
supported in GRUB, not MBOOT.C32.

That's very annoying unfortunately, as a compressed bootloader saves 
quite some diskspace on a floppy(-image). It will do for now though.

> I think getting it working with one or both of 'mboot.c32' and
> 'chain.c32' is possible. What're you trying to boot from FreeLdr? ReactOS?

Yes, that's the main purpose, yet only one of its options. Pressing F8 
shows a lot more use cases though as a general purpose bootloader.
Choking on either the config file or on bootsector isn't much fun.

> Actually, it's a pretty interesting idea to clone the boot disk as a RAM
> disk and then be able to remove the original media. Seems like more of
> something that'd belong as another COMBOOT32 module, though. Essentially
> it could clone the boot disk as the INITRD for MEMDISK, boot the
> MEMDISK, and that'd be that. You're right though... Seems pretty
> DOS[-ish]-centric for usage.

Who knows, some day :)
Already using disc mirroring inside DOS, from
[ http://adoxa.110mb.com/shsucdx/index.html ].
But ofcourse MEMDISK is more fun than adjusting driveletters.

Thanks for an ongoing and interesting discussion.