Red Hat Bugzilla – Full Text Bug Listing
|Summary:||F17 won't boot in VM with virtio disks after upgrade to udev-181-1|
|Product:||[Fedora] Fedora||Reporter:||Tim Flink <tflink>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||gansalmon, harald, itamar, jonathan, kernel-maint, madhu.chinakonda, pcfe, udev-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-02-10 17:24:58 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Tim Flink 2012-02-08 13:15:06 EST
Description of problem: When I install F17 into a VM using virtio disks, no block devices are found and the VM is unable to boot. The install pulled in kernel-3.3.0-0.rc2.git4.1.fc17 but I'm seeing the same thing if I update to kernel-3.3.0-0.rc2.git6.1.fc17 If I downgrade the kernel to 3.3.0-0.rc2.git3.2.fc17, the VM works fine with virtio. If I change the VM's disk to use ATA emulation, it successfully boots with any of these kernels. Version-Release number of selected component (if applicable): kernel-3.3.0-0.rc2.git6.1.fc17 How reproducible: Every time Steps to Reproduce: 1. boot a VM with virtio disks using latest f17 kernel Actual results: boot fails - dracut can't find any block devices to boot from Expected results: successful boot
Comment 1 Josh Boyer 2012-02-08 13:30:22 EST
There's really nothing related to virtio or the block layer or scsi or anything else at all that sounds like this issue between 3.3-rc2-git3.2 and 3.3-rc2-git4.1. Those represent upstream commits 7f06db34e55af8fc33cf3d6d46d869cb7a372b5d 23783f817bceedd6d4e549385e3f400ea64059e5 respectively. Out of curiosity, did you update dracut or something else between those kernel versions? If you rebuild the 3.3-rc2-git3.2 initramfs on your updated VM, does that then fail to boot as well?
Comment 2 Josh Boyer 2012-02-08 13:36:36 EST
Aside from that, dmesg for boot with both would be good, along with rd.info and maybe rd.debug on the kernel command line.
Comment 3 Tim Flink 2012-02-08 13:43:05 EST
(In reply to comment #1) > Out of curiosity, did you update dracut or something else between those kernel > versions? If you rebuild the 3.3-rc2-git3.2 initramfs on your updated VM, does > that then fail to boot as well? I did update dracut but I'm pretty sure that I did that before installing any of the other kernels. I'll try again to be sure, though
Comment 4 Tim Flink 2012-02-08 13:43:51 EST
Created attachment 560341 [details] console log of failed boot with virtio disks
Comment 5 Tim Flink 2012-02-08 13:49:19 EST
This is odd, I did a re-install into a VM using an IDE disk and post-install, everything booted without a problem. When I changed the same disk to virtio, it still boots without a problem. I'm going to dig into this a bit more to see if I can pinpoint the actual cause of these problems.
Comment 6 Tim Flink 2012-02-08 16:28:01 EST
I've been able to reproduce in a VM using a virtio disk. I'm using a custom built install iso to do the initial install and later changes in rescue mode. - Do F17 install with minimal package set & reboot - dracut can't find root volume - rebuild initramfs from anaconda rescue env & reboot - dracut can't find root volume - install newest dracut and rebuild initramfs inside rescue env & reboot - dracut can't find root volume - reinstall 3.3-rc2-git6.1 in rescue env & reboot - dracut can't find root volume - downgrade kernel to 3.3-rc2-git4.1 * grubby fatal error: unable to find a suitable template * manually ran grub2-mkconfig - dracut can't find root volume - downgrade kernel to 3.3-rc2-git3.2 * grubby fatal error: unable to find a suitable template * manually ran grub2-mkconfig - dracut can't find root volume - downgrade dracut to 014-81.git20120202.fc17, force initramfs rebuild, reboot - dracut can't find root volume So it looks like this isn't a kernel issue, I must have changed something else in the first VM. I'm going to keep digging into this, will update/change this bug as I find out more.
Comment 7 Tim Flink 2012-02-09 17:37:34 EST
After some more testing, I think that I've narrowed the problem down to udev. kmod is pulled in during the same update but I assume it isn't involved since an initramfs rebuild is required. I've been able to reproduce this on multiple F16 virthosts. Before Update: udev-180-3.fc17.x86_64 kmod-4-1.fc17.x86_64 dracut-014-81-git20120202.fc17 At this point, the VM boots without any trouble Update: udev-181-1.fc17.x86_64 kmod-5-4.fc17.x86_64 If I reboot after updating, the vm boots without trouble. However, once I rebuild the initramfs and reboot, dracut can't find the root volume.
Comment 8 Tim Flink 2012-02-09 17:38:09 EST
Created attachment 560726 [details] bootlog before udev upgrade
Comment 9 Tim Flink 2012-02-09 17:38:53 EST
Created attachment 560727 [details] bootlog after udev upgrade
Comment 10 Harald Hoyer 2012-02-10 04:31:10 EST
you need kmod-5-6.fc17.x86_64
Comment 11 Harald Hoyer 2012-02-10 04:31:51 EST
(In reply to comment #10) > you need kmod-5-6.fc17.x86_64 and you need to recreate the initramfs after updating
Comment 12 Tim Flink 2012-02-10 17:24:58 EST
Confirmed fixed with TC2 minimal install on VM with virtio disk