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:
Created attachment 752550 [details] system info from fpaste
Created attachment 752551 [details] lspci -nn
Created attachment 752552 [details] lsusb
Created attachment 752553 [details] dracut log of "dracut -f -H -L 5 hostonly.img"
Created attachment 752555 [details] lsinitrd hostonly.img
Created attachment 752556 [details] dracut log of "dracut -f -N -L 5 nohostonly.img"
Created attachment 752558 [details] lsinitrd nohostonly.img
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.
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
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??
(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.
(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.
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.