Bug#672104: ITP: pv-grub-menu.lst
On Fri, 2012-05-11 at 08:42 +0900, Charles Plessy wrote:
> Le Thu, May 10, 2012 at 02:41:23PM +0100, Ian Campbell a écrit :
> >
> > I've not looked at the tool yet, but I wonder if this might be something
> > which could be usefully maintained as part of the upstream Xen project
> > (of which I'm one maintainer) alongside pygrub.
> >
> > Or is the tool mostly about the Debian integration rather than the
> > generation of a compatible menu.lst?
> >
> > What do you think?
>
> Hello,
>
> that would be great if this facility could be shared in Xen, as it would
> benefit more users than just in Debian.
>
> Currently it looks like the whole scripts are debian-specific. I have
> pushed them in a Git repository on Alioth so that you can browse them.
>
> http://git.debian.org/?p=collab-maint/pv-grub-menu.lst.git;a=tree;f=debian
>
> Among them, update-grub-legacy-ec2 is the one that creates menu.lst. The
> others are Debian-specific hooks for package installation and automatic
> refreshing when a new kernel is installed.
>
> update-grub-legacy-ec2 is derived from update-grub scripts that are also
> Debian-specific.
Right, so this script relies at least partially on Debian specific
naming conventions for files under /boot and similar distro specifics. I
suppose I knew that but hadn't consciously realised it. That needn't
mean we can't take it into upstream Xen but perhaps your first instinct
of trying to maintain it under the Grub package umbrella makes more
sense.
Another option might be to maintain as part of pkg-xen in Debian. If it
went upstream it'd still need to be packaged, and doing that as part of
the pkg-xen effort would probably make sense.
> But if they could be replaced by something more generic, that
> would be great. I guess the next step is to look at how Fedora does...
Not sure about Fedora but IIRC CentOS (AKA RHEL) has "grubby" which is a
C program for updating the menu.lst from kernel postinst hooks.
Can I just check I understand the motivation for this script properly.
There are two ways of setting up the disk for a VM.
The first is the "whole disk" scheme. In this configuration the VM
configuration contains the entire "xvda" which contains a partition
table in the usual way. In this configuration either grub-legacy or
grub-pc can be installed and "grub-install /dev/xvda" does the right
thing including setting up the MBR. This is useful because you can flip
quite easily from PV to HVM just by changing the VM config and
rebooting. (This is the setup I generally use myself, so I'm mostly
familiar with it)
The second scheme is the "split partitions" scheme. In this
configuration the VM config contains "xvda1" and "xvda2" etc which
appear to the guest OS as partitions but critically there is no overall
"xvda" and therefore no partition table. This means that "grub-install"
cannot work. This is the configuration which EC2 etc use and therefore
this update-grub variant is necessary.
Is that right?
I guess the bit I am missing is what is it about the second
configuration (lack of MBR space, "grub-install" fails etc) which means
that the regular "update-grub" script (either grub-legacy or grub-pc)
fails? is it actually a failure in update-grub itself or does it e.g.
make the package installation noisy due to "grub-install" failing?
I guess what I'm getting at is can we fix this by either fixing
update-grub in some way or by changing the packaging so that update-grub
can be available without causing attempts to run grub-install.
(I fully expect the answer to the above is "No" otherwise this script
likely wouldn't exist, I just want to check I understand)
Ian.
--
Ian Campbell
Current Noise: Annihilator - Freed From The Pit (Demo Of "Road To Ruin")
Join the Navy; sail to far-off exotic lands, meet exciting interesting people,
and kill them.
Reply to: