Once more, with feeling

Once again, UUID really sucks. Installed OpenSUSE today on my spare drive, now I can no longer boot into Ubuntu even though that hard drive was untouched. This makes sense how?  Stranger yet is that I installed Linux Mint before OpenSUSE, and if I selected Mint from the GRUB menu, Ubuntu would boot instead. (If I selected Ubuntu, I would get an error, so I suspect Mint fried my UUID before OpenSUSE had a chance to).

No big deal… when I get home, I’ll eradicate UUID from my menu.lst and fstab files AGAIN, and all will be right with the world. It’s just freaking annoying, and I want to document all my UUID hassles so I can easily point to them when people ask why I don’t like UUID.

Post a comment or leave a trackback: Trackback URL.


  • Aaron  On March 25, 2009 at 10:06 am

    To begin, you need to understand that UUIDs are hardcoded into the filesystem when you put down a new filesystem on a newly prepared partition. The numbers don’t change unless you reformat the partition. If the numbers are changing, then either something is seriously broken on your system, or you’re not understanding why it changed. UUID is using the EXACT same system as LABELs. Both, as mentioned, are hardcoded into the filesystem, and don’t change unless you either put down a new filesystem, or change it by hand with ‘tune2fs’ or a compatible tool.

    First what are all the partitions that you have on this hard drive? Running ‘blkid’ as root, can you provide the UUID for each filesystem? Second, you mentioned earlier that you’re sharing the swap partition between dual booting Linux operating systems. When you’re installing the second operating system, is it re-formatting the swap partition? If so, it will get a new UUID, which means when you boot into the other OS (Ubuntu), it will fail booting, as it will be in the /etc/fstab as a different UUID and Upstart won’t know how to handle it. My guess is this is your problem. When putting down the now OS (openSUSE), tell it where the partition is, but not to format it, and you’ll be fine.

    The UUID is a real slick, and stable system. It provides complete uniqueness for all drives and partitions, including RAID arrays and LVM volumes. It allows the developers to change drivers for hard drives in the kernel, and not affect your install. For example, in kernel 2.6.20, the developers ditched the PATA driver completely, and introduced a new SATA driver that would recognize PATA disks. Unfortunately, this meant that if you have /dev/hda1 in your /etc/fstab, for example, you couldn’t boot, as the kernel is now seeing the drive as /dev/sda1 instead. Using UUID= or LABEL=, you wouldn’t have this problem. The advantage UUID= has over LABEL= is labels aren’t necessarily non-unique. What happens if you want to mount two devices with LABEL=private? If they both have ext3, or Linux compatible filesystems, they will be guaranteed to have unique UUIDs, which will safeguard this.

    I’m betting that when you install your new operating system, it’s re-formatting the shared swap partition, and as such giving it a new UUID. Again, this will keep the other operating system from booting, as in the /etc/fstab, it’s expecting a static value that your new operating system install just changed. Don’t format it, but just point to its existence, and you should be smooth. For what it’s worth, in my opinion, swap really isn’t needed in most cases, for desktop and laptop installations, unless you want to hibernate to disk or have insufficient RAM to handle a modern OS.

    • wolfger  On March 25, 2009 at 10:19 am

      I will check out my UUIDs when I get home, and verify what, if anything, has actually changed. I know I keep saying that my UUID has changed on drives that weren’t formatted (see story of tornado-induced power outage, and story of problem with unformatted shared drive space from previous posts), but in truth I’ve never actually compared numbers. I’ve merely witnessed a problem, removed UUID from the equation, and witnessed the problem disappear. I deduced therefore that the UUID changed, but since you assure me this is not possible, I will have to actually gather proof šŸ™‚

      As for swap UUID change preventing me from booting: I don’t buy it. It hasn’t stopped me from booting in the past (just stops swap from mounting), and there’s absolutely no reason I can think of for why it should stop me from booting now.

      I’ll update later when I have access to the box and can present more facts rather than conjecture.

  • Aaron  On March 25, 2009 at 10:45 am

    Heh. Whether or not you “buy it” is irrelevant. As most Linux distributions sit, including Ubuntu, any entry in your /etc/fstab that either does not exist, or can’t be located, will keep the operating system from booting, regardless of the partition. Upstart will stop, ask the user what it should do, then carry on, but there is no timeout that I’m aware of. So, if the UUID changes on the filesystem, and /etc/fstab is expecting something else, the system just will not boot until it’s fixed.

  • wolfger  On March 25, 2009 at 10:53 am

    That is flat-out false. I know for a fact that it is, because the last time I removed UUID from my fstab, I mistakenly called out /dev/sda6 as /dev/sdc6, which does not exist. The system booted just fine, except my /home/wolfger/shared directory was not mounted. This was recent, too. On Intrepid.

  • Aaron  On March 26, 2009 at 2:57 pm

    It’s not flat-out false. I don’t know the answer to every situation possible, but I can tell you the design of init. System V Init will not continue the boot process with a syntax error, incorrect location, or missing entry in your /etc/fstab. If Upstart, which is System V Init compatible, is booting anyway, then it’s doing something that I am not aware of. However, I have an external 1TB drive connected via USB 2.0. If it isn’t present when my system boots, I’m dropped to an sulogin, of which I have to provide the root password to fix the situation before I can continue, which is expected. I’ve been teaching Linux system administrators for some time, and have demonstrated this very thing to help the students understand the boot process on Linux. I’ve taught it on OEL 4, RHEL 4, SLES 10 and Ubuntu 8.04. It’s always performed as expected. So, again, if your Ubuntu install is doing something different, by booting anyway, then it’s something specific to your installation, as my Ubuntu 8.10 vm in VirtualBox behaves as expected, halting the install, dropping me to an sulogin, asking to fix the problem before continuing.

  • wolfger  On March 26, 2009 at 4:48 pm

    Well, the current circumstances are completely UUID related after all. It was pure OpenSUSE problem. For some whacked out reason, I could not load Ubuntu from the OpenSUSE boot menu, regardless of whether I was using UUID or /dev. (in fact, OpenSUSE was using /dev, and I added a UUID entry)

    As for failure to boot based on a bad swap… obviously we’ve had different experiences. Or, possibly, my memory is faulty. It happens. Maybe some day soon I’ll deliberately screw up my fstab and post the proof. Having finally rescued my system from the clutches of OpenSUSE, I’m not really feeling like rebooting again anytime soon :p

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: