Re: Installing to NBD

[Joey Hess]

Wouter Verhelst wrote:
> 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.

There is a nobootloader package that can be made to run in preference to
other bootloader installers. This can be enabled by setting
grub-installer/skip, lilo-installer/skip, etc.

> 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.

They all call user-params, which uses debian-installer/add-kernel-opts.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Installing to NBD

[Wouter Verhelst]

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 litt

Re: Installing to NBD

[Lennart Sorensen]

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.

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.
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.

> - 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.

-- 
Len Sorensen


-- 
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/20110629213603.gg7...@caffeine.csclub.uwaterloo.ca

Re: Installing to NBD

[Wouter Verhelst]

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
 

Re: Installing to NBD

[Wouter Verhelst]

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 [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


-- 
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/20110629154912.gf20...@grep.be

Installing to NBD

[Wouter Verhelst]

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 :).
- 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.
- 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?
- 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?

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 [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.

Regards,

[1] http://grep.be/blog/en/computer/debian/d-i/nbd
[2] If you want to try on a different architecture, you'll need to do
the following:
- get 
  and put it in localudebs

- Add

Package: nbd-modules
Depends: kernel-image

  to .../packages/linux-kernel-di--2.6/package-list

- Create a file
  .../packages/linux-kernel.../modules//nbd-modules with as
  contents

#include 

- build the l-k-di package, and put nbd-modules- in localudebs,
  too.

- add partman-nbd to .../installer/build/pkg-lists/monolithic/.cfg

Then, build the monolithic flavour as usual.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


signature.asc
Description: Digital signature