Bump. System is unbootable with 219 release. Raising importance.

Looks like that applying this patch:
https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-dependencies-to-dynamically-mo.patch

allows to mount devices.

Ping anyone ?

(In reply to Tomasz Paweł Gajc from comment #2)
> Looks like that applying this patch:
> https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-
> dependencies-to-dynamically-mo.patch
> 
> allows to mount devices.

Thank you very much, this patch helps me, I am doubt why upstream don't fix this problem.

This is a bad bug. 

Please see my report on the Arch Linux bug tracker on it here: https://bugs.archlinux.org/task/44658#comment134665

This report is using systemd from Arch's [testing] repo which seems to be version 219 with some patches applied by the Arch maintainers which try to address this bug: systemd 219-6, https://www.archlinux.org/packages/testing/x86_64/systemd/

In summary, even when the bug has been "fixed" (allowing mounts to be made again) there are cases when systemd is unmounting things it should not be when the user runs umount (seems like it unmounts ALL mounts associated with a device whenever any mount associated with that device is umounted).

A bug that breaks filesystem mouting/unmounting seems particularly critical. Whatever new logic 219 introduced that created this bug should probably be reverted from the systemd release until all the mounting and unmounting corner cases can be tested and covered.

Another use case to complement the report:

- system is a home server running Arch linux, full disk encrypted with dmcrypt/LUKS and remotely unlocked via dropbear_initrd_encrypt [1]
- it was updated today with the latest systemd packages ({lib}systemd{-sysvcompat} 219-5) and latest linux-lts (3.14.39), therefore the initramfs was rebuilt with mkinitcpio.

What happens: after rebooting I am locked out at the initramfs stage with the following error messages:

- on client trying to ssh in dropbear_initrd:
    Device /dev/disk/by-id/wwn-<redacted_id>-part3 doesn't exist or access denied.

- on server:
   Running systemd 219
(dropbear initialization sequence, everything is ok)
    Starting dropbear
    [123] Apr 23 09:43:56 Running in background
(try to connect remotely via SSH)
    Pubkey auth succeeded for 'root' with key xxx from 192.xxx
    syslogin_perform_logout: logout(pts/0) returned an error: No such file or directory
    Exit (root) Disconnect received
    ERROR: device '/dev/mapper/lvm-archroot' not found. Skipping fsck.
    ERROR: Unable to find rot device '/dev/mapper/lvm-archroot'
    You are being dropped to a recovery shell

If I don't try to login via SSH there is a 15 seconds delay between [123] line and the first ERROR; there is no mean whatsoever to unlock dropbear locally as used to be the case ("enter passphrase for /dev/disk/by-id/wwn-<redacted_id>-part" used to be displayed).

My kernel command line is BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper/lvm-archroot rw quiet cryptdevice=/dev/disk/by-id/wwn-<redacted_id>-part3:crypt ip=192.168.1.xxx::192.168.1.254::arch-medion:eth0:none

[1] https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Remote_unlocking_of_the_root_.28or_other.29_partition

Created attachment 115298 [details] [review]
Proposed patch

With this patch systemd does not umounts manually mounted devices

Lennart recently fixed the recognition of state "tenative" devices, which might help with this, i. e. not declaring such devices as "dead" and trying to unmount them: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f62009410 

It would be great if you could try this patch, on top of the v219-stable branch.

Thanks for the hint. I'll try systemd wit this patch applied today and give feedback.

I was unable to test this patch, as it is not a simple "oneliner" second this commit does not apply on systemd 219. Would be nice if someone backported this commit and related to it other commits to systemd-stable/219

As mentioned, this should be fixed in git since a while ago. Closing hence.

*** Bug 89768 has been marked as a duplicate of this bug. ***

*** Bug 90131 has been marked as a duplicate of this bug. ***