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.