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