[systemd-bugs] [Bug 88483] New: btrfs raid on plain dmcrypt fails to boot randomly
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Jan 15 23:01:04 PST 2015
https://bugs.freedesktop.org/show_bug.cgi?id=88483
Bug ID: 88483
Summary: btrfs raid on plain dmcrypt fails to boot randomly
Product: systemd
Version: unspecified
Hardware: All
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: general
Assignee: systemd-bugs at lists.freedesktop.org
Reporter: palmaway at gmx.it
QA Contact: systemd-bugs at lists.freedesktop.org
I run an up-to-date Archlinux (x64). My configuration is as follows: 3 disks
encrypted with plain dmcrypt, on top of which there is a btrfs RAID5
filesystem. The disks are decrypted at boot through /etc/crypttab using 3 key
files, producing the devices:
/dev/mapper/crypt[a,b,c]
Then a single entry in /etc/fstab mounts the btrfs filesystem.
At boot, only one of the devices is found (systemd message "systemd[1]: Found
device /dev/mapper/cryptX."). Which one is found among the three is random, and
changes at every boot. I suspect this is due to the devices sharing the same
label and uuid because of btrfs, as explained here:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011400.html
The configuration fails to boot producing a "A start job is running for"
message for the remaining devices at any time the device found by systemd is
not the right one. By "right one" I mean:
- in case in fstab I use a specific device, that one. The messages for the
remaining devices have no timeout, so they block the boot process indefinitely,
and a reboot is necessary. Chances to boot correctly are therefore 1/3.
- in case I use the label or uuid shared by the devices, then
/dev/mapper/cryptc (the last one being decrypted by the crypttab). In this
case, there are 3 "start job" messages: one related to the
/dev/disk-by-[label/uuid] and the two relative to the remaining devices as
above. Chances to boot correctly are therefore lower, but the /dev/disk-by-
message does have a timeout (1:30 minutes) and produces an emergency shell
after that.
I tried:
- to create a .mount file in /etc/systemd/system (which takes precedence over
the fstab line) as suggested in
https://bbs.archlinux.org/viewtopic.php?id=146708 . It always boots correctly,
but it doesn't mount the filesystem correctly with the same probability. It
simply fails silently.
- to add the "device=" option for the 3 devices among the fstab mount options,
and even to create a systemd service that runs after cyptsetup.target and
before local-fs-pre.target to force a "btrfs device scan" as suggested here:
https://unix.stackexchange.com/questions/120907/arch-does-not-mount-btrfs-array-on-boot
. Unfortunately, neither of these solve the problem.
Based on the above, I think the problem (bug) is systemd only finding one of
the devices. My guess is that it happens because they share the same label and
uuid (see the first link).
The btrfs filesystem is used for storage, it is not system related and for
various reasons it is not advisable to have it decrypted with the mkinitcpio
hooks (sd-encrypt and btrfs).
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20150116/8f82ff65/attachment.html>
More information about the systemd-bugs
mailing list