If the boot drive has not been unmounted cleanly, systemd will try to run fsck
at startup. On Leap 42.1 for aarch64, systemd will sometimes time-out mounting
the other partitions before the fsck operation on the root FS can complete, and
the boot process will fail and hang.

[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems.
[  OK  ] Started dracut pre-mount hook.
         Starting File System Check on /dev/disk/by-id/ata-SS...251316-part3...
[  OK  ] Started File System Check on /dev/disk/by-id/ata-SSD...57251316-part3.
         Mounting /sysroot...
[  OK  ] Mounted /sysroot.
[  OK  ] Reached target Initrd Root File System.
         Starting Reload Configuration from the Real Root...
[  OK  ] Started Reload Configuration from the Real Root.
[  OK  ] Reached target Initrd File Systems.
[  OK  ] Reached target Initrd Default Target.
[ TIME ] Timed out waiting for device dev-disk-by\x2did-ata\x...2dpart4.device.
[DEPEND] Dependency failed for /dev/disk/by-id/ata-SSD2SC120G...57251316-part4.
[DEPEND] Dependency failed for Swap.
[ TIME ] Timed out waiting for device dev-disk-by\x2did-ata\x...2dpart1.device.
[DEPEND] Dependency failed for /boot/efi.
[DEPEND] Dependency failed for Local File Systems.


If you reboot a few times, allowing fsck to continue and eventually finish[1],
you can then start up normally, but this is a manual process.

So it looks from the output above like mounting of filesystems is dependent on
the root filesystem, which is running an fsck. The fsck itself doesn't time
out, but the waiting for the root FS does.

This bug is similar to bug 955904, except that this bug refers to the boot
drive and has no workaround.

All this said, I tried to come up with a way to reproduce this
deterministically, but I cannot. Forcing fsck to run using various methods
doesn't make it run for long enough to cause a timeout.

Alan.

[1] It seems like fsck continues to run in the background if you leave the
machine on after the failure. If you leave it long enough, then reboot, it
comes up fine. I haven't been able to capture this during a session that didn't
have the "quiet" kernel command line parameter set.