Re: Installing to NBD
On Wed, Jun 29, 2011 at 11:22:51PM +0200, Wouter Verhelst wrote:
> seems to be pretty much in the same boat, in that each of the bootloader
> installers implements their own logic to come up with a reasonable
> kernel command line.
>
> So if I want to implement this properly, I'll have to patch each and
> every boot loader. I was hoping that that *wouldn't* be necessary.
>
> I believe, however, that this would be a good opportunity to modularize
> bootloader installers a bit. After all, they mostly all do the same
> thing: figure out which kernel to load, load it off the disk somehow,
> come up with a reasonable command line to pass to the kernel, and boot
> it. Whether the boot loader is lilo, uboot, grub, emile, aboot, or
> whathaveyou is just a detail, really. On top of that, having each and
> every boot loader come up with its own way of figuring out what the
> kernel command line should be sounds very much like a bad case of code
> duplication to me, so it might be a good idea regardless.
Grub2 is modular, and I think it is already to a large extent doing what
you suggest. It supports many different system architectures (included
being the complete firmware on some of them) and has modular plugins
for filesystems and various OS kernel types.
uboot supports a lot of architectures, but isn't modular in the same
way as grub2.
> So here's a suggestion for a way in which this could theoretically be
> implemented. It's not very well thought out yet, but I'm hoping it
> should get us in the right direction:
>
> Bootloaders generally exist in two flavours: those who hardcode the
> location of the kernel (either by copying it to a dedicated partition in
> the manner of yaboot, or by hardcoding the blocks on which the kernel is
> stored in the manner of lilo), and those who try to understand the
> filesystem on which the kernel is stored, and read it by reading the
> filesystem metadata.
That's the two common flavours on x86 PCs. I am not sure that is accurate
for other systems. yaboot supports filesystem reads by the way.
Some uboot installs have a hardcoded memory location in flash to load
from, while other uboot installs read filesystems like grub.
> So there should be a way for a bootloader installer to specify things
> like 'I can boot off any filesystem, but the kernel must reside on one
> disk' (lilo), 'I can boot off any filesystem in this list' (grub), 'I
> don't care where the kernel is, I copy it to somewhere else'
> (yaboot/flash-kernel), etc. Similarly, there should be a standardized
> way for the installer to tell the bootloader "this is the command line
> the kernel should receive when booting", "this should be the default
> kernel", etc. It's probably a good idea to do this in a way that it can
> be preseeded, too.
>
> So I'm thinking the following:
> - Add a directory (say, /lib/bootloaders) that signal somehow (through
> flag files) what capabilities the different bootloaders available for
> the current (sub)architecture have available. This way, partman can
> provide warnings to the user if a particular configuration is not
> supported on the current subarchitecture, and main-menu can skip
> configuring a bootloader if it doesn't support the current
> configuration.
Different boot loaders have vastly different feature sets. Some can
only support one kernel at a time (essentially no config) while others
provide the user with a menu and are sometimes even dynamic at supporting
additional kernels and OSs. I don't know how you would make a universal
interface to that.
> - Add a hidden debconf template (say,
> debian-installer/bootloader/arguments) that stores the arguments which
> should be specified to the kernel. Bootloades should use that template
> rather than their own logic. As an added bonus, this could allow a
> user to preseed the kernel command line, should the need arise.
> - Presumably the template may need to be split up to accomodate for
> bootloaders who care about the difference between arguments that
> specify the initrd, arguments that specify the root device (etc), and
> 'other arguments'.
> - Add new udeb (say, "bootloader-support") that contains the generalized
> code to do all of the above, and reduce the bootloader installer
> packages' code to little more than "read data and write boot record".
>
> Thoughts?
Interesting question, but I don't know if it is even theoretically
possible to do it, never mind practical.
--
Len Sorensen
Reply to: