Kernel SD root device with/without attached eSATA

[elbling]

Hi folks,
I'm booting the kernel from nand and using a rootfs on the SD-card.
Without an attached eSATA device the root device is root=/dev/sdb1.

If I boot with an attached eSATA drive, this drivers are loaded first and the root device on SD will become root=/dev/sdc1.

To be more robust while booting with/without the eSATA disk, I wanted to use an 'generic' path to the root device.
Ther is a tree beneath /dev/disk were you can find symbolic links to the different disks.

Code:

root@guru:/dev/disk# ls -l
total 0
drwxr-xr-x 2 root root 340 Jun  6 22:01 by-id
drwxr-xr-x 2 root root 180 Jun  6 22:01 by-path
drwxr-xr-x 2 root root 120 Jun  6 22:01 by-uuid

Code:

root@guru:/dev/disk/by-id# ls -l
total 0
lrwxrwxrwx 1 root root  9 Jun  6 22:01 ata-Hitachi_HDS721010CLA332_JP2940HQ2TJEVH -> ../../sda
lrwxrwxrwx 1 root root 10 Jun  6 22:01 ata-Hitachi_HDS721010CLA332_JP2940HQ2TJEVH-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jun  6 22:01 ata-Hitachi_HDS721010CLA332_JP2940HQ2TJEVH-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jun  6 22:01 ata-Hitachi_HDS721010CLA332_JP2940HQ2TJEVH-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jun  6 22:01 scsi-SATA_Hitachi_HDS7210_JP2940HQ2TJEVH -> ../../sda
lrwxrwxrwx 1 root root 10 Jun  6 22:01 scsi-SATA_Hitachi_HDS7210_JP2940HQ2TJEVH-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jun  6 22:01 scsi-SATA_Hitachi_HDS7210_JP2940HQ2TJEVH-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jun  6 22:01 scsi-SATA_Hitachi_HDS7210_JP2940HQ2TJEVH-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jun  6 22:01 usb-Generic_STORAGE_DEVICE_000000009909-0:0 -> ../../sdb
lrwxrwxrwx 1 root root  9 Jun  6 22:01 usb-Generic_STORAGE_DEVICE_000000009909-0:1 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jun  6 22:01 usb-Generic_STORAGE_DEVICE_000000009909-0:1-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Jun  6 22:01 wwn-0x5000cca35de755a7 -> ../../sda
lrwxrwxrwx 1 root root 10 Jun  6 22:01 wwn-0x5000cca35de755a7-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jun  6 22:01 wwn-0x5000cca35de755a7-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jun  6 22:01 wwn-0x5000cca35de755a7-part3 -> ../../sda3

When I use
root=/dev/usb-Generic_STORAGE_DEVICE_000000009909-0:1-part1
the kernel hangs while waiting for the root device to become ready.

I have altough tried the symbolic links in /dev/by-path /dev/by-uuid with the same result.

It seems, that the symbolic links are not directly available.

Any ideas how to reference the SD card independently  from eSATA?

Thanks

elbling

[birdman]

Ther is a tree beneath /dev/disk were you can find symbolic links to the different disks.

That's populated (by udev, I think) by the running kernel, so not there at boot time.
Sorry - I can't help on your real question...

[heini]

Any ideas how to reference the SD card independently  from eSATA?

What you want is to reference the filesystem on the SD card, which can be achieved by using filesystem labels. See http://www.ibm.com/developerworks/linux/library/l-boot-rootfs/index.html.

HTH...

    Dirk

[cjm]

Did you connect the SD card via a USB adapter? The native SD card slot on the plug should give you device names like /dev/mmcblk0p1 for partition 1 and you shouldn't have the problems you described

If you connected the SD card via a USB adapter, you should be able to change the order in which the USB and SATA drivers are loaded by editing /etc/modules and adding the module usb_storage to the top of the file. This way, USB disks will be detected first regardless whether the eSATA disk is attached or not. Unless, of course, it takes too long for the USB stack to get up and running. In this case, you could try to add some delay after loading the USB modules in modprobe.d. Something like this:

/etc/modules:
usb_storage

/etc/modprobe.d/usb_delay.conf
install usb_storage /sbin/modprobe --ignore-install usb_storage; /sbin/sleep 10

If you use a kernel with an initial ramdisk, you would [also] update /etc/initramfs-tools/modules and recreate the initial ramdisk. Not sure whether the NAND kernel uses an initial ramdisk off the top of my head and whether this initial ramdisk might load SATA or USB drivers but I don't think so because the NAND kernel only needs a driver for the NAND to boot.

Thanks,
--Christian

[fragfutter]

Did you connect the SD card via a USB adapter? The native SD card slot on the plug should give you device names like /dev/mmcblk0p1 for partition 1 and you shouldn't have the problems you described

the guruplugs have the sd-card internally attached as an USB device.

[soxs060389]

Don't know if it helps, but I'd try following: Boot into your GPS OS, do ls -l /dev/sd* and you see 2 numbers (in my case 8 and 17). Convert each of them (don't treat them as a single one, that won't work) into hex (in my case 8 and 11). Go into uboot and set root=hexAhexB (in my case 0811), don't forget padding zer0 if it is a single digit.

GL

[theYinYeti]

In /etc/fstab, you can reference a partition in three different ways:
— “/dev/sdXX”
— “LABEL=XXXXX”
— “UUID=XXXXXXXXXXXXXXXXXXXXXXXX”

The first way is straight-forward but unreliable. The third way is the most reliable because each UUID is unique, system-independent, and valid until the partition is formatted anew; it is however hard to read/type, and non human-friendly. My preference goes to the second way; you only have to be careful to only choose unique labels across all partitions that could be connected to the system. Example on my plug:

Code:

plug:~# ls -l /dev/disk/by-{label,uuid}/
/dev/disk/by-label/:
total 0
lrwxrwxrwx 1 root root 15 sep 13 08:21 BootPlug -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 sep 13 08:21 RootPlug -> ../../mmcblk0p2

/dev/disk/by-uuid/:
total 0
lrwxrwxrwx 1 root root 15 sep 13 08:21 0027220a-0bc9-4d4e-9519-a5d107c36b87 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 sep 13 08:21 7be41792-db5c-439d-bcf8-ef4acfcd4eab -> ../../mmcblk0p1

plug:~# grep ext /etc/fstab
LABEL=RootPlug            /             ext3     relatime,errors=remount-ro        0      1
LABEL=BootPlug            /boot         ext2     defaults                          0      2

Yves.

[birdman]

In /etc/fstab, you can reference a partition in three different ways:...

The OP's question was about boot time though, so we haven't got as far as being able to read fstab yet.
The question is whether the boot mechanism can understand UUID or Label settings.  I think that's the kernel, rather than uboot?

[theYinYeti]

Sorry, I misunderstood.

In that case, I don't know if labels can be used. On the other hand, I already successfully used UUIDs for kernel boot options. It was not for root=, though, but rather for resume=, and not on a plug…

Yves.

[birdman]

In that case, I don't know if labels can be used.

They work for root= when booting with grub (v1) on an x86 system.  All I can test at the moment.

[birdman]

Turns out that root=LABEL=... and root=UUID=... only works if you are using an initrd image - which I'm not, but I might look into using a generic one (no module loading) so that I can use LABELs.
In the meantime PARTUUID has just made it into the kernel.