cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Wed, 4 Sep 2013, Haefliger, Juerg wrote:

> All,
>
> OpenStack supports a rescue feature that allows a user to try to fix a
> broken instance. The way it works is that if you engage it, a new
> instance (the rescue instance) is booted using the same Glance image as
> the 'broken' instance and the root disk of the broken instance is
> attached as a second disk to the rescue instance. The problem is that
> both disks have the same filesystem UUIDs (since they're both based off
> the same Glance image) which seems to confuse the guest kernel.
> Sometimes things work as expected and sometimes the two disks are
> swapped.

This generally sounds like broken design.  How could it possibly be
expected to work outside of hard coded 'root=/dev/vda1' on the kernel
command line, which would be busted so many other places.

I wonder if we could fix that broken design.  I haven't spent time
thinking about that, but we shouldn't assume that we have to fix instances
to function according to someones shortsighted design.

> I'm wondering if we should extend cloud-init to change the UUIDs on
> first boot. Obviously we'd have to also change it in all the places
> where it's being used (/etc/fstab, /boot/grub/grub.conf, ...) or the
> instance becomes unbootable (which makes me just a little bit nervous).

This first popped up in bug 665235 (http://pad.lv/665235).

Your suggestion of changing the uuid (and using uuid for boot) doesn't
seem terribly unreasonable, and would solve some cases.

It doesn't solve another case that I've run into where I actually want to
attach the disk twice on first boot.  Once as the boot image, once as just
a data disk.  The use case is for customizing the second disk (similar to
libguestfs would do).  I know this is an odd case, but I'm just throwing
it out there.

Which device to use as root device is a decision made at initramfs time,
combined with kernel command line.


> Comments? Suggestions?

Sorry I dont have easy answers.  I just want to think this trough and i'm
not interested in doing something now that hackily solves a specific
problem.

Scott