В Fri, 3 Apr 2015 21:19:24 +0300 Mantas Mikulėnas <[email protected]> пишет:
> Previously udev used to undo mounts when a device *disappeared;* when > systemd took over the task, it started unmounting things as soon as it > noticed that the device *doesn't exist right now.* While similar, the new > behavior can be annoying, since it also triggers if the device never > existed in the first place. For example: > > ~ My fstab has "/dev/mapper/luks-backups → /mnt/backup". I want to mount > another disk there (which has a different label), but even though `mount > /dev/sdb1 /mnt/backup` succeeds, the directory remains empty and won't show > up in `findmnt`. > > After a few retries I check dmesg and notice systemd saying that > "mnt-backup.mount is bound to an inactive device; stopping". Which means, > if my fstab says disk X is mounted there, systemd won't let me mount > anything else but disk X at that location. > > ~ I had to boot to emergency mode due to reasons, and attempted to mount > /boot & /boot/efi in order to fix something. Since my fstab had > "/dev/disk/by-partlabel/boot → /boot", any attempts to mount anything at > /boot get immediately undone – emergency mode has no udev, so I get > "boot.mount is bound to an inactive device; stopping" all over again. > Do these commits help? commit 628c89cc68ab96fce2de7ebba5933725d147aecc Author: Lennart Poettering <[email protected]> Date: Fri Feb 27 21:55:08 2015 +0100 core: rework device state logic This change introduces a new state "tentative" for device units. Device units are considered "plugged" when udev announced them, "dead" when they are not available in the kernel, and "tentative" when they are referenced in /proc/self/mountinfo or /proc/swaps but not (yet) announced via udev. This should fix a race when device nodes (like loop devices) are created and immediately mounted. Previously, systemd might end up seeing the mount unit before the device, and would thus pull down the mount because its BindTo dependency on the device would not be fulfilled. commit 496068a8288084ab3ecf8b179a8403ecff1a6be8 Author: Martin Pitt <[email protected]> Date: Fri Mar 13 08:35:59 2015 +0100 core: don't change removed devices to state "tentative" Commit 628c89c introduced the "tentative" device state, which caused devices to go from "plugged" to "tentative" on a remove uevent. This breaks the cleanup of stale mounts (see commit 3b48ce4), as that only applies to "dead" devices. The "tentative" state only really makes sense on adding a device when we don't know where it was coming from (i. e. not from udev). But when we get a device removal from udev we definitively know that it's gone, so change the device state back to "dead" as before 628c89c. > So I need to either use a different mount path, or manually start > udevd.service and run `udevadm trigger`. (Which, by the way, also fsck's > and mounts everything else from my fstab – which I was kinda hoping to > avoid, with fsckd being broken and all that.) > > ~ Ah, yeah, and if dbus isn't running, systemctl spews out this: > > Error getting authority: Error initializing authority: Could not connect: > > No such file or directory (g-io-error-quark, 1) > > _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
