Partition UUID changes after upgrade, cannot mount partitions

[David Osolkowski]

Binary package hint: grub

After upgrading several packages, including the linux kernel image, it appears the UUID of at least the root partition, and possibly others, has been changed automatically. As a result, grub's booting fails and drops to a shell. From this shell, it is not possible to edit /etc/fstab to correct the issue. I have to boot from a live CD to edit /boot/grub/menu.lst and change it to use root=/dev/hdXN devices instead of UUIDs. I know this because I had to figure it out the last time this happened.

From the perspective of an average user, their computer would have been utterly crippled after a simple software update. The fact that total show-stopping bugs such as this make it through not just once, but repeatedly, is indicative of serious issues. Perhaps bug #1 should be resolved as "won't fix."

[Colin Watson (cjwatson)]

Easy on the hyperbole, please - if this were happening to everyone then I might agree with you, but it certainly isn't. The reason we switched to UUIDs was precisely to insulate users from problems caused by devices changing names due to issues beyond our control; it is most unfortunate that that's causing the same problem in reverse in your case.

Could you give us more details about your system? For example, what filesystem is used for /? Could we have copies of 'fdisk -l', /etc/fstab, /boot/grub/menu.lst, /var/log/dpkg.log, and anything else you think may be relevant?

[David Osolkowski (qidydl+launchpad)]

Apologies for the hostility; I've been attempting to get wireless working properly after discovering there are unfixed bugs and issues with the standard tools, trying to work around those and getting stymied, and finally trying to install something else to get somewhere and then getting sacked with this issue, so I was rather frustrated.

It looks like I can only attach one file at a time, so I'll start posting up what I have.

[David Osolkowski (qidydl+launchpad)]

Second file

[David Osolkowski (qidydl+launchpad)]

Third file

[David Osolkowski (qidydl+launchpad)]

Fourth file

This is a backup copy of menu.lst before I changed the invalid UUID entries to /dev/sda1 instead.

[David Osolkowski (qidydl+launchpad)]

Fifth file

[Steve Langasek (vorlon)]

Hi David,

It's noteworthy that in your menu.lst, the "kopt" and "kopt_2_6" options list two different UUIDs. The kopt_2_6 option is the one that's been automatically mapped to the kernel boot options, which is what's expected; what isn't clear is why this is different from the "kopt" value, which is presumably the real UUID of your device, and which also appears in your fstab.

Could you confirm the current UUID of your root filesystem? You can query this with the command:
dumpe2fs -h /dev/sda1 |grep UUID

[Chris Coulson (chrisccoulson)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!