Comment 2 for bug 117084

There are deeper system implications for use case number 3: After cloning a system, the UUIDs of the disk partitions will be different. The partitions might be different: for example the root partition might have been /dev/sda1 on the original machine, but on the cloned machine it might be /dev/sda2. Plus, UUIDs need to be adjusted by this potential new tool both in /etc/fstab, plus in /boot/grub/menu.lst (so that update-grub will do the right thing if the kernel ever gets upgraded in the future by the user). If the UUIDS and partition device names (like /dev/sda1) are not adjusted correctly, the system will probably be rendered unbottable after the next reboot after a new kernel is installed. That is to say, by default, after cloning, the post-install of upgrading the kernel will try to update grub and do a bad job.