Bug 508384

This seems to be a duplicate of bug #457870

I saw bug 457870 before opening this bug report, and agree that the underlying cause is probably the same (mkinitrd does not look at /etc/modprobe.d/). But that bug is discussing something rather different - in that case the problem is that mkinitrd does not copy modprobe configuration from the OS to the initrd, whereas in this case the problem is that mkinitrd is not extracting module names (regardless of their options) from the configuration, resulting in an unbootable system. Thus, I felt it warranted a separate bug report. Of course, if the maintainer wishes to combine the two bugs, that's fine.

(In reply to comment #2)
> I saw bug 457870 before opening this bug report, and agree that the underlying
> cause is probably the same (mkinitrd does not look at /etc/modprobe.d/). But
> that bug is discussing something rather different - in that case the problem is
> that mkinitrd does not copy modprobe configuration from the OS to the initrd,
> whereas in this case the problem is that mkinitrd is not extracting module
> names (regardless of their options) from the configuration, resulting in an
> unbootable system. Thus, I felt it warranted a separate bug report. Of course,
> if the maintainer wishes to combine the two bugs, that's fine.  

Ok, so to get this clear, the issue you have is (as you state in the initial description) that the module does not get included into the initrd, right ?

That is not a bug, well atleast the not automatically putting all modules
which have a scsi_hostadapter alies in the initrd is not a bug.

What mkinitrd does is:
1) look at /etc/fstab and see what is specified as device for /
2) resolve this to a device (in case of LABEL=... or UUID=...)
3) goto /sys/block/<device>
4) look for slaves in there:
   ls /sys/block/<device>/slaves
   and for each slave read the device link and then look at the modalias for
   the device and include the matching module in the initrd
5) For the device itself see if there is a device link and look at the modalias
6) If there is no device link go up a level in the dir hierarchy (after
   following the symlink) and repeat this until there is a device link

This way it should find all modules needed for your / filesystem without
needing to look at module aliases.

Can you please explain your problem in more detail (what sort of
filesystem / blockdevice is your / on, which module is not being loaded).

And can you please run:
mkinitrd -f -v test.img $(uname -r) &> log1
bash -x /sbin/mkinitrd -f test.img $(uname -r) &> log2

And attach the 2 resulting log files ? Thanks!

---

Notice that mkinitrd will be replaced with dracut in F-12, and your
time thus may be better spend testing that instead, see:
http://fedoraproject.org/wiki/Dracut
http://fedoraproject.org/wiki/Features/Dracut
http://www.harald-hoyer.de/personal/blog/dracut-0.3

(In reply to comment #3)
> Ok, so to get this clear, the issue you have is (as you state in the initial
> description) that the module does not get included into the initrd, right ?

Exactly.

> That is not a bug, well atleast the not automatically putting all modules
> which have a scsi_hostadapter alies in the initrd is not a bug.

I found the mkinitrd manpage a little misleading here, since it does say that it parses scsi_hostadapter entries (albeit only from /etc/modprobe.conf, which worked on F10 but not any more in F11, since that was moved to /etc/modprobe.d/local.conf).

> What mkinitrd does is:
> 1) look at /etc/fstab and see what is specified as device for /
> 2) resolve this to a device (in case of LABEL=... or UUID=...)
> 3) goto /sys/block/<device>
> 4) look for slaves in there:
>    ls /sys/block/<device>/slaves
>    and for each slave read the device link and then look at the modalias for
>    the device and include the matching module in the initrd
> 5) For the device itself see if there is a device link and look at the modalias
> 6) If there is no device link go up a level in the dir hierarchy (after
>    following the symlink) and repeat this until there is a device link

Thanks for the info - that is very clear.

> This way it should find all modules needed for your / filesystem without
> needing to look at module aliases.

Right, except that my system is cursed with a HighPoint RAID, needing a custom kernel module (hptmv). And the procedure you describe above maps the fstab to a pci:<something> entry but then fails to find any module for that, since hptmv contains no aliases. The workaround before for this was to add a scsi_hostadapter entry to /etc/modprobe.conf ensure the root filesystem module was loaded.

Using your hints above, I patched the source code for the hptmv kernel module to add a suitable MODULE_ALIAS, so now mkinitrd and depmod will pick up the alias correctly. Thanks for your assistance!

(In reply to comment #4)
> I found the mkinitrd manpage a little misleading here, since it does say that
> it parses scsi_hostadapter entries (albeit only from /etc/modprobe.conf, which
> worked on F10 but not any more in F11, since that was moved to
> /etc/modprobe.d/local.conf).
> 

Ah, how right you are, the manpage needs updating wrt this. I'll put that on
my to do list (although very low priority as, as explained mkinitrd is being
replaced).

<snip>

> Using your hints above, I patched the source code for the hptmv kernel module
> to add a suitable MODULE_ALIAS, so now mkinitrd and depmod will pick up the
> alias correctly. Thanks for your assistance!  

Ah, well that MODULE_ALIAS should be there anyways, even when not used for /, so
that the module get auto loaded by udev bad hptmv driver!

Given that you have a very special setup, it would be great if you could
test dracut (the mkinitrd replacement) with it, for more info on dracut see:
http://fedoraproject.org/wiki/Dracut
http://fedoraproject.org/wiki/Features/Dracut

For testing instructions for using dracut on F-11 see:
http://www.harald-hoyer.de/personal/blog/dracut-0.3