This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 508384 - mkinitrd does not pick up scsi_hostadapter entries in /etc/modprobe.d/
mkinitrd does not pick up scsi_hostadapter entries in /etc/modprobe.d/
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-26 16:19 EDT by Ben Webb
Modified: 2009-07-06 14:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-06 14:14:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Webb 2009-06-26 16:19:37 EDT
Description of problem:
After upgrading to F11, my system would no longer boot. I discovered that this is because mkinitrd no longer adds modules for my scsi_hostadapter entry. In turn, this is because in Fedora 11, this entry has moved from /etc/modprobe.conf to /etc/modprobe.d/local.conf. mkinitrd does not scan this file - or any file in /etc/modprobe.d/, as far as I can tell - for scsi_hostadapter entries. (This is consistent with the mkinitrd manpage, but I would prefer to have a bootable system ;)

Version-Release number of selected component (if applicable):
mkinitrd-6.0.86-2.fc11.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Edit /etc/modprobe.d/local.conf and add a scsi_hostadapter line.
2. Build an initrd with mkinitrd -v.
  
Actual results:
mkinitrd -v output does not include the scsi_hostadapter module, and it is not included in the initrd.

Expected results:
The initrd *does* include the module.

Additional info:
As a workaround, if I copy /etc/modprobe.d/local.conf to /etc/modprobe.conf before running mkinitrd, everything works correctly.
Comment 1 Gerd v. Egidy 2009-07-04 19:48:17 EDT
This seems to be a duplicate of bug #457870
Comment 2 Ben Webb 2009-07-04 20:21:43 EDT
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.
Comment 3 Hans de Goede 2009-07-06 05:18:14 EDT
(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
Comment 4 Ben Webb 2009-07-06 14:05:24 EDT
(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!
Comment 5 Hans de Goede 2009-07-06 14:13:57 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.