Am 17.10.2017 um 18:10 schrieb Michael Biebl: Hi Michael,
> Bernhard, could you try to run a git bisect to find the relevant change > which broke fsck for you. > https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/log/disk-utils/fsck.c?h=stable/v2.30 > > There aren't that many changes for fsck. There are only two commits over 2.29 and they don't look related at all. Maybe in a library. I'll try to find time to bisect it on the weekend or at least try to make a testcase on a fresh VM. I did some more tests today and found the reason. util-linux 2.29 + systemd 234-3: works fine util-linux 2.29 + systemd 235-2: works fine util-linux 2.30 + systemd 234-3: boot stalls completely util-linux 2.30 + systemd 235-2: login prompt eventually appears, root login is possible, user login hangs Accessing /home leads to a blocked process. The reason is that (for numerous years, due to reasons I don't remember) I had x-systemd.automount in my fstab for /home /dev/mapper/homecrypt /home btrfs relatime,x-systemd.automount 0 2 so at this point /home is already "mounted" with autofs. systemd-1 on /home type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12282) but access is blocked until the real fs is mounted. Which will only happen after the fsck has completed, which is blocked open()ing the mountpoint. Removing x-systemd.automount fixes this behaviour. Bernhard
