Bug 966956 - dracut hostonly generates initramfs without networking drivers
dracut hostonly generates initramfs without networking drivers
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F19Blocker/F19FinalBlocker
  Show dependency treegraph
 
Reported: 2013-05-24 07:32 EDT by Kamil Páral
Modified: 2013-05-29 07:28 EDT (History)
6 users (show)

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


Attachments (Terms of Use)
system info from fpaste (12.29 KB, text/plain)
2013-05-24 07:34 EDT, Kamil Páral
no flags Details
lspci -nn (2.55 KB, text/plain)
2013-05-24 07:34 EDT, Kamil Páral
no flags Details
lsusb (382 bytes, text/plain)
2013-05-24 07:35 EDT, Kamil Páral
no flags Details
dracut log of "dracut -f -H -L 5 hostonly.img" (8.90 KB, text/plain)
2013-05-24 07:35 EDT, Kamil Páral
no flags Details
lsinitrd hostonly.img (66.30 KB, text/plain)
2013-05-24 07:36 EDT, Kamil Páral
no flags Details
dracut log of "dracut -f -N -L 5 nohostonly.img" (19.91 KB, text/plain)
2013-05-24 07:36 EDT, Kamil Páral
no flags Details
lsinitrd nohostonly.img (231.05 KB, text/plain)
2013-05-24 07:36 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2013-05-24 07:32:46 EDT
Description of problem:
A fresh installation of F19 Beta (RC4) x86_64 netinst. After boot, there are no network devices (neither wired nor wifi), although they were visible during the installation. If I reboot to a rescue mode, the network devices are detected OK. After closer inspection, in the standard boot mode there are no kernel modules for the network devices (e1000e and iwlwifi).

If I install dracut-nohostonly and re-install kernel (regenerate initrafms), the issue is fixed and the network devices are detected in a standard (non-rescue) boot mode.

Version-Release number of selected component (if applicable):
kernel-3.9.3-301.fc19.x86_64
dracut-027-46.git20130430.fc19.x86_64
ThinkPad X201

How reproducible:
always

Steps to Reproduce:
1. a default network installation
2. no kernel modules wrt to network devices on system boot

Actual results:
current hardware modules are not included in initramfs

Expected results:
current hardware modules are included in initramfs

Additional info:
Comment 1 Kamil Páral 2013-05-24 07:34:21 EDT
Created attachment 752550 [details]
system info from fpaste
Comment 2 Kamil Páral 2013-05-24 07:34:46 EDT
Created attachment 752551 [details]
lspci -nn
Comment 3 Kamil Páral 2013-05-24 07:35:04 EDT
Created attachment 752552 [details]
lsusb
Comment 4 Kamil Páral 2013-05-24 07:35:43 EDT
Created attachment 752553 [details]
dracut log of "dracut -f -H -L 5 hostonly.img"
Comment 5 Kamil Páral 2013-05-24 07:36:12 EDT
Created attachment 752555 [details]
lsinitrd hostonly.img
Comment 6 Kamil Páral 2013-05-24 07:36:38 EDT
Created attachment 752556 [details]
dracut log of "dracut -f -N -L 5 nohostonly.img"
Comment 7 Kamil Páral 2013-05-24 07:36:58 EDT
Created attachment 752558 [details]
lsinitrd nohostonly.img
Comment 8 Kamil Páral 2013-05-24 07:39:08 EDT
This might be hardware specific (I haven't seen this issue apart from this ThinkPad X201), but it makes the system unusable, at least in the networking sense (most probably other important drivers were missing too, would have to double check). Proposing for FinalBlocker discussion.
Comment 9 Kamil Páral 2013-05-28 05:09:38 EDT
Dominic Hopf [1] is said to have a similar problem, in his case the kernel modules for disk decryption were not included. It might probably be the same cause. I asked him to check this bug, try to produce similar hostonly and nohostonly images and comment here.

[1] http://fedoraproject.org/wiki/User:Dmaphy
Comment 10 Harald Hoyer 2013-05-28 10:04:14 EDT
Do you need network in the initramfs for your root filesystem?

Normally, when you don't need network to mount your root filesystem, udevd should load the network drivers after the initramfs has done its job and the boot continues in the real root.

If that is not the case, then we might have a selinux problem??
Comment 11 Harald Hoyer 2013-05-28 10:05:07 EDT
(In reply to Kamil Páral from comment #9)
> Dominic Hopf [1] is said to have a similar problem, in his case the kernel
> modules for disk decryption were not included. It might probably be the same
> cause. I asked him to check this bug, try to produce similar hostonly and
> nohostonly images and comment here.
> 
> [1] http://fedoraproject.org/wiki/User:Dmaphy

That would be a different bug, and I really would like to see a bug report for that, to fix this bug.
Comment 12 Dominic Hopf 2013-05-28 18:27:18 EDT
(In reply to Harald Hoyer from comment #11)
> (In reply to Kamil Páral from comment #9)
> > Dominic Hopf [1] is said to have a similar problem, in his case the kernel
> > modules for disk decryption were not included. It might probably be the same
> > cause. I asked him to check this bug, try to produce similar hostonly and
> > nohostonly images and comment here.
> > 
> > [1] http://fedoraproject.org/wiki/User:Dmaphy
> 
> That would be a different bug, and I really would like to see a bug report
> for that, to fix this bug.

It's true that I stumbled over some issues when I upgraded to Fedora 19 Alpha in Berlin last week. I do not really consider this as an issue with Fedora 19 Alpha, though. I have the fedora-rawhide-kernel-nodebug repository active on my system and the kernels not booting were installed from that repository. The Fedora 19 Kernel booted without issues. Updating to kernel-3.10.0-0.rc3.git0.2.fc20.x86_64 and re-generating the initramfs for that kernel version solved the issue for me today. Let me know if you'd like to see this reported anyway.
Comment 13 Kamil Páral 2013-05-29 07:28:46 EDT
I have tried to reproduce the issue to get some useful logs and now everything works, even with hostonly image! I have no idea why, probably a kernel or systemd update fixed it. I checked that selinux wasn't updated in the meantime.

Since I can't reproduce, I'm closing this bug. Thanks, Harald, for your help.

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