how to list scsi devices while executing linuxrc

rotkmaninov · 03-30-2013, 08:26 AM

Hi ,

I'd like to list scsi devices at boot , while executing linuxrc , before mounting the root . Basically the same output as fdisk -l . Looking at the code of fdisk , uses /proc/partitions , so is not usable (partitions are not mounted) . Looking at the code of lsblk , uses sysfs , also this is unusable . I suppose some system call is needed , so I've googled in several linuxrc.c , and in kernel-api docs, without success . May be I'm searching in the wrong places .
So, any idea ?

jpollard · 03-30-2013, 08:43 AM

You won't find one.

these are normally loaded by udev.

http://www.enterprisenetworkingplane...-with-udev.htm

The problem is in two parts - first, during the inital boot, there are no devices - the kernel only has a builtin ramfs driver, a tty driver for the console. The ramfs is loaded from the initrd. Once the initial boot is done the init process starts working from scripts in the ramfs - which runs udev to scan for physical devices, and load appropriate drivers.

The last thing done by these scripts is to identify and mount the real root in /mnt of the ramdisk, then use the pivot_root system call to exchange the ramdisk root and the /mnt mounted root. Once that is done, the ramdisk is dismounted... and init execs the /sbin/init from the real root.

As far as I know, there are no system calls to do that, I believe udev uses privileged access to the controllers to invoke appropriate scans by sending raw scsi commands. Responding controllers get drivers loaded, which in turn initializes/appends to the partition table.

I think your best bet is to just read the /proc/partitions table.

If you REALLY want the list of SCSI devices (and not all SCSI devices are disks), then there is the /proc/scsi/scsi file which lists what has been identified.

rotkmaninov · 03-30-2013, 09:14 AM

Scsi (and other devices) have just been found by kernel , at the time when I need to list them , so it's after the udev action. But before the mount of root : I'd like to print the list to have a menu from which is possible to choice the dev for mounting the root . I can't read /proc/partitons because partitions are not mounted , as I said (that would be doing as fdisk) . Actually I'm booting from USB, the boot device is hard-coded in the linuxrc, if I add or remove a hd or cd , the list of sdx devices changes , and my boot fails . I have to rebuild another linuxrc with proper devices .

jpollard · 03-30-2013, 09:26 AM

Quote:

Originally Posted by rotkmaninov

Scsi (and other devices) have just been found by kernel , at the time when I need to list them , so it's after the udev action. But before the mount of root : I'd like to print the list to have a menu from which is possible to choice the dev for mounting the root . I can't read /proc/partitons because partitions are not mounted , as I said (that would be doing as fdisk) . Actually I'm booting from USB, the boot device is hard-coded in the linuxrc, if I add or remove a hd or cd , the list of sdx devices changes , and my boot fails . I have to rebuild another linuxrc with proper devices .

So you are using a non-standard boot process ?

IF it is after udev, but before mounting root, then /proc/partitions is what you want. But if you also need to know if they contain a root file system, then you are out of luck.

That is why there is a ROOT= option on the kernel command line. You have to tell it what to use for root. The blkid utility will list the UUID value (always present for disks) or the "label=" value if the partition is labeled.

Now if the label of all roots is something like "ROOT<number>" then you can get a list of UUID values that can be used for root and create a menu that way (see /dev/disk/by-label), but you can't have two identical labels. BTW, the devfs filesystem (mounted as /dev) is a memory resident filesystem so it is available after udev runs.

Don't count on much in the way of graphics (the initrd is still rather small for fancy graphics unless you have lots of memory).

And your problem of identifying which physical device is why the ROOT= option has one of "UUID=...." or "LABEL=...". Both of these are identified when the partition table is loaded

rotkmaninov · 03-30-2013, 12:18 PM

Hmm .. , about udev I've just followed you, but now I think I'm wrong (about udev) : a bunch of devices used to boot are statically built in /dev partition in initrd , this is why I can mount for instance /dev/sdc to use as boot , once that I know which sdx to use (the goal of this question) . I think udev has not yet run , if this invalidate your answer , I'm really sorry , I really appreciate your effort , this is a difficult matter full of thorns , anyway , this is why I've come here ;-)
But again, boot partition and root partition are not yet mounted , devices have just been recognized by kernel , somewhere in ram memory there should be the list of sdx devices , how to get it ?
Now I rebuild a very much custom initrd each time I add or remove a disk .
If you are interested , you can look at the build-initrd.sh script in the loop-AES package , at sourceforge .
The kernel option for root is 100 (I can't change), after there is a root change in the linuxrc script (hard-coded also), yes I can build a menu also for choosing root device , but this comes after getting the list of sdx :-)
Unfortunately I can hardly follow your considerations on partition tables , I don't have partiton tables at all , not even in the USB stick .

jpollard · 03-30-2013, 01:25 PM

It appears nonstandard... as it must have all drivers compiled into the kernel. I do notice that the function to actually create these /dev entries are "maybeMakeDiskNode". So only one of these has to exist.

But you still can't scan scsi controllers - just look at the partition tables created during driver initialization. Thats all you get.

And the names cannot be fixed - they vary depending on how the hardware reacts during initialization. O

Thats why there is a "ROOT=" kernel command. There is no way to know ahead of time what the system drive will be named.

And even "no partition" table still gets an entry in the partitions table - one that covers the entire disk.

Just look at any running system - if you cat the /proc/partitions file you will see something like:

Code:

$ cat /proc/partitions
major minor  #blocks  name

   8        0  244198584 sda
   8        1    1048576 sda1
   8        2  113185792 sda2
   8        3  113184768 sda3
   8        4          1 sda4
   8        5   16776192 sda5
   8       16 1953514584 sdb
   8       17  976757260 sdb1
   8       18  976757292 sdb2
   8       32  244198584 sdc
   8       33  244196001 sdc1
   8       48   58633344 sdd
   8       49   58629186 sdd1
  11        0    8233770 sr0

Note the entries for "sda","sdb","sdc",and "sdd". That entry would be the disk with no partition table to subdivide the disk.

Notice the oddity of sda sdb and sdc. sda and sdc are the same manufacturer and drive size... but sdb is a different manufacturer. The only reason sdb is named sdb is that it happens to come up ready sooner than sdc. And no rearrangement of cabling will fix that (tried, doesn't work). Not sure why sda even comes up first, it just does. sdd I understand (it really is a slow drive - an old ATA).

If you still need SCSI Ids, look in the directory /dev/disk/by-path.

Unfortunately, I believe these entries are created by udev. Without udev to identify the disks you may be out of luck - other than maybe using blkid to scan the partition table and read the extra information from the disks.

rotkmaninov · 03-30-2013, 02:07 PM

Quote:

Originally Posted by jpollard

It appears nonstandard... as it must have all drivers compiled into the kernel. I do notice that the function to actually create these /dev entries are "maybeMakeDiskNode". So only one of these has to exist.

>Correct , all drivers are compiled into the kernel , there are a lot of options to be set precisely : I have to add /dev/sda ... /dev/sdz static devices , to have all of them available at mount , actually only the hard-coded are built

But you still can't scan scsi controllers - just look at the partition tables created during driver initialization. Thats all you get.

>with many disks it's not possible to look at the initialization , for simple humans like me the scrolling it's too fast , tried blocking scroll, but is unusable

And the names cannot be fixed - they vary depending on how the hardware reacts during initialization. O

Thats why there is a "ROOT=" kernel command. There is no way to know ahead of time what the system drive will be named.

>They have just been named , it's not ahead of time ! I see them all during initialization , hda .... then sda , sdb , ...... sdx : the list is in ram , ready to be used !

And even "no partition" table still gets an entry in the partitions table - one that covers the entire disk.

Just look at any running system - if you cat the /proc/partitions file you will see something like:

Code:

$ cat /proc/partitions
major minor  #blocks  name

   8        0  244198584 sda
   8        1    1048576 sda1
   8        2  113185792 sda2
   8        3  113184768 sda3
   8        4          1 sda4
   8        5   16776192 sda5
   8       16 1953514584 sdb
   8       17  976757260 sdb1
   8       18  976757292 sdb2
   8       32  244198584 sdc
   8       33  244196001 sdc1
   8       48   58633344 sdd
   8       49   58629186 sdd1
  11        0    8233770 sr0

Note the entries for "sda","sdb","sdc",and "sdd". That entry would be the disk with no partition table to subdivide the disk.

>correct , even if unfortunately is unusable

Notice the oddity of sda sdb and sdc. sda and sdc are the same manufacturer and drive size... but sdb is a different manufacturer. The only reason sdb is named sdb is that it happens to come up ready sooner than sdc. And no rearrangement of cabling will fix that (tried, doesn't work). Not sure why sda even comes up first, it just does. sdd I understand (it really is a slow drive - an old ATA).

>correct : I also had to add a looooooooooooong delay , before trying to mount the boot sdx, the last of my disks comes up after 7 seconds

If you still need SCSI Ids, look in the directory /dev/disk/by-path.

>I'd like very much to have this option at boot , but unfortunately I don't have

Unfortunately, I believe these entries are created by udev. Without udev to identify the disks you may be out of luck - other than maybe using blkid to scan the partition table and read the extra information from the disks.

My conclusion so is : I'll give a look to udev source .

Thanks a lot

Have a nice Easter