[Solved]after sys upg fstab mounts fail on boot mount -a ok

[karog]

I upgraded with pacman -Syu an odroid-xu4 and an odroid-n2 last night. The following packages were upgraded on the n2.
$this->bbcode_second_pass_code('', '
[2019-04-24 00:35] [ALPM] upgraded libdrm (2.4.97-1 -> 2.4.98-1)
[2019-04-24 00:35] [ALPM] upgraded libuv (1.27.0-1 -> 1.28.0-1)
[2019-04-24 00:35] [ALPM] upgraded sqlite (3.27.2-1 -> 3.28.0-1)
[2019-04-24 00:35] [ALPM] upgraded systemd-libs (241.93-1 -> 242.0-1)
[2019-04-24 00:35] [ALPM] upgraded systemd (241.93-1 -> 242.0-1)
[2019-04-24 00:35] [ALPM] upgraded systemd-sysvcompat (241.93-1 -> 242.0-1)
[2019-04-24 00:35] [ALPM] upgraded thin-provisioning-tools (0.7.6-1 -> 0.8.0-1)
')

Upon reboot, fstab drives failed to mount. However, once rebooted, mount -a mounted them successfully. This is true for both the xu4 and the n2. This is repeatable. This did not happen before the upgrade.

Here is the dmesg output for the n2 when it finds the drive but does not mount it:
$this->bbcode_second_pass_code('', '[ 7.024907] scsi 0:0:0:0: Direct-Access WD My Passport 25E2 4004 PQ: 0 ANSI: 6
[ 7.028036] scsi 0:0:0:1: Enclosure WD SES Device 4004 PQ: 0 ANSI: 6
[ 7.069025] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 7.069114] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 7.069244] sd 0:0:0:0: [sda] 7813969920 512-byte logical blocks: (4.00 TB/3.64 TiB)
[ 7.069247] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 7.069457] sd 0:0:0:0: [sda] Write Protect is off
[ 7.069460] sd 0:0:0:0: [sda] Mode Sense: 47 00 10 08
[ 7.069671] sd 0:0:0:0: [sda] No Caching mode page found
[ 7.069674] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 7.070030] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 7.114326] scsi 0:0:0:1: Attached scsi generic sg1 type 13
[ 7.276785] audit: type=1130 audit(1556064522.020:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald c
omm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 7.294582] sda: sda1
[ 7.295483] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 7.301930] sd 0:0:0:0: [sda] Attached SCSI disk
')

Later after the mount -a, dmesg showed
$this->bbcode_second_pass_code('', '
[ 33.404766] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
')

Is this a bug in the newer systemd 242.0-1?

[RicoSalva]

$this->bbcode_second_pass_quote('karog', 'I') upgraded with pacman -Syu an odroid-xu4 and an odroid-n2 last night. The following packages were upgraded on the n2.
$this->bbcode_second_pass_code('', '
[2019-04-24 00:35] [ALPM] upgraded libdrm (2.4.97-1 -> 2.4.98-1)
[2019-04-24 00:35] [ALPM] upgraded libuv (1.27.0-1 -> 1.28.0-1)
[2019-04-24 00:35] [ALPM] upgraded sqlite (3.27.2-1 -> 3.28.0-1)
[2019-04-24 00:35] [ALPM] upgraded systemd-libs (241.93-1 -> 242.0-1)
[2019-04-24 00:35] [ALPM] upgraded systemd (241.93-1 -> 242.0-1)
[2019-04-24 00:35] [ALPM] upgraded systemd-sysvcompat (241.93-1 -> 242.0-1)
[2019-04-24 00:35] [ALPM] upgraded thin-provisioning-tools (0.7.6-1 -> 0.8.0-1)
')

Upon reboot, fstab drives failed to mount. However, once rebooted, mount -a mounted gimp freejobalert notepad++ them successfully. This is true for both the xu4 and the n2. This is repeatable. This did not happen before the upgrade.

Here is the dmesg output for the n2 when it finds the drive but does not mount it:
$this->bbcode_second_pass_code('', '[ 7.024907] scsi 0:0:0:0: Direct-Access WD My Passport 25E2 4004 PQ: 0 ANSI: 6
[ 7.028036] scsi 0:0:0:1: Enclosure WD SES Device 4004 PQ: 0 ANSI: 6
[ 7.069025] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 7.069114] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 7.069244] sd 0:0:0:0: [sda] 7813969920 512-byte logical blocks: (4.00 TB/3.64 TiB)
[ 7.069247] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 7.069457] sd 0:0:0:0: [sda] Write Protect is off
[ 7.069460] sd 0:0:0:0: [sda] Mode Sense: 47 00 10 08
[ 7.069671] sd 0:0:0:0: [sda] No Caching mode page found
[ 7.069674] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 7.070030] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 7.114326] scsi 0:0:0:1: Attached scsi generic sg1 type 13
[ 7.276785] audit: type=1130 audit(1556064522.020:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald c
omm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 7.294582] sda: sda1
[ 7.295483] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 7.301930] sd 0:0:0:0: [sda] Attached SCSI disk
')

Later after the mount -a, dmesg showed
$this->bbcode_second_pass_code('', '
[ 33.404766] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
')

Is this a bug in the newer systemd 242.0-1?

[karog]

I solved my problem. In fstab I am using x-systemd.device-timeout which I had set to 1 (second). It would seem that this threshold which has been fine for years, is no longer sufficient. Maybe the systemd changes somehow slowed things just enough. I changed the value to 3 and the disks now mount.