Dockstar/Golfex: booting with LABEL or UUID instead of device name

Dockstar/Golfex: booting with LABEL or UUID instead of device name

(1 votes, average: 5.00 out of 5)

Did you want to reboot your Dockstar or Golfex with multiple drives attached? Well, that’s not the problem if uboot lists the devices in the correct order.
But what if your Golfex has SATA drives attached and you want to boot from an usb-drive?

The answer my Goflex gives me all the time: Loading kernel from usb works. Starting the kernel also works. But mounting the filesystem fails, because the device names are remapped when the SATA drives are initialized. The usb-drive ain’t /dev/sda anymore…

I (have) had one rule since I had to drive more than 100 kilometers to fix that: never reboot remotely with SATA attached.

The solution is quite simple:
We have to tell the kernel properly where to get the rootfs from to mount it. To be versatile, uboot is configured to boot the kernel with device names as parameter, such as /dev/sda1. But I know what I am doing and want to boot from one single device, no matter if other drives are attached or not, which could mess the device names. So the disk LABEL or the Universally Unique Identifier (UUID) is what we need.
You might say: Ha! I adapt fstab. But this doesn’t do the trick.

We need to alter the uboot bootargs. You have to decide which method is more suitable for your environment.

First of all backup the current argument:

LABEL method

The more flexible method is to use the disk LABEL. It allows you to easily change your boot device without modifying the uboot vars.

Determine the rootfs’ LABEL:

Now alter usb_set_bootargs and create usb_root_label:

UUID method

Before you start: If you change your bootdevice or change it’s UUID, your device will most likely fail to boot! I have a fallback rescue system installed on nand, and a serial console to debug things. If you are not on the latest uboot or you didn’t use Jeff’s uboot script, your output may vary.

Determine the rootfs’ UUID:

Now alter usb_set_bootargs and create usb_root_uuid:

If you do this directly in uboot use printenv, setenv and saveenv instead of fw_printenv and fw_setenv.


Now give it a try and reboot your system.

To verify your work, check mount. It should look like this:

NOT like this:

Update 09.06.2013:

Thanks to chessplayer pointing at the advantages/disadvantages on these methods! I’ve rewritten this article to have both methods together in one place.