http://bugzilla.suse.com/show_bug.cgi?id=990325 Bug ID: 990325 Summary: fsck at boot times out, preventing boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: aarch64 OS: openSUSE 42.1 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: alan@softiron.co.uk QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- 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. -- You are receiving this mail because: You are on the CC list for the bug.