mar...@duskware.de (Martin Husemann) writes:
>But the more general solution (which would be just as easy for the end
>user, but more flexibel) is to add support for a rootdev statement
>in boot.cfg and then put the label name or the guid there. Similar
>to evbarm taking a root=dev argument passed from the bootloarder.
You can already specify the root in boot.cfg.
>It would also be cool if boot.cfg could specify the partition to load
>the kernel from via something similiar to NAME=.
You can already specify the disk to load the kernel from with NAME=.
>You insist on this not working for multiboot (which I understand), but I
Multiboot specifies a BIOS drive number and 2 (or 3) partition numbers,
the interpretation of the partition numbers is not really defined
but commonly it's as MBR partition number (1..4 for primary 5+ for extended)
and optionally a BSD disklabel partition number (assuming the primary
partition happens to be identified as *BSD*).
That isn't really flexible or abstract enough or matches the
raidframe scenario and trying to do so (by fixing an interpretation)
is the wrong way to go.
>don't understand how you get this far at all with multiboot. And I think
>multiboot can pass a command line, so root=dev support and make it equivalent
>to the boot.cfg rootdev statement would solve it too.
The multiboot support code in the kernel already interprets the passed
command line, including a "root" option, and this also allows to pass
a wedge name.
There is one caveat. Since all x86 bootloader data is funneled through
the bootinfo structure we have:
struct btinfo_rootdevice {
struct btinfo_common common;
char devname[16];
};
So we have 16 chars to store the identifier (including a NAME= or
wedge: prefix), that's not enough for a UUID.
