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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110630051724.ga27...@grep.be