Created attachment 435562 [details]
proposed patch on top of my patch for bug #619745 (attachment #435538 [details])
Description of problem:
kmod modules from driver disk are not included in initrd
Version-Release number of selected component (if applicable):
RHEL6 beta2 snap8
Steps to Reproduce:
1. install system that needs driver from dd
driver from kmod is not included in the initramfs of the installed system
drivers from kmod need to be included in the initramfs of the installed system
This problem is normally shadowed by bug #619745.
There are 3 problems here.
1. bug #619745 causes the kmods not to be installed on the target system
2. new-kernel-pkg needs to be started with the --host-only option (-> -H option to dracut), otherwise 3rd-party modules will not be included in the initrd
3. the backend needs to know that there are driver disk modules to be installed. This currently works only if the modules are in the anaconda.id.extraModules list.
I am attaching a fix that stacks on top of my patch attachment #435538 [details].
At the top of the description, it should read "attachment #435538 [details]", not
"attachment #435558 [details]". I am sorry.
Thus attachment #435538 [details] fixes problem 1., and attachment #435562 [details] fixes 2. and 3.
This is a Fujitsu blocker. Opened IT 1208353.
We verified that with both patches applied, the dd installation completes successfully.
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Martin. The first patch makes sense, but I'm not sure why you want to explicitly tell dracut to run with --host-only. The default option should be *more* inclusive than that, and we don't run with --host-only in other cases (in which drivers are correctly installed). So, can you ellaborate on that for us please?
Our internal Anaconda folks are looking into this.
I don't see the necessity for this patch. The extraModules list should populated by loader and passed to anaconda in order to tell anaconda which driver disk modules have been loaded. In other words, it would do exactly what you want it to.
However it looks like it's not currently being set up by loader, so that needs to be fixed. I don't believe we need to introduce yet another flag variable here.
(In reply to comment #7)
> Martin. The first patch makes sense, but I'm not sure why you want to
> explicitly tell dracut to run with --host-only. The default option should be
> *more* inclusive than that, and we don't run with --host-only in other cases
> (in which drivers are correctly installed). So, can you ellaborate on that for
> us please?
Without --host-only, dracut looks for modules only under /lib/modules/`uname -r`/kernel/, and thus doesn't find DUD modules that are installed under .../extras/ (you can verify that in the dracut source).
It would be possible to change that of course, but I felt that would be a graver change that what I did.
(In reply to comment #8)
> I don't see the necessity for this patch. The extraModules list should
> populated by loader and passed to anaconda in order to tell anaconda which
> driver disk modules have been loaded. In other words, it would do exactly what
> you want it to.
> However it looks like it's not currently being set up by loader, so that needs
> to be fixed. I don't believe we need to introduce yet another flag variable
That makes sense. I saw the "extraModules" mechanism in place but loader currently doesn't use it (it doesn't pass --module args to anaconda). Using "extraModules" properly would also solve bu #619745.
I wasn't sure which one of the two possible ways (1. isys.modulesWithPaths(), 2. anaconda.id.extraModules) loader was supposed to use to pass DUD information to anaconda, and I focused on 1.) to solve the practical problem I was having.
However let me make one remark - I'd personally prefer isys.modulesWithPaths() because I think it's cleaner than relying on command line args. The isys.modulesWithPaths() call shows unambiguously which modules are being used at installation time, implying that these modules are compatible with the RHEL6 kernel. I think that's actually better than using the extraModules list. Just my $0.02.
Chris, we cannot populate extraModules easily, because udev handles the loading for us now. So there is no other way of distinguishing new and old modules, than the one we fix in #619745.
We cannot even move the logic to earlier stage, because udev migh be loading new drivers for us during stage2 now. The patches make sense, but can be cleaned up a bit.
I'm missing something with the host-only stuff. We don't call dracut that way post-install, and it does correctly pick up the right directories when doing a generic build. Anyway, a "generic" build should be more inclusive, not less. Why is there something specifically different during install that results in dracut behaving differently from other calls after installation?
I've done a lot more digging on this. I feel that it is necessary to change dracut because the initramfs is rebuilt at other times also, and it should be scanning the updates for bootpath drivers. Consequently, I have filed the following bug against dracut, in which I explain the *one line* fix:
Thanks again to Martin Wilck for helping to find that problem. I am requesting that this be fixed in the next compose if possible.
I was wrong in comment 13. It was reported as working, but I fear that was mistaken as a consequence of either another bug or just bad data. In any case, the dracut source in dracut-functions clearly does need to be fixed.
*** This bug has been marked as a duplicate of bug 622641 ***