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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
