Starting with this info ...

Slackware 15 64bit clean install fully updated
two disks /dev/sda /dev/sdb

used mdadm to create array:

/dev/md0 as /boot partition RAID1
/dev/md1 as / partition RAID10
/dev/md2 as /home partition RAID10

generated initrd using:
mkinitrd -c -k 5.15.27 -f ext4 -r /dev/md1 -m jbd2:mbcache:ext4 -R -u -o /boot/initrd.gz and added to lilo.conf followed by running lilo

lilo.conf (key items) boot = /dev/md0 raid-extra-boot = "mbr-only"

If booting the 'huge' kernel the system comes up fine.

If booting the 'generic' kernel, the system fails to boot with ... no /sbin/init ... Trouble ahead during boot and system stopping there and rendered unresponsive.

(As an aside, another machine Slackware 14.2 setup the same way raid wise etc, boots fine both huge and generic)

Please, what might the huge kernel boot be loading/doing that is missing in the generic boot leading to it failing to boot and what would be a way to identify differences ?


Thank you

I'd use lsmod (on working kernel) to identify the module responsible for loading the root disk.
When found, you could include it to initrd image. Or make a custom kernel which includes the relevant module.
It's likely some raid module that is missing in your generic kernel.. but I've never used raid so I can't say which one.

i have tried that (lsmod) since posting and did not notice any obvious raid related module or difference that stood out as a possibility. I will have another look though.

I'm now wondering if it is a setting in kernel config. Perhaps I should try find any differences in those (huge and generic) related to raid or loading disks.

Certainly, previously I've not had to do any customisation towards mkinitrd (using /usr/share/mkinitrd/mkinitrd_command_generator.sh) once it did its thing. Perhaps generator.sh and Slackware 15 are out of sync somewhere from previous; I have no basis for this at the moment though.

Thank you for the reply.

It could be a SATA controller driver that is compiled-in huge kernel and not in generic.
If lsmod does not show a difference, maybe see with lspci the SATA controller name.
The huge kernel usually has all of them compiled-in, even the unstable ones.

Or it might be an upstream change in the kernel that caused it, there was many changes from 4.4 to 5.15

Try adding a "wait" period '-w 1' or '-w 2' in your mkinitrd command. When I used mdadm in the past the RAID partitions needed the extra time time to setup.

Hope that helps...

Thank you for the comments.

I managed to get the issue sorted and a generic kernel is now booting with RAID. I suspect it was an issues that something somewhere relating to RAID/mdadm was not being captured when generating the initrd as hinted at in the comments received. Exactly what it was I cannot say as I made the mistake of not trying one adjustment at a time, but I had ensured that mdadm.conf contained correct devices and array entries and I had run one or two madadm commands prior to mkinird commands (using the -w as suggested) and it seemed to sort the issue.