I have onboard SATA controller, and also an additional RAID controller card:

00:17.0 SATA controller: Intel Corporation Device a282
04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3108 [Invader] (rev 02)

When linux kernel boots, disks connected on the LSI raid controller are recognized/enumerated first (sda,sdb,...), and disk hanging on the SATA controller after that (sde).

My kernel is monolithic, without loadable modules. Is it possible to tell the kernel, the disk on the SATA controller should be first (sda) ?

What affects the order? Is this just an accident, that LSI raid is recognized first, or can this be changed?

  • 1
    Can you use an initrd? If so, referencing the partitions using UUID or LABEL might be an easier choice. PARTUUID may work if not, according to this thread. – ErikF Oct 24 '20 at 5:39
  • @ErikF - thanks, but referencing partitions by UUID will not solve my problem. I need the SATA disk to be first (/dev/sda). – 400 the Cat Oct 26 '20 at 5:31
  • Order is first come first served. You can unbind and bind through the sysfs interface (in initramfs, when drives are not yet in use), but you really need to stop relying on drive names. There's too many cases where they can go out of order, so just don't rely on it. – frostschutz Oct 26 '20 at 19:58

I was looking into something similar in the past - changing the order of the disks and the network cards for a monolithic kernel.

The order how the drivers are loaded gets decided during compilation - by initcall_levels (from lower to higher, include/linux/init.h) and then by positions in the Makefiles.

I do not think there is much room for playing with initcall_levels - there are too many dependencies.

SATA level 4 in drivers/ata/libata-core.c at subsys_initcall(ata_init)

MEGASAS level 6 in drivers/scsi/megaraid/megaraid_sas_base.cat module_init(megasas_init)

Pointers in System.map:

ffffffff829545cd t megasas_init
ffffffff8295547c t ata_init
ffffffff829e7688 t __initcall_megasas_init6
ffffffff829e8288 t __initcall_ata_init4

Changing the order in the Makefile should be an option, for example in drivers/net/ethernet/intel/Makefile switching the lines for e1000 and e1000e will change the order for eth0 and eth1 (using net.ifnames=0)

obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_E1000E) += e1000e/

So in drivers/Makefile moving ata before scsi

obj-$(CONFIG_ATA)               += ata/
obj-y                           += scsi/

should change the order of the host controllers (SATAs first). Check by

ls -l /sys/class/scsi_host/

But even when having SATA as host0 the disks at LSI controller were found first, I am not sure how the asynchronous SCSI probe works, but adding a little delay (e.g. 700 ms) somewhere at the beginning of megasas_init() in drivers/scsi/megaraid/megaraid_sas_base.c made the SATA disk to be /dev/sda

static int __init megasas_init(void)
        int rval;

I hope it does not cause any issues in the kernel, it worked for me but be careful. Of course there are dependencies, not everything is possible. For example I know when I tried mptsas (drivers/message/fusion/) before scsi, it would compile, but the kernel immediately crashed at boot.

Hope this helps.

  • this works! Thank you so much! – 400 the Cat Oct 28 '20 at 3:51
  • what is the chance, that by moving ata before scsi in drivers/Makefile, this could cause some unintended consequences? – 400 the Cat Oct 28 '20 at 3:54

The only way to achieve this without udev is to change the order of the drivers the kernel loads. Since you want to use a "monolithic" kernel, this is probably not that easy. If you would have the drivers loaded as modules, you could change the order of the modules per /etc/modprobe.*, but this only helps as long as the disks need different drivers. If you add another disk using the same driver, you will have the same problem again.

On systems using systemd-udev it is not possible anymore to change the device-name to a different sd* like you could before (or maybe on current non-systemd-distributions like OpenRC on gentoo or alpine or SysVInit on devuan, …)

Why is it necessary to have the device named as /dev/sda? Can't you use /dev/disk/by-*/* or write you own udev-rules to generate your own symlinks? What distribution are you using?

some links:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.