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: