http://bugzilla.opensuse.org/show_bug.cgi?id=955904 Bug ID: 955904 Summary: after 13.2 -> leap 42.1 upgrade, systemd-controlled fsck of large arrays times out, drops to emergency mode Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: 9b3e05a5@opayq.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I've upgraded a server Opensuse 13.2 -> Leap 42.1 The server has several large (> 10TB) RAID-10 arrays, directly attached via SATA-3. The arrays have been recently/cleanly fsck'd from a rescue disk. The arrays' "passno" in /etc/fstab is set to "2". No cmd line parameter is set, so systemd's systemd-fsck@.service should default to fsck.mode="auto" fsck.repair="preen" Under Opensuse 13.2, all drives' boot-time fsck's, including for these large arrays, occurred at systemd-controlled intervals, and never had any issues. Now, under Leap 42.1, an @boot-time fsck of the large array FAILs ... [ *** ] A start job is running for dev-VG_NAS1-LV-NAS1.devic...13s / 1min 30s) [ TIME ] Timed out waiting for device dev-VG_NAS1-LV_NAS1.device. [DEPEND] Dependency failed for /NAS/NAS1. [DEPEND] Dependency failed for Local File Systems. Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. Give root password for maintenance (or press Control-D to continue): Here, I can login, enter the password ... then check
pvscan | grep VG_NAS1 PV /dev/md2 VG VG_NAS1 lvm2 [5.46 TiB / 0 free] vgscan | grep VG_NAS1 Found volume group "VG_NAS1" using metadata type lvm2 lvscan | grep VG_NAS1 inactive '/dev/VG_NAS1/LV_NAS1' [5.46 TiB] inherit grep VG_NAS1 /etc/fstab /dev/VG_NAS1/LV_NAS1 /NAS/NAS1 ext4 relatime,acl,user_xattr,journal_checksum,barrier=1 0 2 mount /dev/VG_NAS1/LV_NAS1 mount: special device /dev/VG_NAS1/LV_NAS1 does not exist
The fsck does not occur on every boot ... when it doesn't, the system boots successfully. Using boot-time kernel command line parameters, systemd-fsck@.service can DISABLE fsck checks for ALL drives Changing 'passno' in fstab can (?) DISABLE fsck for ONE drive/mount. Neither is acceptable. Those fsck's should be able to be enabled AND not fail for large arrays. -- You are receiving this mail because: You are on the CC list for the bug.