Mailing List Archive

[RFC] bootloader improvements
This is a set of patches we're using to pygrub/bootloading. The aim of
the patchset as a whole is to allow xm/xend to just "do the right thing"
by default, hopefully making it easier to configure, use, and deploy
Solaris and Linux domU's. The patches are:

pygrub-automatic

- Default to using pygrub if there's no kernel and no bootloader
specified.

pygrub-default

- Make pygrub be the "default" bootloader and understand that
keyword.

pygrub-kernel-config
pygrub-no-grub

- The combination of these patches allows pygrub FS code to be
used in a hands-off manner. Note that this can also be used to
fix the problem pygrub currently has with restart, by
specifying the kernel/ramdisk explicitly in the config. The
split between "boot kernel" and "configured kernel" might need
some xen api/lifecycle changes too?

pygrub-solaris

- Solaris domU's will typically never change the kernel/ramdisk
path they use, except if someone's debugging etc. Add some
logic to pygrub so it knows what to do.

All comments welcome.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [RFC] bootloader improvements [ In reply to ]
At 19:20 +0000 on 09 Nov (1163100017), John Levon wrote:
> pygrub-automatic
>
> - Default to using pygrub if there's no kernel and no bootloader
> specified.

Sure, that seems like a good idea. This should be documented in
tools/examples/xmexample* too.

> pygrub-default
>
> - Make pygrub be the "default" bootloader and understand that
> keyword.

I don't understand why this is needed. Why not just not set a
bootloader= option if you want the default?

> pygrub-kernel-config
> pygrub-no-grub
>
> - The combination of these patches allows pygrub FS code to be
> used in a hands-off manner. Note that this can also be used to
> fix the problem pygrub currently has with restart, by
> specifying the kernel/ramdisk explicitly in the config. The
> split between "boot kernel" and "configured kernel" might need
> some xen api/lifecycle changes too?

Hmmm. I like the idea of splitting the bootloader's suggested
kernel/etc from the config file's one, but I don't think the bootloader
should be involved in that at all. I'd rather have Xend be able to make
a decision based on all the information from both sources. This needs
a bit more thought generally.

> pygrub-solaris
>
> - Solaris domU's will typically never change the kernel/ramdisk
> path they use, except if someone's debugging etc. Add some
> logic to pygrub so it knows what to do.

Autodetecting Solaris seems fine, but from that patch it looks like
pygrub will always choose Solaris even if there's a grub menu.lst in the
guest. I'd prefer that to be the other way around: always use the menu
file, even if we think we can see Solaris.

Could this code, instead of just overriding the menu code entirely, just
add another line to the grub menu that contains the default Solaris
config? That way if there's no menu.lst, you get a single-item menu for
Solaris, and even if there is a menu.lst, you still get the choice of a
"vanilla" Solaris boot. Something like:

sol_lines = ["title Default Solaris boot",
"kernel %s %s" % (sol_krnl, sol_args),
"ramdisk /platform/i86pc/boot_archive" ]
sol_img = grub.GrubConf.GrubImage(sol_lines)
g.cf.images.append(sol_img)

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [RFC] bootloader improvements [ In reply to ]
On Fri, Nov 10, 2006 at 11:05:27AM +0000, Tim Deegan wrote:

> > - Make pygrub be the "default" bootloader and understand that
> > keyword.
>
> I don't understand why this is needed. Why not just not set a
> bootloader= option if you want the default?

I don't understand your point. The name and location of 'pygrub' should
be an internal detail unless somebody /wants/ to use a different
bootloader. It's a natural follow-on for the first patch.

> > pygrub-kernel-config
> > pygrub-no-grub
> >
> > - The combination of these patches allows pygrub FS code to be
> > used in a hands-off manner. Note that this can also be used to
> > fix the problem pygrub currently has with restart, by
> > specifying the kernel/ramdisk explicitly in the config. The
> > split between "boot kernel" and "configured kernel" might need
> > some xen api/lifecycle changes too?
>
> Hmmm. I like the idea of splitting the bootloader's suggested
> kernel/etc from the config file's one, but I don't think the bootloader
> should be involved in that at all. I'd rather have Xend be able to make
> a decision based on all the information from both sources. This needs
> a bit more thought generally.

Could you expand a bit more on what you mean here?

> > - Solaris domU's will typically never change the kernel/ramdisk
> > path they use, except if someone's debugging etc. Add some
> > logic to pygrub so it knows what to do.
>
> Autodetecting Solaris seems fine, but from that patch it looks like
> pygrub will always choose Solaris even if there's a grub menu.lst in the
> guest. I'd prefer that to be the other way around: always use the menu
> file, even if we think we can see Solaris.

There /is/ no menu file on Solaris domU.

> Could this code, instead of just overriding the menu code entirely, just
> add another line to the grub menu that contains the default Solaris
> config? That way if there's no menu.lst, you get a single-item menu for
> Solaris, and even if there is a menu.lst, you still get the choice of a
> "vanilla" Solaris boot. Something like:
>
> sol_lines = [."title Default Solaris boot",
> "kernel %s %s" % (sol_krnl, sol_args),
> "ramdisk /platform/i86pc/boot_archive" ]
> sol_img = grub.GrubConf.GrubImage(sol_lines)
> g.cf.images.append(sol_img)

Why? I don't understand why replacing a hands-off method with a load of
interactive gook is a step forward.

regards,
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [RFC] bootloader improvements [ In reply to ]
At 17:25 +0000 on 10 Nov (1163179547), John Levon wrote:
> On Fri, Nov 10, 2006 at 11:05:27AM +0000, Tim Deegan wrote:
> > I don't understand why this is needed. Why not just not set a
> > bootloader= option if you want the default?
>
> I don't understand your point. The name and location of 'pygrub' should
> be an internal detail unless somebody /wants/ to use a different
> bootloader. It's a natural follow-on for the first patch.

Sorry, what I meant was, isn't not setting the bootloader option at all
equivalent to setting it to "default"? If you want to control whether
the bootloader is called at all, there could be two config options, say,
use_bootloader (default 0) and bootloader_path (default wherever pygrub is).

> > Hmmm. I like the idea of splitting the bootloader's suggested
> > kernel/etc from the config file's one, but I don't think the bootloader
> > should be involved in that at all. I'd rather have Xend be able to make
> > a decision based on all the information from both sources. This needs
> > a bit more thought generally.
>
> Could you expand a bit more on what you mean here?

I think that it would be better not to pass the config file options into
pygrub and back out again: pygrub presumably has no business changing
those fields anyway. In future, if pygrub supplies more configuration
options, will we have to add a command-line option for each one so it
can pass the config file versions through? It just seems a bit messy.

Could Xend not just run the bootloader and then, say, fall back to the
values it got from the config file if it doesn't get anything from the
bootloader?

> Why? I don't understand why replacing a hands-off method with a load of
> interactive gook is a step forward.

It would let you dual-boot a linux/Solaris guest. :) It would mean that
if you untarred a Solaris kernel in your linux guest your Grub menu
woudn't just go away forever. It would let you choose a "backup" Solaris
kernel if your main one got toasted. All the usual things a boot menu
is useful for.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [RFC] bootloader improvements [ In reply to ]
On Mon, Nov 13, 2006 at 10:09:01AM +0000, Tim Deegan wrote:

> > > I don't understand why this is needed. Why not just not set a
> > > bootloader= option if you want the default?
> >
> > I don't understand your point. The name and location of 'pygrub' should
> > be an internal detail unless somebody /wants/ to use a different
> > bootloader. It's a natural follow-on for the first patch.
>
> Sorry, what I meant was, isn't not setting the bootloader option at all
> equivalent to setting it to "default"? If you want to control whether
> the bootloader is called at all, there could be two config options, say,
> use_bootloader (default 0) and bootloader_path (default wherever pygrub is).

No, if you specify kernel then it's picked up from the dom0 filesystem.
And I want to avoid having to insist on the bootloader_path at all: the
common case (using pygrub) should just work.

> > > Hmmm. I like the idea of splitting the bootloader's suggested
> > > kernel/etc from the config file's one, but I don't think the bootloader
> > > should be involved in that at all. I'd rather have Xend be able to make
> > > a decision based on all the information from both sources. This needs
> > > a bit more thought generally.
> >
> > Could you expand a bit more on what you mean here?
>
> I think that it would be better not to pass the config file options into
> pygrub and back out again: pygrub presumably has no business changing
> those fields anyway. In future, if pygrub supplies more configuration
> options, will we have to add a command-line option for each one so it
> can pass the config file versions through? It just seems a bit messy.

I agree it's messy. In fact I'd rather like to rework the interface to
read the config from an fd and write it back to another. It's a
requirement to pass the details in, otherwise we cannot say "load me
/this/ kernel". Equally I'd like to split the code up a bit further into
"load this file" code and "run interactive pygrub" code.

> Could Xend not just run the bootloader and then, say, fall back to the
> values it got from the config file if it doesn't get anything from the
> bootloader?

That would enforce interactive usage.

> > Why? I don't understand why replacing a hands-off method with a load of
> > interactive gook is a step forward.
>
> It would let you dual-boot a linux/Solaris guest. :) It would mean that
> if you untarred a Solaris kernel in your linux guest your Grub menu
> woudn't just go away forever.

hmm :)

> It would let you choose a "backup" Solaris kernel if your main one got
> toasted. All the usual things a boot menu is useful for.

Plus all the problems. It's trading the 99.9% case on Solaris ("boot the
kernel you always boot") for the rare exception ("I totally screwed up
my machine", "I'm a Solaris kernel developer running a different
kernel") which can be handled much better via the .py config file.

regards,
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [RFC] bootloader improvements [ In reply to ]
At 13:42 +0000 on 13 Nov (1163425323), John Levon wrote:
> No, if you specify kernel then it's picked up from the dom0 filesystem.
> And I want to avoid having to insist on the bootloader_path at all: the
> common case (using pygrub) should just work.

If we have a use-a-bootloader flag, which defaults to off if a kernel is
specified, and a which-bootloader-should-i-use path, which defaults to
wherever pygrub lives on this system, does that covers all the angles?

I find both the idea of having a "default" keyword at all and the idea
that explicitly requesting the default (!) has side-effects to be
unintuitive.

> I agree it's messy. In fact I'd rather like to rework the interface to
> read the config from an fd and write it back to another. It's a
> requirement to pass the details in, otherwise we cannot say "load me
> /this/ kernel".

Yes, I see. So now I like the pygrub-nogrub patch more. :)
As it stands, passing a kernel= option causes pygrub not to bother
looking for menu options, yes?

> Equally I'd like to split the code up a bit further into
> "load this file" code and "run interactive pygrub" code.

Hmmm. Let me try and untangle what we require now...

1) Receive kernel, args and initrd choices from xm config.
2) Find and parse a GRUB menu.lst in a filesystem image.
3) Automatically detect a Solaris installation in a filesystem image.
4) Let the user choose and modify their boot options.
5) Extract a particular file from a filesystem image for booting.

We should always do all three of 1, 2 and 3: no such thing as too many
options. I would like to see stage 4 available regardless of which of
stages 1, 2 and 3 provide boot options (including none). Letting the
user choose seems like it should always be the right idea.

There's also a question of weighting: if we run non-interactively (or
time out in interactive mode) what should we do by default? My
inclination is to listen to menu.lst first, then autodetected kernels,
and then the config-file-provided kernel.

> Plus all the problems. It's trading the 99.9% case on Solaris ("boot the
> kernel you always boot") for the rare exception ("I totally screwed up
> my machine", "I'm a Solaris kernel developer running a different
> kernel") which can be handled much better via the .py config file.

I have a particular dislike of having to make changes to the xm config
file; as far as I'm concerned, a major goal of having all this
bootloader code is that eventually only "hardware" changes will need to
be made in dom0 and *all* software configuration will be inside the
guest filesystem.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [RFC] bootloader improvements [ In reply to ]
On Mon, Nov 13, 2006 at 06:01:40PM +0000, Tim Deegan wrote:

> > No, if you specify kernel then it's picked up from the dom0 filesystem.
> > And I want to avoid having to insist on the bootloader_path at all: the
> > common case (using pygrub) should just work.
>
> If we have a use-a-bootloader flag, which defaults to off if a kernel is
> specified, and a which-bootloader-should-i-use path, which defaults to
> wherever pygrub lives on this system, does that covers all the angles?
>
> I find both the idea of having a "default" keyword at all and the idea
> that explicitly requesting the default (!) has side-effects to be
> unintuitive.

Hrm. I'd be OK with a use_bootloader {true,false} and a follow-on
bootload_path, yes. But this would break compatibility for .py scripts,
no? They've already broken (a little) in 3.0.3 so I'm not sure if this
is a concern.

> > I agree it's messy. In fact I'd rather like to rework the interface to
> > read the config from an fd and write it back to another. It's a
> > requirement to pass the details in, otherwise we cannot say "load me
> > /this/ kernel".
>
> Yes, I see. So now I like the pygrub-nogrub patch more. :)
> As it stands, passing a kernel= option causes pygrub not to bother
> looking for menu options, yes?

Correct.

> > Equally I'd like to split the code up a bit further into
> > "load this file" code and "run interactive pygrub" code.
>
> Hmmm. Let me try and untangle what we require now...
>
> 1) Receive kernel, args and initrd choices from xm config.
> 2) Find and parse a GRUB menu.lst in a filesystem image.
> 3) Automatically detect a Solaris installation in a filesystem image.
> 4) Let the user choose and modify their boot options.
> 5) Extract a particular file from a filesystem image for booting.
>
> We should always do all three of 1, 2 and 3: no such thing as too many
> options.

I'm not sure why we'd do 2) if 3) succeeds. What action would you like
to result?

> I would like to see stage 4 available regardless of which of
> stages 1, 2 and 3 provide boot options (including none). Letting the
> user choose seems like it should always be the right idea.

If I've specified stuff in my .py file it seems at the least intrusive
to then ask me to confirm them.

> There's also a question of weighting: if we run non-interactively (or
> time out in interactive mode) what should we do by default? My
> inclination is to listen to menu.lst first, then autodetected kernels,
> and then the config-file-provided kernel.

This seems exactly backwards to me. In normal operation, nobody will
provide parameters in the .py file, letting either interactive boot or
the defaults happen. So when they /do/, we should apply it.

I'd also like to avoid having to parse menu.lst if we autodetect: the
parser is rather brittle, and it's pointless for the only case we
autodetect right now (Solaris).

> > Plus all the problems. It's trading the 99.9% case on Solaris ("boot the
> > kernel you always boot") for the rare exception ("I totally screwed up
> > my machine", "I'm a Solaris kernel developer running a different
> > kernel") which can be handled much better via the .py config file.
>
> I have a particular dislike of having to make changes to the xm config
> file; as far as I'm concerned, a major goal of having all this
> bootloader code is that eventually only "hardware" changes will need to
> be made in dom0 and *all* software configuration will be inside the
> guest filesystem.

Understandable; it's worth noting that these changes actually /reduce/
the need for this except in development/recovery scenarios. The fact
that there's no real possibility of sane interaction between 'xm reboot'
and pygrub interactive /without/ having the config override menu.lst is
a pretty strong argument for my approach too. (Edit a line in pygrub and
boot with that: on reboot, you can either choose the default in menu.lst
(your priority order), or re-use what was specified (mine)).

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel