Tag Archives: UUID

I don’t know why, but from time to time drivers are assigned other “/dev”-paths on my ubuntu 6.10 LTS GNU/Linux server. I think a removable USB driver might have something to do with it…

However, when that happens it is a complete pain in the a$$ because if the driver is relocated, the system cannot find it and if it is mentioned in /etc/fstab the system reasons (justly so, I might add) that if it can’t find the drive it should pull the emergency break and jump into a rescue prompt (where mostly everything is disabled), letting the user (that’s me) deal with the problem.

I usually press the CTRL-D command exiting the shell and getting back to the boot process praying that no vital driver was lost. (I’m not really a guru, just a poor guy trying to make live a little easier).

For some reason (touch wood!) the drives with the boot image or with system specific things on them has never been moved around this way. Usually its the USB drive itself (when I still had it in the fstab) that has moved (I’ll get back on how to make it auto-mount in a later post) or in this latest case, one of the back-up drives.

However, there’s a solution. If you run GNU/Linux you might have seen it in your fstab-file. The use of a UUID to do mount instead of the regular /dev/something. My desktop computer’s fstab looks like this:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options> <dump>  <pass>
proc            /proc           proc    defaults  0       0
# /dev/sda1
UUID=e1f37856-6cfd-43f9-bea0-d4c2e43afe29 /     reiserfs notail,relatime 0  1
# /dev/sda6
UUID=64549135-a478-4aef-bb2a-da37d245dd9c /home reiserfs relatime        0  2

From this rather confusing array of characters (I had to shrink the spaces in order to fit it on the site) you can determine that there’s three devices mounted at start up (proc, sda1 and sda6, I’ve got even more, but the exact number of devices are not interesting for this discussion).

The proc device always resides at the file system “proc”, and it does not have nor need a UUID. However the sda1 and sda6 devices are regular hard drives (formatted with reiserfs) and they can change designation, for instance if I start rearranging my sata-cables or start a USB drive in a USB slot with a lower ID than those of my sda drivers (I’m guessing on that one but I’ve seen it on my server so…) These are therefore interesting to mount not by their dev-names but by their UUID’s. The UUID are stored on the drive itself and it wont change unless the drive is reformatted. The drive can be moved, turned off, turned on, it will still have the same UUID.

So, using UUIDs are a good idea when I want to create my new, drives-moving-around-proofed server configuration. The first step is to determine what UUID the drives have. This is done with the following command:

sudo vol_id -u /dev/something

I had problems finding “vol_id”. It was not in the PATH, and could therefore not be run like above. I did a locate (locate vol_id) and found it in “/lib/udev” so I prepended that path to my command. I’ve also to determine how to get the UUID from a swap partition, but for now I’m happy to have the infringing drives on UUID and hope the swap wont move (perhaps with the extra 2GB of memory I also stashed in it will need the swap even less, but anyway)…

You won’t be able to determine the UUID of any drive part of a software raid configuration (but then again, the software raid is able to do its own magic locating of drives regardless of their sd-number — trust me, I’ve done that as well — so they won’t need a UUID anyway — wouldn’t surprise me if raid uses the same scheme behind the scene though)

Let’s look at the changes I did in my fstab file (always make backups before you start messing with this file! If you fail to set it up correctly your system will probably not start at all so have a live-cd handy before trying to do this!):

/etc/fstab before I changed it (just a part of it)

# /etc/fstab: static file system information.
#
# <file system> <mount point>    <type>   <options>           <dump>  <pass>
proc            /proc            proc     defaults            0       0
/dev/sdc1       /                reiserfs notail,user_xattr   0       1
/dev/sdc5       /home            reiserfs defaults,user_xattr 0       2

As you can see the situation is not as clear on this machine as it was on my desktop machine. Here sdc is the main system drive and that alone is a, well not a worrisome problem, but a slight discomfort… sdc never moved around, but being that I have a bunch (8 or 9) sata-cables in a large but far-from-large-enough case I’m bound to switch them around one day or another…

Anyway, using the above vol_id command to get the UUIDs of the drives, I’ve updated my fstab to look like this (still only partial fstab but you get the idea):

# /etc/fstab: static file system information.
#
# <file system> <mount point>    <type>   <options>           <dump>  <pass>
proc            /proc            proc     defaults            0       0
#/dev/sdc1
UUID=716cf691-dabd-4894-8e46-bc02b4c092b4 /     reiserfs notail,user_xattr   0  1
#/dev/sdc5
UUID=9587a32e-ebb2-45ab-9e68-7a66cf43d6b4 /home reiserfs defaults,user_xattr 0  2

Unfortunately I have the same problem as above, the lines wont fit in the editor (or on the site) if I tabulate them correctly, but hopefully you’ll still be able to connect the dots. Every group of white spaces (space, or tab) in the file counts as a field separator. I’ve commented out the “/dev/sdc…” section, added a line feed and replaced it with the “UUID=…” section, and then left the rest of the line intact.

This makes sense since I’ve replaced one identifier (“dev/sdc…”) with another (“UUID=…”). So, after the original “dev”-version of the file has been safely backed up, the entries in the original “/etc/fstab” has been checked and double checked, it’s time to restart and pray this will actually work. :O

Here’s a few links you might want to check out before you give it a try:

Good luck!

Update: If, however, you’re using LVM, you’ll get stable device names and you should mount these instead. If you use LVM-snapshots you’re going to get two or more volumes with the same UUID, and in that case you should absolutely not use UUID mounting.

Computers

Using UUIDs to Prevent Broken Links

April 3, 2007 erk

I don’t know if someone has proposed this before, but how about using UUIDs to prevent broken links?

A UUID, Universally Unique Identifier, is a hexadecimal number divided into five sections. A UUID has the special quality that it is universally unique. This means two people on each side of the world could create a UUID each at the exact same time, and still be sure their UUIDs are not identical. In fact they can create a large number of UUIDs and still be sure they are not identical. (The same goes for two people on the same server.)

This quality makes UUIDs a perfect tool for assigning unique IDs to web pages or other Internet resources (in fact any resource of any kind, your dog, the cuttlery in your drawers, you name it.)

This could be done like this:

Step 1: Place the UUID on the page

First a UUID has to be put on the webpage, perhaps with a meta-tag, or with plain text on the page.

With a meta tag it could be done like:

<meta name=”UUID” content=”8523813a-7c47-4cd9-ad78-09c14dfb505f”/>

Or on the page, like:

UUID: 8523813a-7c47-4cd9-ad78-09c14dfb505f

Step 2: Find the UUID

The second step would be to make sure every time a program stores a URL to the page it also stores the UUID. (When creating bookmarks, or linking from one site to another etc).

So, once the page get lost, either because the link has changed, the page has been moved or something similar, the browser (or site) can use the UUID to find the page again.

The second step obviously demands a search engine (or some other central registry) that utilizes UUIDs in it’s index since the system does require some kind of central processing for keeping track of a UUID-to-page-link.

A UUID is not a particularly good URI since even UUIDs generated at the same host just a few seconds apart are still totally different from each others (this actually depends on implementation, but one should not assume UUIDs from the same host shares any similarities).

This however is also one of the strengths of UUIDs since it means an Internet resource should be possible to locate regardless of its physical location (in a contrary to ordinary http-URLs that are tightly bound to their location — they start with the server name).

Since a UUID (per definition) is universally unique, it is fairly simple to generate one wherever you are, and use it in a page, be sure there are no duplicates and locate the exact page of the UUID again.

A Google experiment

I’ve placed the text “UUID: 8523813a-7c47-4cd9-ad78-09c14dfb505f” on this page. (Several times now). As far as I’ve been able to discern, Google indexes even such arbitrary information as UUID data (the exact string “8523813a-7c47-4cd9-ad78-09c14dfb505f” to be precise, check out this page with a discussion on how to use UUIDs to make pages unique… It has nothing to do with this discussion but is an interesting example on how UUIDs could be used with Google).

By searching for “8523813a-7c47-4cd9-ad78-09c14dfb505f” it should be possible to locate this page… (see if it works? — Give Google time to index the page though… Update: the above link seems to not work, but this one [searching for the UUID with “-” replaced to space — or “+”], however, does…)

Finally

The page localization should work regardless of the page’s position, site, or anything. In fact, as long as the UUID is still there, it should even be possible to place this text in a document of type Word/OpenDocument/PDF or any other format a search engine can index, and the text would still be possible to find with nothing but the UUID.

Obviously the end result of this technology would be that there is no “search-engine-in-between” but instead whenever the link is lost, the caller goes to the central repository/search engine (or some other place) and locate the page, then links to it automatically. It should even be smart enough to retry until it finds a link that works if a UUID has several possible links.

Talkwards