jaunty install: formatting root partition changes uuid

[Tony Green]

Binary package hint: ubiquity

Attempting to install Xubuntu Jaunty to replace an existing Kubuntu Intrepid.

Because the install was a total failure (separate bug raised) I had to restore from my backups. However, having done so and attempted to reboot, Grub failed with "error 15 file not found".

After spending a lot of time trying to reinstall Grub and not getting anywhere, I spotted that the UUID of my root partition had been changed by the install process, so not surprisingly, the UUID in menu.lst was incorrect. Editing this file allowed my computer to boot into the restored system.

I would suggest that this shows that changing the UUID of filesystems during installation is an undesirable behaviour.

[PowerUser (i-am-sergey)]

UUID is an UNIQUE identifier by definition, don't you think so? Hence, if you re-format partition it MUST change or UUID will make no sense. That's how it works - by design. Reformatting created DIFFERENT, new unique filesystem. Hence, UUID should get changed as well.

But I have to admit that menu.lst probably should be re-generated with new UUID by installer in such cases and this still could be a bug if installer does not generated boot strings correctly.

[Tony Green (ubuntu-beermad-deactivatedaccount)]

I understand what you're saying (can't honestly say I understand UUIDs or what they're for though...)

In my case, regenerating menu.lst wouldn't have made any difference, because having a failed installation meant that I had to restore it from my dumps, where the installer couldn't (and shouldn't) have touched it.

So really the problem is the use of UUIDs in menu.lst. If that had been pointing at /dev/sda1 or hd(0,0) then restoring after a failed installation wouldn't be a problem.

[Tony Green (ubuntu-beermad-deactivatedaccount)]

Having now read up a bit on UUIDs, it seems to me that if an existing partition is being reformatted, it SHOULD retain the existing UUID. Anything referring to that particular partition by UUID will then still safely be able to find it if necessary. Although at one level a reformatted filesystem might be thought of as new and thus needing a new UUID, at the physical level, it's still the same part of the same disc, so is still the same filesystem, albeit wiped clean.

It makes sense to allocate a new UUID for a newly-created filesystem, but to prevent difficulties after failed installs, pre-existing filesystems ought to retain their original UUID. I note from the man page that tune2fs can be used to set a chosen UUID for a filesystem, so there's no technical reason why this couldn't be done. And then someone in a disastrous situation such as mine could get working again with fewer problems.

[Charlie Kravetz (cjkgeek)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. If you could test the current Ubuntu development version, this would help us a lot. If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect 377613, and any other logs that are relevant for this particular issue.

[Charlie Kravetz (cjkgeek)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Charlie Kravetz (cjkgeek)]

Although the OR did not respond to requests, I am confirming this report. Perhaps we can find a way to revert the UUID if the install fails.

[Phillip Susi (psusi)]

Reformatting means a new UUID. Performing a new install includes installing grub, and generating a new config that will reference the new uuid.