[gutsy] Don't change UUID of existing ext3 partition when formatting it for install

Hi again, I just wanted to add that if I can help testing any fix you come up with, I'll try my best to do it.

For example, if it's needed I can happily erase Gutsy and Feisty in my machine and reinstall both, to try any fix for the interrupted boot process in Feisty after a Gutsy install (as I said in my bug report above, this is not my main machine).

By the way, the machine is an old Pentium III at 1GHZ, with 384MB RAM and a 9.5GB hard disk. The graphics card is an ATI Radeon 9600XT with 256MB RAM and 2 video outputs, VGA and DVI-I (I found it cheap in a local shop, and it runs Compiz!). Everything so far works in Gutsy, X and Compiz included, and graphics are very smooth.

Thanks again for your efforts, your work is very much appreciated!

If I understand correctly I have a similar but different problem.

I had feisty installed on /dev/sda1. Then I installed gutsy tribe-5 in /dev/sda5. During the installation I removed the existing swap partition and made a new (bigger) one. Then I created a new partition for gutsy and it installed. After reboot it booted gutsy and all was fine.

Then I decided to boot back to my old feisty but I got an error during boot. It looked like grub couldn't find my original feisty anymore (which is on /dev/sda1). It seemed like the uuid of the /dev/sda1 was changed during installation of gutsy. This is not what I expect. I changed my menu.lst (which now is on /dev/sda5 instead of sda1!) to use old-fashioned device names instead of uuids and everything worked again.

I also have this problem.

I have a testing and a stable install of Ubuntu. I have Gutsy installed on most of my HD. It booted up correctly every time. Last night I installed Hardy Alpha 2 onto the testing partition and left all of the Gutsy partitions alone. From then onwards, Gutsy stalls on every boot saying that fsck tried to check the disk with UUID [whatever] and that it failed. One then has to get out of the maintenance shell. I have also lost access to the testing partition since the install of Hardy.

Note that Bug #134763 complains about fsck failing with an error.

I have this problem too, but i am installing on my three partition Gutsy only. First partition is in any case all right, but Gutsy on second partition, after installation Gutsy on third partition, reports "fsck died with exit status 8" (see above).

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

I'm not sure what you mean by "compatibility problems with the upcoming ext4 filesystem". You will get better performance if you remake the filesystem as ext4 from the beginning as opposed to converting an existing ext3 filesystem to ext4, but the latter certainly works. Also, note that that use of a 256-byte inode is not ext4-specific. It's something we started doing in ext3 since it makes a huge difference if your system is using lots of extended attributes, as the Beagle search program and SELinux tends to do. Ext3 has supported storing xattrs in large inodes for quite some time. Unfortunately grub doesn't know how to deal with 256-byte inodes unless it is patched to do so. Ext4's sub-second timestamps and some other features also require 256-byte inode, but ext4 (although with fewer features) on a legacy filesystem with 128-byte inodes.

Theodore, I stand corrected! I got the impression that converting an ext3 partition with 128-byte inodes to ext4 would be extremely challenging if at all possible and the statement reflects that.

Alan

I'm going to have to say no on this. It would be inappropriate to try and pretend a formatted partition is the same as the existing one.