Arch Linux

Without providing mkinitcpio config, this bug report is useless.

'lsinitcpio -a' output from the "broken" image is relevant, too.

# /etc/mkinitcpio.conf
MODULES="twofish_x86_64 xts"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata filesystems usbinput fsck encrypt"

Here is lsinitcpio -a output. I suspect the double "encrypt" under "Hook run order" is at fault.

Yep, I knew about this -- happens when the last hook in HOOKS has a runtime component. If you move something like 'sata' to the end and regenerate, it'll fix itself.

Needs to be fixed in cryptsetup.

That workaround works.

may be.
https://bugs.archlinux.org/task/30019

I stumbled into the same problem. However, i found a solution somewhere in the Arch BBS (sorry, link is lost), about a similiar problem:

1) Boot by using the old method in your kernel line: "root=/dev/sdxx" instead of "cryptdevice=/dev/sdxx:root root=/dev/mapper/root". It will complain that it is deprecated, but it will boot.
2) Change the order of the HOOKS: Move "encrypt" at least in front of "filesystems" (don't forget "keymap", if needed).
3) Create a new initrd and reboot with the correct kernel line.

This solves it for me.

Yes, thank you for reiterating what I already stated.

The only way I'm willing to "fix" this in mkinitcpio is to remove the deprecated API usage that causes this (which core/cryptsetup uses). I've already fixed this in testing/cryptsetup.

David Reisner (falconindy) wrote at Saturday, 26 May 2012:

> Yes, thank you for reiterating what I already stated.

I am not shure if there is some undertone in your sentence, however, i just wanted to help, so: You're welcome.

I'm running an encrypted mdadm raid and got the same problem this morning.
Downgrading to mkinitcpio-0.8.8-1 linux-3.3.6-1 and udev-182-2 as suggested by OP didn't fix the problem.
Neither did putting sata to the end of hooks in mkinitcpio.conf.
After installing cryptsetup from testing recreating the initrd doesn't complete smoothly.

-> Parsing hook: [encrypt]
/usr/lib/initcpio/install/encrypt: line 12: add_all_modules: command not found
/usr/lib/initcpio/install/encrypt: line 22: add_runscript: command not found

Am I missing something..? Any suggestions how to fix this?
Thanks in advance.

If you change your config, you must recreate your initramfs for the changes to take effect. Downgrading is not a solution. With the cryptsetup and mdadm packages in testing, this bug doesn't exist.

After installing mdadm from testing and with re-upgraded packages I can create the initramfs without errors but I'm still being dumped to rootfs during boot.

Your description is neither useful, nor related to this bug.

Ok the thing is, I'm not sure about opening a new bug report for a maybe slightly different bug.
Nearly everything is the same I updated these packages and it won't boot anymore due to misbehavior of cryptsetup.
I'll explain this and you can tell me whether it is a different bug or not, as I said I'm not sure and don't want to fill the Bug tracker with garbage.

I have an encrypted mdadm raid and use udev rules and an usbstick to automatically open my Luks encrypted volumegroup during boot.
Since the recent changes I'm being dropped to a recovery shell due to my root device being unable to find.
I don't get any other error messages besides that one.
During the [mdadm] hook being "mdadm: dev/md/0 has been started with 2 drives." is being echoed as always and the "running hook [encrypt]" section
prints "Waiting 10 seconds for device /dev/md/0 . . .".
In the [lvm2] section my root cannot be found and I'm being dropped to the recovery shell.

Edit: without the stick inserted I'm not even getting prompted for my passphrase it is just being displayed that the device could not be found and "Keyfile could not be opened. Reverting to passphrase." But I never get a chance to enter it and being dropped to rootfs again.

By using the last stable live CD I could normally open my raid (while using the key from my usbstick) and was able to apply the suggested upgrades of mdadm and cryptsetup from testing and recreated my initramfs (/boot /proc /sys /dev were mounted). But the problem still exists and I'm going out of ideas.

Please tell me whether this issue should get it's own bug report or not.

Sure whatever, I'll deal with it here. Posting the actual image and your config is needed.

Allright, here we go.

I asked for the image itself, because it makes things much easier to troubleshoot. You won't be able to attach it here.

You appear to be cherry picking from testing which is completely unsupported. Versions of lvm, udev, and mdadm are relevant.

Sorry I got that wrong. Here is the image http://www.2shared.com/file/2ky9SyXk/initramfs-linux.html

And I'm using lvm2-2.02.95-4 udev-182-4 and mdadm-3.2.5-2

mdadm is from testing, and so is cryptsetup... but the rest of it isn't. This is entirely unsupported.

I tried that to fix the issues but it didn't.
The problem occured and still occures when using cryptsetup-1.4.2-1 and mdadm-3.4.2-1 , too.

Great. I can't help you until you pick a repo. I'm not dealing with these sorts of problems when there's major rebuilds in testing and version bumps that involve most of these packages.

Sorry I didn't want to bother you I just kinda got the impression from the comments in this report that getting cryptsetup and mdadm from testing is suggested to fix it.
No other package on my machine is from testing and now I installed only main repo packages and recreated the initramfs.
Here is the initramfs generated completely without stuff from testing being installed.
http://www.2shared.com/file/fwctk3wY/initramfs-linux.html

...a fix for an unrelated issue. The initramfs you posted is fine, and entirely capable of booting the setup you describe. You'll need to dig around in early userspace and figure out what's failing.

Ok, thanks nevertheless. I hope I'll figure it out soon, I'm kinda out of ideas because there aren't any more error messages or hints.