The idea of UUIDs has its problems ...
|
| Author | Content |
|---|---|
| penguinist Sep 02, 2013 5:11 PM EDT |
for example, if you dd clone a partition, you now have two partitions with the identical uuid. Boot scripts and config scripts that are based on UUIDs now become confused. Back in "the day" we used to be able to flexibly move partitions around within one disk or from disk-to-disk, and then just adjust the grub.conf parameters to find the new location of the os we were wanting to boot into. Now with the new scheme of things with grub2 and gpt partitions, a dd'ed partition fails to boot due to UUID mismatches. My solution was to do a full install into the new partition and let the installation work out the details. The moral of this story is that it is now even more important to keep a separate 'home partition' so that os reloads can be done with the least disruption. The unanswered question in my mind is how to do image backups in this grub2/gpt environment if restoring the partition image is not sufficient to get back to a bootable state. |
| djohnston Sep 03, 2013 1:49 AM EDT |
Quoting:for example, if you dd clone a partition, you now have two partitions with the identical uuid. Boot scripts and config scripts that are based on UUIDs now become confused. Well, yeah. If you make a clone, I would hope it would be an exact duplicate. That includes the UUID of the filesystem. The UUID is not applied to the partition, but to the filesystem residing within the partition. You can, however, pass a parameter to the dd command to create a new UUID of the clone during the dd process, if that's what you're after. Or, you can uncomment the #GRUB_DISABLE_LINUX_UUID=true line in the /etc/default/grub file, then run update-grub. As an alternative, you can change the UUID of a restored filesystem after it has been restored. Quoting:Back in "the day" we used to be able to flexibly move partitions around within one disk or from disk-to-disk, and then just adjust the grub.conf parameters to find the new location of the os we were wanting to boot into. Now with the new scheme of things with grub2 and gpt partitions, a dd'ed partition fails to boot due to UUID mismatches. My solution was to do a full install into the new partition and let the installation work out the details. The moral of this story is that it is now even more important to keep a separate 'home partition' so that os reloads can be done with the least disruption. With legacy GRUB, I never really edited grub.conf or used any graphical editors. I just edited the /boot/grub/menu.lst file directly to make any changes. Corresponding changes should be made to /etc/fstab. But, legacy GRUB can also use the newer UUID scheme, depending on what distro you're using and how the boot system is set up. Each boot stanza can be changed to point to a physical partition or to a filesystem LABEL instead of the UUID. And, unless it's a testing installation, I always use a separate partition for the /home directory. I'm not sure from your description what it is you were doing. A new installation, or a restore from a backup? If you are restoring an image to the same partition, you want to keep the UUID the same as before, don't you? Or am I missing something here? |
You cannot post until you login.