Comment 5 for bug 132762

Revision history for this message
Alan Searchwell (searchie) wrote :

Similar problem here, I've got a Windows partition that I rarely boot into, a home partition, a root partition with Gutsy that I've been using all the time and another root partition that had was Hardy, now Intrepid. After installing Intrepid, I got the fsck message during boot:

fsck.ext3: Unable to resolve 'UUID=XXXXX............
fsck died with exit status 8

What's worse is that the failure resulted in no access to my home partition (last in the partition table) when I resumed the boot. The next time I booted into Gutsy I issued "mount /home" at the maintenance shell after the fsck failure. This restored access to my home partition for that session. I then fixed the fstab to reflect the new UUID for my Intrepid partition by using the value supplied by the blkid command and everything returned to normal.

Some comments on Eduardo's proposed solutions:

Allowing installation into an existing ext3 partition without formatting it, while preserving the UUID, will introduce compatibility problems with the upcoming ext4 file system. On the other hand, it prevents errors with GRUB that arise from the ext4 compatibility introduced by formatting ext3 with 256bit i-nodes as opposed to the 128 bit i-nodes used before.

Preserving the UUID during the format process by saving the UUID and writing it back to the partition after formating or seems to be the best solution. Information at this page at https://launchpad.net/ubuntu/+source/partman-basicfilesystems suggests that this has been done for swap partitions. I suspect that in the past this may not have been an issue when installing a new system that uses UUIDs in the fstab alongside a system that used the older style fstab. It seems to me to be a generally bad idea to go changing UUIDs of partitions on a disk that has other operating systems using those UUIDs. Are there instances where changing the UUID would be a good thing?

The third solution would require seeing into the future. Without the knowledge that creating a partition may cause problems in the future, there's no reason not to create it. How is one to know that creating a partition, say for testing purposes, is going to cause problems in the future.

Alan