If you’ve ever rebooted a Linux server and had it fail to come back up, there’s a good chance the culprit is sitting right in your /etc/fstab file. Device names like /dev/sda1 can shift after a reboot, a drive swap, or even a kernel update — and when that happens, your mounts break and your server may not boot at all. In this video, I break down why UUIDs matter for Linux storage, and I show you a real production server that ran into exactly this problem.

What is a “Universally Unique Identifier?”

And first, let’s set some foundational knowledge. What exactly is a UUID in regard to Linux storage, and why does it matter?

Well, to better understand that we need to first understand the problem that UUID’s actually solve. What you’re seeing right here is an /etc/fstab file, and you can see that I have two volumes, /dev/sda and /dev/sdb that are being mounted.

At first, nothing looks unusual here – and to be fair, the file is correct from a syntax perspective. We have the two volumes I mentioned, a mountpoint, a filesystem type, and so on – the file looks totally fine from an untrained eye.

But the problem is that depending on the hardware or platform, the device identifiers (such as /dev/sda for example) might not always be assigned to the same device. When your system boots up, it’s going to assign identifiers like sda or sdb to your hard disks, and depending on the order they’re detected in, the device previously known as sdb might now be sda. When this happens, it effectively means that storage volumes might not be mounted to their correct directories. In my case, the volume designated for swap might get sdb sometimes, or sda other times.

And when this does happen, you might end up getting a kernel panic, such as the one you’re seeing here. And yes, this is the actual server the community forums runs on – it’s not a demo instance, it’s a real server. I could simply force a reset of the instance, and maybe it’ll come up fine next time. If not, I’ll reset again, and eventually it’ll boot like there was no issue – even though I haven’t actually fixed anything yet.

When it comes to Universally Unique Identifiers, this is the exact problem this concept aims to solve.

What I’ll do right now is give you a few commands we can use as we navigate the problem. The first one is the lsblk command, which simply shows us a list of storage volumes we have attached to our server, and it doesn’t matter if it’s a cloud instance, a VM, or physical hardware – with this command we’ll see the storage volumes that are available to us.

In addition to that, we also have the blkid command, and what this does is give us the UUID’s of all of our storage volumes. You can also run blkid against a storage volume directly, such as this one:

blkid /dev/sda

Going back to the lsblk command, we can actually view all of the information we need in one shot by simply adding the -f option:

sudo lsblk -f

So at this point, we now know how to retrieve the UUID’s assigned to our volumes, but what does that actually give us, and why is this important?

Well, the benefit is that UUID’s never change. If you use UUID’s to reference a storage volume instead of the normal device identifier, you won’t have to worry about what order the volumes were detected in – the UUID follows the device.

Fixing the forums site

Now that we’re armed with a bit of foundational info, let’s see what this looks like in practice.

When it comes to my server, what you’re seeing here is its /etc/fstab file. As I’ve covered in other videos, this file is (more or less) an index that tells our system what to mount, and where to mount it to. In this case, sda is the root volume, and sdb is for swap.

What’s really strange about this is that I always use UUID’s, and I have no idea how it got this way. But what we’re going to do is switch the server to use UUID’s instead.

Before we do that though, what I’m going to do is take a snapshot of the instance so that way if I make a mistake, I can easily revert the changes.

Now what I’m going to do is find the UUID’s:

sudo lsblk -f

Now, before we continue, if you see PARTUUID, that’s not what we want. We specifically want the UUID of each device, which we have here. We can copy this information into a text file somewhere, we’ll need it shortly.

With that done, we’ll edit the /etc/fstab file – and we need to be very careful here and take our time, because one typo in this file is all it takes to have an unbootable system. We could recover it from the snapshot, but I’d still rather do it right the first time.

Anyway, we’ll edit the file:

sudo nano /etc/fstab

And inside it, we’re going to change the device identifier to use UUID’s instead. For example:

UUID=12798ba4-5b80-1411-028e-6c072007bdff

We’re going to replace /dev/sda with this instead, and we’ll do the same for the other one.

Verifying the /etc/fstab file

At this point, we’re actually done – but we should run through some verification first. We definitely shouldn’t reboot our server until we’ve verified that we’ve edited the fstab file correctly.

To do that, we’re going to run this command:

sudo mount -a

What this command will do is mount any volume that’s not already mounted – but it also does some validation too. If we have a syntax error in the fstab file then this command will give us an error.

In addition to that, we can also run the following:

findmnt --verify

This command further validates fstab syntax and checks for things like missing mount points.

Basically, after editing the fstab file we should never reboot the system until we’ve tested it through those commands. In my case, there were no errors – so I’m safe to reboot.