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:

fw_printenv usb_set_bootargs
usb_set_bootargs=setenv bootargs console=$console root=&usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params

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:

blkid
/dev/sdc1: LABEL="my-rootfs" UUID="4812b490-4104-5b33-85ae-7aa4ba635173" TYPE="ext2" # that's it
/dev/sdc2: UUID="d8ae81eb-28ff-a983-42a6-28d2b868759c" TYPE="swap"

Now alter usb_set_bootargs and create usb_root_label:

fw_setenv usb_set_bootargs setenv bootargs console=\$console root=LABEL=\$usb_root_label rootdelay=\$usb_rootdelay rootfstype=\$usb_rootfstype \$mtdparts \$usb_custom_params
fw_setenv usb_root_label my-rootfs

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:

blkid
/dev/sdc1: LABEL="my-rootfs" UUID="4812b490-4104-5b33-85ae-7aa4ba635173" TYPE="ext2" # that's it
/dev/sdc2: UUID="d8ae81eb-28ff-a983-42a6-28d2b868759c" TYPE="swap"

Now alter usb_set_bootargs and create usb_root_uuid:

fw_setenv usb_set_bootargs setenv bootargs console=\$console root=UUID=\$usb_root_uuid rootdelay=\$usb_rootdelay rootfstype=\$usb_rootfstype \$mtdparts \$usb_custom_params
fw_setenv usb_root_uuid 4812b490-4104-5b33-85ae-7aa4ba635173

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

Reboot

Now give it a try and reboot your system.

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

mount
/dev/disk/by-uuid/4812b490-4104-5b33-85ae-7aa4ba635173 on / type ext2 (rw,noatime,errors=remount-ro,user_xattr,acl)

NOT like this:

/dev/sda1 on / type ext2 (rw,noatime,errors=remount-ro)

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.