Bug 797322 - dracut Warning: Unable to process initqueue
dracut Warning: Unable to process initqueue
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-02-24 17:46 EST by Tom
Modified: 2012-03-08 03:24 EST (History)
20 users (show)

See Also:
Fixed In Version: lvm2-2.02.94-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 799535 (view as bug list)
Last Closed: 2012-03-08 03:24:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
nonbooting dmesg (123.19 KB, text/plain)
2012-02-25 01:53 EST, Tom
no flags Details
yum history (15.71 KB, text/plain)
2012-02-25 11:14 EST, Tom
no flags Details
Working dmesg (123.96 KB, text/plain)
2012-02-25 11:15 EST, Tom
no flags Details

  None (edit)
Description Tom 2012-02-24 17:46:08 EST
Description of problem:

Device does not exist.
Command failed.
dracut Warning: Unable to process initqueue
Dropping to debug shell.

Version-Release number of selected component (if applicable):
kernels 3.3.0-0.rc4.git3.1 and git1.2 will not boot.

How reproducible:
Everytime I try to boot with last two kernels, but older kernel git0.1 works.

Steps to Reproduce:
2.Fails to boot with last two kernels
3.Boots with older kernel
Actual results:

Expected results:

Additional info:
I have an encrypted hard drive and selinux set to permissive.
Comment 1 Tom 2012-02-25 01:50:36 EST
Trying 'dracut -f' stops older kernel from booting as well.
Attached nonbooting dmesg with rd.debug added and rhgb removed.
Comment 2 Tom 2012-02-25 01:53:25 EST
Created attachment 565725 [details]
nonbooting dmesg
Comment 3 Josh Boyer 2012-02-25 07:51:08 EST
(In reply to comment #1)
> Trying 'dracut -f' stops older kernel from booting as well.
> Attached nonbooting dmesg with rd.debug added and rhgb removed.

What kernel version is this?

Did udev, dracut, or device-mapper get updated around or before the kernels that have a problem?  If rc4.git0.1 works, it might be using an older version of the userspace tools in the initramfs.

Basically, dracut is failing to setup the device mapper devices that are used for your LVs.  It says it can't find /dev/dm-*, which is odd.

Can you capture the full boot log for the machine?
Comment 4 Tom 2012-02-25 11:13:47 EST
Attached yum history and dmesg from last working boot. 

I can only chroot into my system now, since I haven't been able to get the dracut instructions to work for me. http://fedoraproject.org/wiki/How_to_debug_Dracut_problems#Accessing_the_root_volume_from_the_dracut_shell
Comment 5 Tom 2012-02-25 11:14:49 EST
Created attachment 565778 [details]
yum history
Comment 6 Tom 2012-02-25 11:15:37 EST
Created attachment 565779 [details]
Working dmesg
Comment 7 Zhang Hongjiu 2012-02-26 11:28:28 EST
I experience this problem on Gentoo Linux. It seems that /sbin/dmsetup from lvm2-2.02.92 no longer works with argument like "/dev/dm-0", which should work with 2.02.88.
Comment 8 Zhang Hongjiu 2012-02-26 11:29:14 EST
s/argument/device name

Comment 9 Josh Boyer 2012-02-26 11:51:11 EST
Harald, is this something dracut needs to adjust to, or something the LVM team needs to fix?
Comment 10 Tom 2012-02-26 17:13:45 EST
Boots for now since I took the 'rd.luks.uuid= ' line out of the kernel grub command, and simplified /etc/fstab without uuid.
Comment 11 Harald Hoyer 2012-02-27 04:19:40 EST
(In reply to comment #9)
> Harald, is this something dracut needs to adjust to, or something the LVM team
> needs to fix?

I would like to have a comment from the LVM team, why the behaviour changed.
Comment 12 Milan Broz 2012-02-27 17:04:34 EST
What exactly changed?

I tried "dmsetup table /dev/dm-X" which fails now (dmsetup table /dev/mapper/<name> still works, IMHO it is bug in dmsetup...

(You should not use dm-X devices directly, these are not static, but that is different issue...)
Comment 13 Milan Broz 2012-02-27 17:52:32 EST
3ffe9aa27d7dfb1bb8f06152e0097b437e4845b9 is the first bad commit
commit 3ffe9aa27d7dfb1bb8f06152e0097b437e4845b9
Author: Peter Rajnoha <prajnoha@redhat.com>
Date:   Wed Feb 15 11:27:01 2012 +0000

    Mangle device name on dm_task_set_name/newname call if necessary.

Peter, please can you check and fix it?
Comment 14 Alasdair Kergon 2012-02-27 19:38:25 EST
Regression.  Blocker for 2.02.94.
Comment 15 Alasdair Kergon 2012-02-27 19:55:38 EST
(Easy fix.  2.02.94 is due around Wednesday this week.)
Comment 16 Peter Rajnoha 2012-02-28 03:40:35 EST
Fix checked in.

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