This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 788662 - F17 won't boot in VM with virtio disks after upgrade to udev-181-1
F17 won't boot in VM with virtio disks after upgrade to udev-181-1
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: udev-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 494832
  Show dependency treegraph
 
Reported: 2012-02-08 13:15 EST by Tim Flink
Modified: 2012-03-06 14:06 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-10 17:24:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
console log of failed boot with virtio disks (149.64 KB, text/plain)
2012-02-08 13:43 EST, Tim Flink
no flags Details
bootlog before udev upgrade (32.99 KB, text/plain)
2012-02-09 17:38 EST, Tim Flink
no flags Details
bootlog after udev upgrade (22.06 KB, text/plain)
2012-02-09 17:38 EST, Tim Flink
no flags Details

  None (edit)
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

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