Hi, (I seem to be mostly talking to myself here -- anyone awake? ;-)
On Wed, Jun 29, 2011 at 05:49:12PM +0200, Wouter Verhelst wrote: > On Tue, Jun 28, 2011 at 09:29:38PM +0200, Wouter Verhelst wrote: > > - Once the installatoin is complete, the installer will attempt to > > install grub to the local hard disk. If we've installed Debian to a > > network target, this is Wrong(TM); we've not touched the local hard > > disk for the rest of the installation, so I believe the boot loader > > shouldn't do so either. Indeed, if you're installing to an NBD device, > > you might not even *have* a local hard disk. So when the user installs > > to a network device, I believe the installer should default to > > nobootloader, rather than grub, lilo, or whatever boot loader is used > > on the architecture we're using; but if the user still wants to > > install a boot loader anyway, that should probably also be possible. > > Can this be done? If so, how do I do that? Also, note that this > > shouldn't be hardcoded; if we're installing to root-on-NBD we don't > > want to touch the local hard disk, but if we're doing, say, root on > > local hard disk but /usr on NBD, then we /do/ want to install the > > bootloader to the local hard disk. > > This is still an issue, and I'm not sure how to proceed. > > I've been thinking that suggesting to mount /boot on a separate > filesystem (say, NFS or so) could be an option, and that I could then > write a pxelinux.0 and a pxelinux.cfg there. That would only work for > x86*, though. Or I could just unconditionally produce an error if > /target is mounted on an NBD device, so that the user can then choose to > either use the architecture's native boot loader (if that's what they > want), or use nobootloader and figure out how to netboot the thing all > by themselves. > > Input is welcome. So, AIUI, there isn't really a way for me to do this, since all bootloader installers have hardcoded logic to decide they want to run; so if I want to make this work correctly (so that none of the bootloaders will attempt to write to disk by default), I'll have to patch each and every one of them myself. Hrmpf. Also, that other issue: [...] > > - Finally, in order for root-on-NBD to work properly, the kernel needs > > to specify an extra boot parameter that tells the nbd initramfs script > > where the server is. I couldn't find any interface to specify random > > extra kernel parameters for the installed system; did I miss > > something? > > I haven't found how to do this, yet. Anyone? 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. 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. 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. - 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? -- 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/20110629212251.ga14...@grep.be