Bug 67533 - systemd-206 fails to mount btrfs md rootfs
Summary: systemd-206 fails to mount btrfs md rootfs
Status: RESOLVED WORKSFORME
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-30 11:06 UTC by Florian Scandella
Modified: 2013-10-06 21:59 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
journalctl -b (151.04 KB, text/plain)
2013-07-30 11:06 UTC, Florian Scandella
Details

Description Florian Scandella 2013-07-30 11:06:59 UTC
Created attachment 83287 [details]
journalctl -b

i wrote a mail about this to the list (http://lists.freedesktop.org/archives/systemd-devel/2013-July/012377.html) but i think it's better to open a bug.

Basically, systemd tries to mount the rootfs before all the raid devices are ready (or registered with the btrfs module).

systemd opens a rescue shell which it immediately exits. It tries to mount rootfs a second time and succeeds.
Comment 1 Kay Sievers 2013-07-30 12:08:33 UTC
Just a guess: dracut as an initramfs might support a setup like that.

Systemd/udev itself has no real idea about MD devices and how they are
assembled/configured, or when they are ready to use.

Systemd should support multi-device btrfs volumes, native btrfs raid, properly out-of-the-box though.

If none of the above helps, you might need to seek help from someone who
knows and supports MD, systemd doesn't really, and there are no plans for
native MD support at the moment.
Comment 2 Florian Scandella 2013-07-30 18:48:04 UTC
sorry if that was not clear enough, i'm talking about native btrfs raid (on the btrfs page they call it btrfs multidevice-filesystem).

my guess what happens is, that the mount waits for the devices to get ready but that happens before the udev rule to register with btrfs gets called.

this is low priority because it actually works, boot takes about 10 sec longer because i get dumped to rescue shell and back early on, no manual intervention required.

in my older initrd i used btrfs device scan to register the drives but it seems this is no longer advocated on arch because udev should do that job.
Comment 3 Kay Sievers 2013-07-30 22:58:32 UTC
Ah fine, no MD.

What kind of initrd is that?

Does it have the needed rules and pieces included to make the btrfs devices
known to the kernel?
Comment 4 Florian Scandella 2013-07-30 23:10:45 UTC
I use mkinitcpio from arch/testing with the new systemd hook (so systemd handles the full boot process).

btrfs udev rules are included.

(extracted from initrd)

 ~/tmp/initrd/usr/lib/udev/rules.d $ cat 64-btrfs.rules 
# do not edit this file, it will be overwritten on update

SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION=="remove", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"

# let the kernel know about this btrfs filesystem, and check if it is complete
IMPORT{builtin}="btrfs ready $devnode"

# mark the device as not ready to be used by the system
ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"

LABEL="btrfs_end"
Comment 5 Florian Scandella 2013-07-30 23:17:57 UTC
i forgot to mention, /usr/bin/btrfs and the btrfs.ko module are also present
Comment 6 Lennart Poettering 2013-09-12 17:32:03 UTC
It's probably a good idea to ask the Arch initrd folks for help. My (Fedora) system is a btrfs multi-device setup, and it just works, but I cannot test this for non-FEdora/Dracut I fear.
Comment 7 Florian Scandella 2013-10-04 21:35:30 UTC
the problem is gone. i don't know what fixed it (upgrade to newer systemd or kernel) but the boot works without errors now.
Comment 8 Lennart Poettering 2013-10-06 21:59:52 UTC
OK closing then!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.