Well, I’ve been using Kubuntu for a while now (switched from Ubuntu because I couldn’t stand GNOME any more), and I decided this past weekend that I no longer need to keep my Mepis partition lying around. The “Feisty Fawn” version of Kubuntu is super stable for all of my needs. So what to do with that other partition? Well, the “Gutsy Gibbon” version is due out soon, so why not download the latest “tribe” of that and do some bug hunting? And, I figured, I will also get the 64-bit version, to see how progress is coming in the 64-bit world (still needs work, thanks to laggards like Adobe).
But that’s not what I came here to talk about. What I came here to talk about is the crazy way Ubuntu mounts devices. If you’re Joe Average User, I think you can stop reading now, because this is going into the command line and looking at the way Ubuntu “just works” (and sometimes doesn’t).
Ubuntu mounts devices with something called UUID. I’d never heard of it before, but it “just worked”, so I left it alone. Here is an example of a UUID line in fstab:
UUID=8e4da29d-dc80-4c76-bcb9-50014e1929dc none swap sw 0 0
Crystal clear, right? I mean, anybody can tell which device 8e4da29d-dc80-4c76-bcb9-50014e1929dc is… No? Well neither could I. But it wasn’t a problem. Until I installed Gutsy Tribe 5 on my other partition. Gutsy decided that it needed to format my swap partition for some odd reason. Formatting it, apparently, gives it a new UUID. So Gutsy “just worked”, but when I tried to reboot and load up my Feisty desktop again, it no longer worked. I had an fscheck error on /dev/hdb5 (a shared media partition which was not formatted during the Gutsy install), and swap would not mount at all. Neither of these problems were fatal. I could still boot, but having no swap drive will get painful after a while. So what to do? First option: “the Windows solution”. I rebooted. Same errors. That’s fine. Doing a reboot shouldn’t fix anything. Next option? I remember seeing the UUID mounting entries in fstab. I don’t like things I don’t understand, so I decided to convert the UUID line for “swap” that you see above into something more sane, and recognizable to any Linux admin:
/dev/hda2 none swap sw 0 0
While I was at it, I also converted every other UUID entry. I rebooted, to see if the system boot would work properly after this change. It did. Not even an fscheck error on hdb5. UUID is crap. Why does Ubuntu use UUID, then? I had it explained to me.
UUID is cool when using removable peripherals, so they will always mount where you want it to mount.
Still, I think that’s going to be a minority of users that will benefit by it. I think Ubuntu made a bad choice to go with this by default. But I could be wrong. Desktop systems are going the way of the dinosaur, and I can see that UUID would probably fit a laptop better, seeing as how things are getting plugged and unplugged constantly.
Comments
Actually, the UUID thing was instituted so that users wouldn’t have to manually edit the fstab when the new kernel drivers that changed hda’s to sda’s were activated.
Try typing ls -l /dev/disk/by-uuid at a command line….
I think a simpler solution would have been a script to go through fstab with a regex and make the changes. Something along the lines of s/\/dev\/hd/\/dev\/sd/g
Correct me if I’m wrong, but UUID is going to cause problems with any user trying to restore a backup to a new or reformatted drive. HDA crashes hard and permanent like, so I buy a new HDA and restore my root partition, but fstab will fail to mount anything (including root) that existed on that old drive.
I got rid of UUID from my fstabs. I first hit the Swap disappearing problem with SuSE. I also hit problems with backup partitions (partimage) that created two partitions both with the same UUID and a mess. UUID also makes for long messy lines in fstab. What was wrong with /dev/sda5? For me, a home user, I’ve seen nothing but problems with UUID. Nothing good.
Another way to do it would be to use the LABEL dev node, or LABEL=
ls -l /dev/disk/by-label/
/dev/disk/by-label/BOOT /boot ext2
/dev/disk/by-label/BOOT none sw
or
LABEL=BOOT /boot ext2
LABEL=SWAP none sw
The labels can be set with e2label for ext partitions or mkswap -L /dev/ for the swap.
I don’t use Ubuntu myself, but I’m guessing that you get to mount your extra partitions to where you want during the install, in which case it could set the label to the last part of the path you gave it (e.g. /mnt/music would get the label ‘music’) or let you name them yourself.
Thank God, I found this page…
Guys I need instructions as I am a newbie. I have come across with the UUID problem twice. 2 in Feisty (stable release) and on in Gutsy (BETA). Although I keep a backup I WASNT able to restore since the UUID changes everytime… Three installations are too many…and beeing able to use the backup.
Well if i got it right,
what I need to do is to
sudo kwrite /etc/fstab/
and change every strange symbol with smg like
/dev/sda6 (my linux boot)
/dev/sda5 (swap)
/dev/sd7 (my /home partition)
pls let me know, I cant stand another format.
What will happen with my external usb HD? Do you believe this is the reason for getting this error? (e.g when I unplug the HD from the PC)
P.S I’m using a Sony Vaio SZ3xp, dual boot (and i’m trying to get rid off MS Win.)
Yes, that’s basically what you need to do. On my Fiesty fstab, where I made this change, each UUID line was preceeded (fortunately) by a comment line giving the /dev name. Change all the UUID to the designated /dev and you should be golden. As always, back up fstab before making changes, even if things currently aren’t working, it’s nice to be able to return to the original broken state if the fix doesn’t work.
I don’t use an external HD, so I can’t really comment on that. I doubt it’s the cause of the error, though, since according to “admiralchicago”, external drives are the raison d’etre for UUID.
Good luck with this fix, and good luck getting rid of MS!
Hi thnx for the reply,
I’ve got another question, shouldn’t we change the UUID in /boot/grub/menu.st
and in /initramfs-tools/config.d/resume?
What happens if we dont?
Yes, if you have problems with your boot/root partitions, you definitely need to change the UUID entries in /boot/grub/menu.lst or your system will fail to boot.
I’ve never dealt with /etc/initramfs-tools/config.d/resume before in my life. Resume sounds like something that might be called when coming out of hibernation on a laptop? At any rate, you will need to fix or eradicate ALL instances of UUID when the UUID of your partitions changes. Quite a pain in the arse, eh? I guess I got lucky that only my swap and /home/wolfger/shared partitions were affected, or I may not have figured it all out. Now more than ever I feel that Ubuntu should drop this abomination. Or, at the very least, find some way to make it easy to fix (without a reinstall) when a UUID changes.
I have this problem when cloning a Ubuntu drive with Acronis and installing it in another computer. Strangely enough the UUID doesn’t bother the boot process, but the swap partition is not found. I have found problems in relabeling this as /dev/sda5, as /proc identifies it as /dev/hda5.
Obviously a utility for re-recognising the UUIDs and modifying any system files like fstab and menu.1st would be good. The process happens normally during install so it should not be difficult for a clever person to extract the relevant code and write a tool for us.
Another area with cloning seems to be when mounting removeable floppy media. The media is there, but the normal user has no access to it. I think maybe the floppy drive unit in the source system must have been given an identifier which is different in the target, even though there was no media in it when the original install was done. I haven’t figured out a fix yet.
I haven’t tested USB devices yet, but I shall do so this coming Saturday and report.
In retrospect, the funniest part of this whole UUID flap was that due to a bug in util-linux, UUIDs of swap partitions wouldn’t match up across hibernations. So a change that was supposed to get rid of an occasional headache instead wound up turning it into a constant one. It’s so perfect that it makes me wonder why The Linux Hater didn’t cover it before he quit.
Trackbacks
[…] installation on that partition can affect the installation on this partition is through UUID, which I’ve previously complained about when installing “Old-Gutsy” stopped Feisty from recognizing all my partitions (like […]
[…] that I don’t understand UUID, but I think if he’d take a few minutes to actually read what he linked to, it would be obvious I have a genuine problem, and that UUID is most decidedly the culprit. Oh […]
[…] by wolfger on March 25, 2009 Once again, UUID really sucks. Installed OpenSUSE today on my spare drive, now I can no longer boot into Ubuntu even though that […]