Comment 3 for bug 106209

Found the cause of the fsck failures:

This is a quad boot system, hda1 Win98, hda2 Dapper, hdb1 Edgy, hdb3 Feisty.

When I re-installed hdb1 Edgy after a failed attempt at installing Xubuntu Feisty ( Feisty ext3 format fails, Edgy's works ), must be the UUID changes? /dev/hdb1 didn't.

Anyway, the /etc/fstab on Feisty still had the UUID from the previous installed Edgy. fstab must use this as an input and of course couldn't find it because it's not there any more, so in booting Feisty fsck fails. The /dev/hdb1 partition is still there but fsck doesn't use that.

Moreover, I had removed the 3rd hard drive to resurrect another system so I'd have more configurations to test new builds.

The Feisty /etc/fstab still had the UUID from the removed drive, so fsck couldn't find that one either.

So I commented out the left over entries in Feisty's /etc/fstab. Booted up fine, no fsck failures.

Do note the Dapper in hda2 didn't have fsck problems with the installs in the 2nd hard drive because the /dev/hdbx's didn't change.
Feisty is going to have a problem every time I install another build in a different partition, since it uses UUID's and not /dev's.

Therefore in a dual or multi boot system, when a new install is done on one of the partitions, the "ordinary desktop computer user" is going to have to know how to manually edit /etc/fstab in the other partitions in order to boot without fsck failures? Is this a Feisty Install Bug or a Feisty Feature?

Cheers, Jerry