• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: Kernel SD root device with/without attached eSATA  (Read 3353 times)
elbling
Newbie
*

Karma: 0
Posts: 2


View Profile
« on: June 08, 2010, 12:15:06 PM »

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
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #1 on: June 08, 2010, 01:37:36 PM »

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...
Logged

heini
Newbie
*

Karma: 0
Posts: 8


View Profile
« Reply #2 on: June 15, 2010, 12:01:11 AM »

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
Logged

cjm
Jr. Member
**

Karma: 6
Posts: 69


View Profile
« Reply #3 on: July 18, 2010, 02:37:25 AM »

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
Logged

fragfutter
Sr. Member
****

Karma: 12
Posts: 280


View Profile
« Reply #4 on: July 18, 2010, 03:25:38 AM »

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.
Logged

soxs060389
Newbie
*

Karma: 0
Posts: 9


View Profile
« Reply #5 on: July 22, 2010, 05:11:30 AM »

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
Logged

theYinYeti
Newbie
*

Karma: 0
Posts: 15


View Profile WWW
« Reply #6 on: September 13, 2010, 12:30:07 AM »

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.
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #7 on: September 13, 2010, 03:34:53 PM »

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?
Logged

theYinYeti
Newbie
*

Karma: 0
Posts: 15


View Profile WWW
« Reply #8 on: September 15, 2010, 05:12:59 AM »

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.
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #9 on: September 15, 2010, 03:01:38 PM »

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.
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #10 on: December 22, 2010, 05:51:50 PM »

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.
Logged

Pages: [1]
Print
Jump to: