KLV-Airedale-sr8, Kernel messes with sda sdb order

[miltonx]

This is my grub boot menu:

Code: Select all

search --no-floppy --set=root --label a2
linux /klv8/vmlinuz w_bootfrom=/mnt/sda2/klv8 w_changes=RAM2
initrd /klv8/initrd.gz
}

Sometimes it boots, sometimems kernel panics, failing to find /mnt/sda2/klv8.
After testing, I found that /dev/sda and /dev/sdb are randomly allocated. (I have an SSD and a hard disk). My boot parameter was aiming at the SSD, which has 4 partitions, with KLV on 2nd partition's /klv8 folder. The hard disk has one. When the SSD is detected as sda, boots fine. When the hard drive gets detected first, booting fails.

I know that this can easily be solved by changing the boot parameter to:

Code: Select all

w_bootfrom=LABEL=a2=/mnt/sda2/klv8
w_bootfrom=UUID=xxxxxxx=/mnt/sda2/klv8

However, since I have never experienced similar issue when using fossapup64 with "pupsfs=sda2" boot parameter, so I did some search, and some say this is determined by kernel, which does not sort sda sdb... persistently. So far this sounds to be the case, but I'm not sure. I read through fossapup64 initramfs's init file, and did not find any code that seems to do anything to sort the /dev/sd? order.

For those who know about kernel compilation, is there any config that determines how the kernel sorts and names devices?

[wiak]

I know that this can easily be solved by changing the boot parameter to:

Code: Select all

w_bootfrom=LABEL=a2=/mnt/sda2/klv8
w_bootfrom=UUID=xxxxxxx=/mnt/sda2/klv8

Regarding the above two lines... almost correct, but should be this:

Code: Select all

w_bootfrom=LABEL=a2=/klv8
w_bootfrom=UUID=xxxxxxx=/klv8

You don't refer to the partition with /mnt/sda2 (as you say the underlying system can randomly change that, which is why using either UUID or LABEL is more reliable), the UUID or LABEL indicates the correct partition and the last part of w_bootfrom is the path to the frugal install directory not including the partition in this usage.

[miltonx]

Regarding the above two lines... almost correct, but should be this:

Code: Select all

w_bootfrom=LABEL=a2=/klv8
w_bootfrom=UUID=xxxxxxx=/klv8

You don't refer to the partition with /mnt/sda2 (as you say the underlying system can randomly change that, which is why using either UUID or LABEL is more reliable), the UUID or LABEL indicates the correct partition and the last part of w_bootfrom is the path to the frugal install directory not including the partition in this usage.

Yes, thanks. I was sloppy when posting this.

But now the issue of Kernel randomly ordering disks is not solved. It seems that different versions of kernel behaves differently on this. But I guess there may be some workaround. In my case, there are two disks in my laptop, one SSD and another HDD. I hope the SSD can always be registered as /dev/sda. Is it possible to manipulate the initramfs init script to load the SSD's module first, and then the HDD later, so that the former is always /dev/sda? (But I'm not sure whether kernel modules can differentiate between a SSd and a HDD. And even less sure whether kernel sets sda, sdb... after the device is detected or after the module driver is loaded.)

[wiak]

re: changing order of loading of some modules.

I'm far from computer just on android phone just now. However, partly from memory:

If you are booting a KL distro via huge kernel, that has media drivers built in so not loading modules as part of boot process anyway. I have no idea how kernel detects/orders the underlying hardware or if some kernel boot parameter allows you to manipulate that order sorry.

If using a version of Firstrib initrd that includes modules to allow booting with non-huge kernel, the module loading has to occur very early so that is done in the compressed initrd and not in the easily edited external w_init part. However, there is a mechanism included that provides for removing load of some modules, and a similar provision for adding extra modules. It is thus possible to prevent loading of any set of default modules and then adding them at the end of the load process in whatever order you wish. The grub kernel line arguments for these two effects are something like w_rmmodule= along with w_addmodule= but I'd have to check the correct argument names since I think I dont have their names quite correct above.

You would of course have to work out which modules you want to try loading in different order, and I have no idea myself if that would result in sdaX being tied to any particular drive thereafter. Rather, I always rely on booting via partition uuid or partition LABEL

[miltonx]

I checked the drivers for the SSD and HDD, by this command:

Code: Select all

udevadm info -a -n /dev/sda | grep -i driver
udevadm info -a -n /dev/sdb | grep -i driver

Unfortunately they use identical modules, ie sd_mod and ahci. So there is no way to load one's module earlier than the other.
But then I started to do some tinkering. To my surprise, when I modifed firstrib init's modprobe lines from:

Code: Select all

for m in mbcache exportfs ext4 fat vfat ntfs3 fuse isofs nls_cp437 nls_iso8859-1 nls_utf8 reiserfs squashfs xfs libata ahci libahci sata_sil24 pdc_adma sata_qstor sata_sx4 ata_piix sata_mv sata_nv sata_promise sata_sil sata_sis sata_svw sata_uli sata_via sata_vsc pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5520 pata_cs5530 pata_cs5535 pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_netcell pata_ns87415 pata_oldpiix pata_pdc2027x pata_pdc202xx_old pata_rdc pata_sc1200 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pata_isapnp pata_mpiix pata_ns87410 pata_opti pata_rz1000 ata_generic loop cdrom hid hid_generic usbhid mptscsih mptspi mptsas tifm_core cb710 mmc_block mmc_core sdhci sdhci-pci wbsd tifm_sd cb710-mmc via-sdmmc vub300 sdhci-pltfm scsi_mod scsi_transport_spi scsi_transport_sas sd_mod sr_mod usb-common usbcore ehci-hcd ehci-pci ohci-hcd uhci-hcd xhci-pci xhci-hcd usb-storage xts uas nvme overlay; do
	modprobe $m 2>/dev/null
done

to:

Code: Select all

modprobe sd_mod
modprobe ahci
for m in mbcache exportfs ext4 fat vfat ntfs3 fuse isofs nls_cp437 nls_iso8859-1 nls_utf8 reiserfs squashfs xfs libata ahci libahci sata_sil24 pdc_adma sata_qstor sata_sx4 ata_piix sata_mv sata_nv sata_promise sata_sil sata_sis sata_svw sata_uli sata_via sata_vsc pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5520 pata_cs5530 pata_cs5535 pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_netcell pata_ns87415 pata_oldpiix pata_pdc2027x pata_pdc202xx_old pata_rdc pata_sc1200 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pata_isapnp pata_mpiix pata_ns87410 pata_opti pata_rz1000 ata_generic loop cdrom hid hid_generic usbhid mptscsih mptspi mptsas tifm_core cb710 mmc_block mmc_core sdhci sdhci-pci wbsd tifm_sd cb710-mmc via-sdmmc vub300 sdhci-pltfm scsi_mod scsi_transport_spi scsi_transport_sas sd_mod sr_mod usb-common usbcore ehci-hcd ehci-pci ohci-hcd uhci-hcd xhci-pci xhci-hcd usb-storage xts uas nvme overlay; do
	modprobe $m 2>/dev/null
done

NB: picked out the sd_mod and ahci and probed them beforehand (without bothering to remove them from the long list). Then the problem is solved. Kernel always places the SSD first. I guess it was the long module loading list put the hardware detection kind of out of order. Singling out the disk modules and loading them first avoided that.

However, since the SSD is much faster than HDD, I'm not sure this solution would transfer to other cases, eg. when both disks are HDD or SSD.