+++ This bug was initially created as a clone of Bug #1067669 +++
Description of problem:
Dracut identifies kernel modules for block devices in
90kernel-modules/installkernel by a list of symbols.
One of the symbols is "blk_init_queue", which in the past lead to the inclusion of virtio_blk.ko for vm guests.
In kernel 3.13 virtio_blk calls the new function blk_mq_init_queue rather than blk_init_queue and thus the symbol match fails and virtio_blk is not included any more.
That way vm guests configured vor virtio_blk fail to boot kernel 3.13 unless virtio_blk is included for other reasons.
Please add symbol "blk_mq_init_queue" to the list of symbols next to "blk_init_queue" in 90kernel-modules/installkernel.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Fix suggested within above description.
--- Additional comment from Akemi Yagi on 2014-02-21 03:03:27 EST ---
I was having a boot problem on my KVM guest that uses virtio (host=RHEL 6.5 and guest=CentOS 6.5, kernel 3.13). This bug report explains the cause quite well. I created initramfs with a '--add-drivers virtio_blk' option and the kernel booted just fine.
--- Additional comment from Fedora Update System on 2014-04-02 04:57:28 EDT ---
dracut-037-10.git20140402.fc20 has been submitted as an update for Fedora 20.
--- Additional comment from Fedora Update System on 2014-04-03 00:03:52 EDT ---
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-037-10.git20140402.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
--- Additional comment from Fedora Update System on 2014-04-05 22:37:41 EDT ---
dracut-037-10.git20140402.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This prevents ELRepo's kernel-ml from booting on EL6.
As Akemi Yagi noted in the Fedora bug, this can be worked around manully by rebuilding the initramfs with '--add-drivers virtio_blk' added to the dracut line.
As Thorsten Kohfeldt noted in the upstream bug, this can be permanently worked around with:
echo 'add_drivers+="virtio_blk"' >/etc/dracut.conf.d/force-vitio_blk-to-ensure-boot.conf
Please consider including this dracut change in RHEL 6 so that downstream CentOS can consume it, as the CentOS community is no doubt the largest consumer of ELRepo's kernel packages.
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release. Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.
bug 1041484 changed to blk_cleanup_queue, which will pickup virtio_blk
*** This bug has been marked as a duplicate of bug 1041484 ***
Harald -- You have closed this report (request) as a duplicate of 1041484. That is perfectly sensible. However when I attempt to view bug 1041484 I am now denied access. Please add me to the CC list of bug 1041484.
(In reply to Alan Bartlett from comment #5)
> Harald -- You have closed this report (request) as a duplicate of 1041484.
> That is perfectly sensible. However when I attempt to view bug 1041484 I am
> now denied access. Please add me to the CC list of bug 1041484.