http://bugzilla.opensuse.org/show_bug.cgi?id=912170
Andrei Borzenkov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arvidjaar@gmail.com,
| |jeffm@suse.com
Component|Kernel |Basesystem
Assignee|kernel-maintainers@forge.pr |systemd-maintainers@suse.de
|ovo.novell.com |
--- Comment #2 from Andrei Borzenkov ---
Yes, I can reproduce it. Setup - two encrypted containers and btrfs on them as
raid0 for both data and metadata.
The bug is in patch
1060-udev-use-device-mapper-target-name-for-btrfs-device-ready.patch. When
btrfs builtin runs, /dev/mapper link is not yet created so builtin fails. This
results in SYSTEMD_READY being not set and systemd attempts immediately mount
multi-device filesystem without second device being available.
1392 open("/dev/btrfs-control", O_RDWR|O_CLOEXEC) = 7
1392 ioctl(7, BTRFS_IOC_DEVICES_READY, 0x7ffff80a3520) = -1 ENOENT (No such
file or directory)
Cc'ing Jeff who was the author of patch. I am not sure what the statement
--><--
If the device is a DM device, udev will have already cached the table name
from sysfs and we can use that to pass /dev/mapper/<name> to the builtin
so that the correct name is used.
--><--
is based on - as far as I can tell, udev is passing argument verbatim, without
doing any processing. Nor do I understand what problem was supposed to be fixed
here.
@Ryan - as a workaround, copy /usr/lib/udev/rules.d/64-btrfs.rules into
/etc/udev/rules.d/64-btrfs.rules and replace the following two lines
ENV{DM_NAME}=="", IMPORT{builtin}="btrfs ready $devnode"
ENV{DM_NAME}=="?*", IMPORT{builtin}="btrfs ready /dev/mapper/$env{DM_NAME}"
with single one
IMPORT{builtin}="btrfs ready $devnode"
If you will have *any* issues, please mention them here.
--
You are receiving this mail because:
You are on the CC list for the bug.