Bug 788662 - F17 won't boot in VM with virtio disks after upgrade to udev-181-1
Summary: F17 won't boot in VM with virtio disks after upgrade to udev-181-1
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: udev-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 494832
TreeView+ depends on / blocked
 
Reported: 2012-02-08 18:15 UTC by Tim Flink
Modified: 2012-03-06 19:06 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-10 22:24:58 UTC
Type: ---
Embargoed:


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

Description Tim Flink 2012-02-08 18:15:06 UTC
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 18:30:22 UTC
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 18:36:36 UTC
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 18:43:05 UTC
(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 18:43:51 UTC
Created attachment 560341 [details]
console log of failed boot with virtio disks

Comment 5 Tim Flink 2012-02-08 18:49:19 UTC
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 21:28:01 UTC
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 22:37:34 UTC
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 22:38:09 UTC
Created attachment 560726 [details]
bootlog before udev upgrade

Comment 9 Tim Flink 2012-02-09 22:38:53 UTC
Created attachment 560727 [details]
bootlog after udev upgrade

Comment 10 Harald Hoyer 2012-02-10 09:31:10 UTC
you need kmod-5-6.fc17.x86_64

Comment 11 Harald Hoyer 2012-02-10 09:31:51 UTC
(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 22:24:58 UTC
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.