Re: [Xen-devel] [RFC] bootloader improvements

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel