Bug 797322 - dracut Warning: Unable to process initqueue
Summary: dracut Warning: Unable to process initqueue
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Rajnoha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-24 22:46 UTC by Tom
Modified: 2012-03-08 08:24 UTC (History)
20 users (show)

Fixed In Version: lvm2-2.02.94-1.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 799535 (view as bug list)
Environment:
Last Closed: 2012-03-08 08:24:26 UTC
Type: ---
Embargoed:


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

Description Tom 2012-02-24 22:46:08 UTC
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:
1.Update
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 06:50:36 UTC
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 06:53:25 UTC
Created attachment 565725 [details]
nonbooting dmesg

Comment 3 Josh Boyer 2012-02-25 12:51:08 UTC
(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 16:13:47 UTC
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 16:14:49 UTC
Created attachment 565778 [details]
yum history

Comment 6 Tom 2012-02-25 16:15:37 UTC
Created attachment 565779 [details]
Working dmesg

Comment 7 Zhang Hongjiu 2012-02-26 16:28:28 UTC
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 16:29:14 UTC
s/argument/device name

Sorry

Comment 9 Josh Boyer 2012-02-26 16:51:11 UTC
Harald, is this something dracut needs to adjust to, or something the LVM team needs to fix?

Comment 10 Tom 2012-02-26 22:13:45 UTC
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 09:19:40 UTC
(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 22:04:34 UTC
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 22:52:32 UTC
3ffe9aa27d7dfb1bb8f06152e0097b437e4845b9 is the first bad commit
commit 3ffe9aa27d7dfb1bb8f06152e0097b437e4845b9
Author: Peter Rajnoha <prajnoha>
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-28 00:38:25 UTC
Regression.  Blocker for 2.02.94.

Comment 15 Alasdair Kergon 2012-02-28 00:55:38 UTC
(Easy fix.  2.02.94 is due around Wednesday this week.)

Comment 16 Peter Rajnoha 2012-02-28 08:40:35 UTC
Fix checked in.


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