I can verify this bug is present, and will affect anyone upgrading from a instance originally booted with cloud-init older than 0.6.1-0ubuntu6 *and* a natty kernel on EC2. Bug 752361 fixed the issue in newly booted instances.
I tested the following scenarios
A.) started with natty image older than 2011-04-06 (as the bug opener did)
In this scenario, I see a prompt for /etc/default/grub changes. I
selected to accept the maintainer's version.
Then, I was propmted because grub was installed to a disk no longer present.
It showed a list of devices (xvda1). I did not select this and hit 'continue'. Then I said
that grub should continue without installing. (This is OK as grub is not managed inside
EC2 instances). That seemed to work fine.
I also believe that selecting xvda1 in the list would have *also* worked. but I did not try that yet.
I did not see how to get into an endless loop as the opener described.
B.) started with natty image newer than 2011-04-06
I was shown /etc/default/grub modification prompt. That was all.
C.) started with maverick image and do-release-upgrade [-d] to natty.
In this scenario, the upgrade should go OK. The user would then reboot
into the natty kernel, and /dev/sda1 would be renamed to /dev/xvda1. The
next time grub-pc is upgraded, the user may be prompted to address the
missing /dev/sda1. Selecting /dev/xvda1 or selecting to go on without
installing should be OK.
In A and B above, you're shown a prompt for merging /etc/default/grub, and should accept the maintainers version. The differences are either a bug in grub-pc not recognizing older versions of its file, or newer modifications done in the image build process so that user will see a prompt (with a timeout) on first boot of the images.
In C above, you're shown the prompt, this is bug 759545.
I can verify this bug is present, and will affect anyone upgrading from a instance originally booted with cloud-init older than 0.6.1-0ubuntu6 *and* a natty kernel on EC2. Bug 752361 fixed the issue in newly booted instances.
I tested the following scenarios
A.) started with natty image older than 2011-04-06 (as the bug opener did)
In this scenario, I see a prompt for /etc/default/grub changes. I
selected to accept the maintainer's version.
Then, I was propmted because grub was installed to a disk no longer present.
It showed a list of devices (xvda1). I did not select this and hit 'continue'. Then I said
that grub should continue without installing. (This is OK as grub is not managed inside
EC2 instances). That seemed to work fine.
I also believe that selecting xvda1 in the list would have *also* worked. but I did not try that yet.
I did not see how to get into an endless loop as the opener described.
B.) started with natty image newer than 2011-04-06
I was shown /etc/default/grub modification prompt. That was all.
C.) started with maverick image and do-release-upgrade [-d] to natty.
In this scenario, the upgrade should go OK. The user would then reboot
into the natty kernel, and /dev/sda1 would be renamed to /dev/xvda1. The
next time grub-pc is upgraded, the user may be prompted to address the
missing /dev/sda1. Selecting /dev/xvda1 or selecting to go on without
installing should be OK.
In A and B above, you're shown a prompt for merging /etc/default/grub, and should accept the maintainers version. The differences are either a bug in grub-pc not recognizing older versions of its file, or newer modifications done in the image build process so that user will see a prompt (with a timeout) on first boot of the images.
In C above, you're shown the prompt, this is bug 759545.
The relevant cloud-init code can be see at [1] bazaar. launchpad. net/%7Ecloud- init-dev/ cloud-init/ trunk/annotate/ head%3A/ cloudinit/ CloudConfig/ cc_grub_ dpkg.py
--
[1] http://