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

[Shao Miller]

On 8/6/2011 06:29, Bernd Blaauw wrote:
> Op 6-8-2011 11:43, Shao Miller schreef:
>> Below, attached, and available at the 'ifmemdsk' branch at:
>>
>> http://git.zytor.com/?p=users/sha0/syslinux.git;a=commitdiff;h=a975c12919bbd48739fede4ebfe099d98b87192e 
>>
>>
>>
>> Review welcome!
>
> Interesting. I'll await one of HPA's 4.10 test releases for this 
> unless someone got a binary (.c32) handy somewhere.
> My use case for an inner MEMDISK-loaded ISO would be to either 
> suppress the menu or to start a default entry.

Ok, we've discussed your use case more since this e-mail.

> Slightly offtopic:
> * is CHAIN.C32 working for FreeLDR (trunk) ? Mboot.c32 only partial, 
> due to 'root' requirement.

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

> * is an IsoHybrid image possible with only DOS in it?
> I can imagine the script adding MBR, maybe partition layout, but not 
> bootsector. It would also mean adding a kernel and config file at root 
> of ISO. Think I opened some Isyhybrid file a while ago, WinImage 
> wasn't happy with it at all.

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


On 8/7/2011 19:01, Bernd Blaauw wrote:
> Op 6-8-2011 11:43, Shao Miller schreef:
>> Below, attached, and available at the 'ifmemdsk' branch at:
>>
>> http://git.zytor.com/?p=users/sha0/syslinux.git;a=commitdiff;h=a975c12919bbd48739fede4ebfe099d98b87192e 
>>
>>
>>
>> Review welcome!
>
> I've received a binary and did some short initial tests.
> It appears the detection is based on memdisk itself , rather than 
> which bootloader loaded it or which appended arguments were given. 
> Good enough for me :)

Great!

> Based on my needs (boot diskette image if Memdisk already loaded, 
> otherwise show menu) I'll likely need 2 different config files, as 
> shown below in some semi-syntax. Single config file impossible?

This confuses me.  When MEMDISK is booted, it doesn't return control to 
whatever boot-loader loaded it...  It passes control to the RAM disk; 
either an MBR/boot-sector or an El Torito image.  So when you say "boot 
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.

> (Not showing a menu when MEMDISK detected works fine for ISOLINUX, for 
> PXE-Linux it's probably an entirely different story as no menu was 
> shown before.)

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

> syslinux.cfg:
> com32 ifmemdsk.c32 --mbfts [label 1] -- [label2]
> label 1
> kernel memdisk bootdisk.img
> label 2
> config bigmenu.cfg

That config-file appears to have some errors.  I think you meant:

   DEFAULT check_memdisk
   LABEL check_memdisk
     COM32 ifmemdsk.c32
     APPEND --mbfts label1 -- label2
   LABEL label1
     KERNEL memdisk
     INITRD bootdisk.img
   LABEL label2
     COM32 menu.c32
     APPEND bigmenu.cfg

However, it doesn't appear to make much sense...  When the computer 
first boots and XXX boots and uses this config-file, it'll check for 
MEMDISK, not find one, then boot the "bigmenu" via 'label2'.  Presumably 
the user can choose some option which will boot MEMDISK + some disk 
image.  Presumably you are re-using the above config-file within that 
disk image.  So when that happens, 'ifmemdsk.c32' will _find_ a MEMDISK, 
then take the 'label1' action...  Which appears to boot another MEMDISK?!

> and bigmenu.cfg being my current MENU.C32-using syslinux.cfg
>
> Is there a way to specify alternate options if file doesn't exist or 
> doesn't fit in memory? I guess options 3 and 4 are fallback for both 
> the 'memdisk detected' and the 'no memdisk found' scenario.

There probably are ways to add such features, but that seems like a bit 
of scope creep, to me...  All Syslinux "commands" (modules & directives) 
have the same challenges in regards to missing files and files not 
fitting in memory, but do they offer fall-back choices like you describe?

> com32 ifmemdsk.c32 --mbfts label 1 -- label 2 -- label 3 --label 4
> label 1
> # small bootdisk image, will load always
> kernel memdisk bootdisk.img
>
> label 2
> # Memdisk not found, so MEMDISK-load ISO(provided it exists and fits)
> kernel memdisk iso bootcd.iso
>
> label 3
> # hm the ISO didn't exist, fallback..to same as 1
> # provided memdisk doesn't hang
> kernel memdisk bootdisk.img
>
> label 4
> # hm the ISO didn't fit in memory, fallback..to same as 1
> # provided memdisk doesn't hang
> kernel memdisk bootdisk.img

Oops.  I meant for that snippet to be grouped with the previous one.


On 8/8/2011 16:02, Bernd Blaauw wrote:
> Op 8-8-2011 21:18, Shao Miller schreef:
>> MEMDISKs, not Syslinuces. Since an established MEMDISK might or might
>> not have anything to do with the currently-running Syslinux, why add
>> special-case behaviour that deviates from DOS' mdiskchk.com?
>
> Ah that's a clear example of how complicated things indeed can get. 
> Was just considering a convenience feature, but your 
> argument/explanation is enough to actually don't make the module 
> behave as I suggested.

Ok.

>> I don't completely understand your target scenario (and might've missed
>> some relevant e-mail), but maybe that's not important. Why would an
>> "outer" .ISO have the same config-file as an "inner" .ISO? Suppose you
>> have, in the outer .ISO:
>
> Because I'm generating an (inner) ISO and optionally an outer ISO to 
> enable loading the inner ISO by MEMDISK. It enables freeing up the 
> physical device I'm booting from quite fast (allowing other discs to 
> be inserted or entire device removed).

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.

> Most convenient is copying the inner ISO's isolinux directory to the 
> outer ISO (and storing the inner ISO in that outer ISOLINUX 
> directory). Thus, identical files.
>
>> LABEL test4memdisk
>> COM32 /isolinux/ifmemdsk.c32 --mbfts load_inner -- show_menu
>> LABEL load_inner
>> KERNEL memdisk
>> INITRD inner.iso
>> APPEND iso
>> LABEL show_menu
>> ...
>

This has the same confusing semantics as an earlier e-mail...  If 
'ifmemdsk.c32' _detects_ a MEMDISK as having already been booted, then 
why would it _boot_ a MEMDISK?

> so unde the show_menu label I can put all that's required for MENU.C32 
> including the UI directive? or should I use a 2nd isolinux config file?
> I was under the impression the UI MENU.C32 had to be at start of 
> config file.
> Basicly I'd like to only show a menu once. That's when no MEMDISK/ISO 
> has been loaded yet (by isolinux).

If I was really going to reuse a config-file for "outside" of a MEMDISK 
and "inside" it, I'd use something like:

   DEFAULT check_memdisk
   LABEL check_memdisk
     COM32 ifmemdsk.c32
     APPEND --mbfts found -- establish
   LABEL found
     COM32 menu.c32
     APPEND bigmenu.cfg
   LABEL establish
     KERNEL memdisk
     INITRD inner.iso
     APPEND iso

(I think.)

>>> I'll stick to whatever works though, hopefully including a MBOOT.C32
>>> at some time that is able to set root before chaining :)
>>
>> Ok.
>>
>>> Switching to GRUB/Grub4dos/BURG/GRUB2/GRUB24DOS/BURG2 in either
>>> uncompressed or compressed versions wasn't my intention :)
>>
>> You've lost me. :)
>
> Ha, getting to an offtopic issue (sorry, HPA) as I'm making a boot 
> floppy as well.
>
> Well I'd like to load FREELDR.SYS on floppy, with following requirements:
> [1] FreeLDR loaded from floppy, by Syslinux menu
> [2] FreeLDR loading freeldr.ini config file from floppy, not hdd
> [3] FreeLDR as small as possible
> [4] Standard floppy layout (sector/cluster size)
> [5] Total size of all necessary files as small as possible
>
> * Bootsector way (KERNEL FREELDR.BSS) doesn't meet [3], [4] and [5]
> * CHAIN.C32 way (CHAIN.C32 freeldr=freeldr.sys) same issues
> * MBOOT.C32 way (MBOOT.C32 FREELDR.GZ/SYS) doesn't meet [2] (instead 
> expecting config file on harddisk)
> * GRUB doesn't meet [5] due to itself being a rather huge file
>  (unknown if compressible). See below.
> * MEMDISK FREELDR.IMZ won't complete due to FREELDR being protected
>   mode and not being MEMDISK-aware.

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.

> Size estimations:
> - Bootsector way is 340 KB or so
> - Chain.c32 way around 170KB then (+30KB from chain.c32)
> - Mboot.c32 way is 130KB (compressed freeldr) + 30KB or so
> - GRUB way is 130 (FreeLDR) + 240KB (GRUB) or 120KB (compressed
>   GRUB4DOS..if it runs..).
> - MEMDISK way would be 150KB (130 from FreeLDR, 20 from MEMDISK)
>
> So all in all I'd prefer MBOOT.C32, provided it can set root before 
> loading Multiboot-kernel, so that silly kernel goes looking for its 
> configuration file on the drive it booted from, instead of on the 
> drive it expects the operating system to be)

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?


On 8/10/2011 16:04, Bernd Blaauw wrote:
> Op 6-8-2011 11:43, Shao Miller schreef:
>> Below, attached, and available at the 'ifmemdsk' branch at:
>>
>> http://git.zytor.com/?p=users/sha0/syslinux.git;a=commitdiff;h=a975c12919bbd48739fede4ebfe099d98b87192e 
>>
>>
>>
>> Review welcome!
>
> I'll implement your ifmemdsk module anyway, but just realised I'm 
> kinda being silly for building a small shell around my (inner) ISO.
> A better question therefor is:
> "is it possible to use some memdisk-like module to mirror the boot 
> medium itself to RAM then boot from it?".
>
> a MEMDISK-SELF module, sort of. For anything over 100MB or so this 
> might not be fun though, likely consuming too much time. But it could 
> work for small 'CDs' and 'diskettes' (or anything resembling it).
>
> floppy --> bootsector --> syslinux --> ifmemdsk.c32 --> memdisk-self -->
> (ram-img) --> bs --> syslinux --> ifmemdsk --> "chain.c32 something.bss"
>
> Seeing as the ELTORITO driver finds some kind of ISO9660 bootsector / 
> magic hook, same procedure might work for Isolinux (read/copy blocks 
> till done)
>
> I admit all this stuff is way too realmode/DOS-specific, might thus 
> not be worth general coding time as there's a current option that 
> works (ISO + tiny shell and for low end systems a tiny bootdisk image)

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.

- Shao Miller