lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 698,7G 0 disk ├─sda1 8:1 0 65M 0 part /boot ├─sda2 8:2 0 4M 0 part ├─sda3 8:3 0 80M 0 part │ └─md0 9:0 0 84M 0 linear │ └─md0p1 259:0 0 80M 0 md ├─sda4 8:4 0 4,1G 0 part [SWAP] ├─sda5 8:5 0 13G 0 part / └─sda6 8:6 0 678G 0 part /home sr0 11:0 1 1024M 0 rom loop0 7:0 0 4M 0 loop └─md0 9:0 0 84M 0 linear └─md0p1 259:0 0 80M 0 md This setup is to enable me to access /dev/sda3 from within QEMU. loop0 points to an image file containing MBR, on the /home partition. Sometimes when I shutdown I forget to disassemble the md0 device, and systemd fails to do so automatically; on next boot, some file systems need to recover from their journals. A bit annoying. Apparently block-device dependency information like this is available to lsblk, and losetup -a will reveal which file a loop device points to. systemd could probably also make use of that.
Systemd does not support "fake block devices". This needs to be provided by the raid tools themselves and hook up into systemd. Most of the things are done today by (mostly weird) shell scrips provided by the distributions. Systemd has currently no plans to support MD or LVM natively. We provide minimal dis-assembly support for device-mapper volumes, something similar could probably be done for MD, but someone needs to do it, and it would need to be reasonable simple and not involve running daemons, calling-out to command line tools or linking against uncommon libraries. None of the main systemd developers I know uses any MD or LVM, so I have no idea who we could expect to do that.
During shutdown systemd (actually the shutdown binary) will attempt to destroy DM devices and loop devices, and unmount filesystems. So I'd think it should deal with this setup. Is this still a problem?
(In reply to comment #2) > During shutdown systemd (actually the shutdown binary) will attempt to > destroy DM devices and loop devices, and unmount filesystems. So I'd think > it should deal with this setup. Is this still a problem? Well, MD is not DM. And given that we detach all that stuff, I'd be open to adding a patch that does what we do for DM also for MD...
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.