RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 619771 - kmod modules from driver disk are not included in initrd
Summary: kmod modules from driver disk are not included in initrd
Keywords:
Status: CLOSED DUPLICATE of bug 622641
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Martin Sivák
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 619745
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-30 13:52 UTC by Martin Wilck
Modified: 2010-08-10 06:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-10 06:34:09 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed patch on top of my patch for bug #619745 (attachment #435538) (1.70 KB, patch)
2010-07-30 13:52 UTC, Martin Wilck 		no flags Details | Diff
View All

Description Martin Wilck 2010-07-30 13:52:39 UTC 
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

How reproducible:
always

Steps to Reproduce:
1. install system that needs driver from dd
  
Actual results:
driver from kmod is not included in the initramfs of the installed system


Expected results:
drivers from kmod need to be included in the initramfs of the installed system

Additional info:
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].
Comment 1 Martin Wilck 2010-07-30 13:56:43 UTC 
Typo :-( 

At the top of the description, it should read "attachment #435538 [details]", not
"attachment #435558 [details]". I am sorry.
Comment 2 Martin Wilck 2010-07-30 13:57:57 UTC 
Thus attachment #435538 [details] fixes problem 1., and attachment #435562 [details] fixes 2. and 3.
Comment 3 Martin Wilck 2010-07-30 14:05:37 UTC 
This is a Fujitsu blocker. Opened IT 1208353.
Comment 4 Martin Wilck 2010-07-30 14:08:32 UTC 
We verified that with both patches applied, the dd installation completes successfully.
Comment 6 RHEL Program Management 2010-07-30 14:28:13 UTC 
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. **
Comment 7 Jon Masters 2010-08-02 17:11:10 UTC 
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.

Jon.
Comment 8 Chris Lumens 2010-08-02 18:32:46 UTC 
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.
Comment 9 Martin Wilck 2010-08-03 08:41:22 UTC 
(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.
Comment 10 Martin Wilck 2010-08-03 08:48:46 UTC 
(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
> here.    

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.
Comment 12 Martin Sivák 2010-08-09 09:31:18 UTC 
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.
Comment 13 Jon Masters 2010-08-09 22:35:55 UTC 
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?

Jon.
Comment 14 Jon Masters 2010-08-10 03:10:05 UTC 
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:

https://bugzilla.redhat.com/show_bug.cgi?id=622641

Thanks again to Martin Wilck for helping to find that problem. I am requesting that this be fixed in the next compose if possible.

Jon.
Comment 15 Jon Masters 2010-08-10 03:11:20 UTC 
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.

Jon.
Comment 16 Jon Masters 2010-08-10 06:34:09 UTC 

*** This bug has been marked as a duplicate of bug 622641 ***
Note You need to log in before you can comment on or make changes to this bug.