Re: Installing to NBD
Hi,
Some updates:
On Tue, Jun 28, 2011 at 09:29:38PM +0200, Wouter Verhelst wrote:
> Hi,
>
> A while back, I blogged about success in installing to an NBD device[1].
> Unfortunately, that was only partial success; that is, while it works
> perfectly well as far as partman is concerned (and therefore also the
> base-installer step), beyond that things go a bit wrong:
>
> - /usr/lib/finish-install.d has 50release-dhcp-lease and 95umount.
> Obviously, if /target is mounted over the network somehow (through
> NBD, but we might have support for installing to, say, NFS or iSCSI in
> the future too, which would run into the same problem), umount (and
> anything that wants to access anything under /target, really) is going
> to fail if there's no network anymore. This obviously means that
> whatever is between priority 50 and 95 that wants to access /target is
> going to fail too.
> I would like to fix this by moving release-dhcp-lease to priority 97,
> so it sits between umount and reboot. Any objections to that? If I
> hear none within the next few days, expect a commit to that effect
> near the end of the week (or sooner if I get a go-ahead :).
I now have a locally patched netcfg that does the above, and it seems to
work. Any objections if I commit?
> - 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.
> - The nbd-client package has an extensive debconf configuration
> interface. Would it be considered good form to programmatically
> preseed the answers to that debconf interface from partman-nbd, or
> should I find another way?
I've done this, and it seems to work; I don't think it's a serious
problem.
> - 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?
> At any rate, if I ignore the hang due to the network going down
> prematuraly, manually make sure the initrd is copied to my tftp server,
> and make sure to enter the correct values in the nbd-client debconf
> interface, the system will correctly boot off NBD to a login prompt, so
> I guess I'm almost there :-)
>
> For those who want to try, I've put an installer image for
> 2.6.39-2-amd64 up on <http://people.debian.org/~wouter/d-i/initrd.gz>[2].
> Note that this is still slightly broken in that it doesn't run
> 'apt-install nbd-client' yet, but I'm working on that.
That is fixed now, too. I've updated my initrd.gz, and beyond the above
issues, it seems to work.
I've moved the source to a git repository, and added it to the .mrconfig
file, so if you run 'mr update' you should get it.
Testing would be very welcome.
(one caveat: poweroff on the installed system won't work properly, due
to an issue with the initscripts package. I have a bug filed, so please
ignore).
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: