Re: Installing to NBD
On Wed, Jun 29, 2011 at 05:36:03PM -0400, Lennart Sorensen wrote:
> 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.
That's grub2, not grub-installer. I'm talking about d-i exclusively
here.
grub-installer will install grub or grub2 if we're on PC, depending on
what makes most sense.
> 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.
Yes, but only if you use a particular kind of filesystem for /boot. If
you don't, then yaboot will need a yaboot-specific filesystem that it
copies the kernel to.
> 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.
It's not necessary to support the full feature set of all boot loaders
with this interface; just the bits that could be relevant to d-i.
> > - 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.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: