Re: Installing to NBD
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
Reply to: