Comment 19 for bug 106209

I'm installing Tribe 6 into partition 1 of a three boot system. Another partition has a running Tribe 5 in case Tribe 6 has a problem, and also has master copy of saved files.

UUID culprits: Install to a partition requires formatting that partition. Format changes the UUID, example Gutsy Tribe 6 install into sda1 of a three boot system:
Before install
/dev/sda1: UUID="9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1" SEC_TYPE="ext2" TYPE="ext3"
After install
/dev/sda1: UUID="f23f7c06-5228-4b6e-8103-0adbc524f920" SEC_TYPE="ext2" TYPE="ext3"

Further muddying the water, Install puts the UUID's of all three partitions in fstab.

Now when I go back to boot the Tribe 5 in the other partition, boot fails because its fsck tries to do a file systems check on a UUID that no longer exists.

Now Install is smart enough to recognize another Ubuntu and wants to know if I want to model things from it, like bookmarks. Why isn't it smart enough to know the fstab in the other Ubuntu is going to be wrong now, since it points to the old UUID not the new UUID that Install just created?

Where in the Ubuntu instructions or in Install does it then say, "formatting this partition changes the UUID so you have to manually edit any other fstab's to match, otherwise the other Ubuntu stops when it is booted"?

By the way, multi boot is the way to go, when trying out new distro's or new builds so there is an old partition that works in case the new one doesn't. Example on this system Tribes 1 & 2 did, Tribe 4 wouldn't install and botched up the partition, but I had a partition with Tribe 2 to fall back on.

Jerry