Bug#672104: ITP: pv-grub-menu.lst
On Thu, 2012-05-24 at 09:08 +0900, Charles Plessy wrote: Le Fri, May 11, 2012 at 04:17:39PM +0100, Ian Campbell a écrit : 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? Exactly. When installing Debian on a EC2 volume with Debian Installer, the partition is a whole disk, completely usable by grub. But that means that when the newly prepared Debian system is booted, it is a root partition, which is split partitions in the Amazon cloud and grub hooks will fail when installing a new kernel (I did not have time to triplecheck). So it is whole disk at install time and split partition at run time? Wow! I guess I need to try amazon some time so I can see these quirks for myself... Perhaps that could be solved by making the hooks checking for the availability of a MBR before running grub, but the grub packages are quite critical, and I am not sure how this additional complexity would be welcome. Yes, I can see that being tricky to get right, without regressing the normal cases. In addition there is a second problem. Pv-grub needs a menu.lst file that is made by GRUB 1. Ah, this is a wrinkle I hadn't considered before, I tend to think about pygrub (which can do GRUB 2) and always forget that EC2 uses pvgrub! But Debian's GRUB 1 package is in maintainance-only mode, I do not know what are the plans to remove it eventually, but once GRUB 2 can replace it in all cases, this may happen. So it is probably better to have a menu.lst-builder script for pv-grub maintained somewhere else. The pkg-xen project on Alioth is a good idea indeed. I've CC'd the pkg-xen list, perhaps waldi has an opinion... Or maybe pv-grub could be extended to parse menu.cfg files ? There was mention of a project to turn grub2 into a pv-grub2 at one point, but I'm not sure who that was or what the status is. But I do not know how long it would take for this new function to propagate to Amazon. Indeed. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- Ian Campbell The system will be down for 10 days for preventive maintenance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672104: ITP: pv-grub-menu.lst
Le Fri, May 11, 2012 at 04:17:39PM +0100, Ian Campbell a écrit : 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? Exactly. When installing Debian on a EC2 volume with Debian Installer, the partition is a whole disk, completely usable by grub. But that means that when the newly prepared Debian system is booted, it is a root partition, which is split partitions in the Amazon cloud and grub hooks will fail when installing a new kernel (I did not have time to triplecheck). Perhaps that could be solved by making the hooks checking for the availability of a MBR before running grub, but the grub packages are quite critical, and I am not sure how this additional complexity would be welcome. In addition there is a second problem. Pv-grub needs a menu.lst file that is made by GRUB 1. But Debian's GRUB 1 package is in maintainance-only mode, I do not know what are the plans to remove it eventually, but once GRUB 2 can replace it in all cases, this may happen. So it is probably better to have a menu.lst-builder script for pv-grub maintained somewhere else. The pkg-xen project on Alioth is a good idea indeed. Or maybe pv-grub could be extended to parse menu.cfg files ? But I do not know how long it would take for this new function to propagate to Amazon. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672104: ITP: pv-grub-menu.lst
Hi Charles, 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? Ian. On Thu, 2012-05-10 at 08:41 +0900, Charles Plessy wrote: reassign 672104 wnpp retitle 672104 ITP: pv-grub-menu.lst Dear all, Some systems booted by PV-Grub need a menu.lst file like the one created by grub1, but without GRUB itself on the MBR. Such systems include computer cloud systems like Amazon's Elastic Computer Cloud. Some methods to create such systems do not fit well with installing the grub-legacy package, as there may be no MBR available. In Ubuntu, there is a binary package, called grub-legacy-ec2, that provides kernel hooks and and update script to maintain the menu.lst file when kernels are changed. This package is part of the cloud-init source package, but is unrelated to the upstream cloud-init source. In Debian, cloud-init will be maintained in the Python Applications Packaging Team, and grub-legacy-ec2 does not fit well there, as it is not a python application. After discussion with the Ubuntu maintainer of the cloud-init package, our plan is to provide the functions of grub-legacy-ec2 in a separate source package. I send this ITP with a more generic name that I feel is more descriptive, unless it is only useful on the Amazon EC2. But I am open to keep the original name if it helps. People interested in co-maintaining this package, we welcome you. Currently my plan is to set up a Git repository on collab-maint, with the grub-legacy-ec2 part of Ubuntu's cloud-init source package as a starting point. GRUB Maintainers, I would be happy to place the package under your umbrella if you are intersted. I would like to interface well with grub2, perhaps through depending on grub2-common if possible, in order to be co-installable with grub-pc without diversions. For those who wonder why this ITP is not about bioinformatics, this is part of my long-standing goal of developping a fully debian-contained, preseedable, and unattended procedure to prepare Debian Med images for computer clouds. (see http://charles.plessy.org/Debian/debiâneries/installeur-debian-dans-un-nuage/ ) Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- Ian Campbell Current Noise: Vader - Out Of The Deep Well, I think we should get some bricks and some bats, and show him the *true* meaning of Christmas!' -- Bernice, Designing Women, 12/2/91. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672104: ITP: pv-grub-menu.lst
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. 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... Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672104: ITP: pv-grub-menu.lst
Charles Plessy, le Thu 10 May 2012 08:41:33 +0900, a écrit : I send this ITP with a more generic name that I feel is more descriptive, unless it is only useful on the Amazon EC2. I believe it is useful outside EC2. I would actually use it for my VMs. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
