1

[Arch system on UEFI / GPT boot]

Every time I boot, my box' root volume (located in its own ext4 partition) is re-mounted, something that (I think) never occurred before my last update (kernel 5.8.5 -> 5.9.3).

My corresponding /etc/fstab line is:

UUID=xxxxxxxxxxxxxxxxxxxxxxxx   /   ext4   errors=remount-ro,relatime,data=ordered,acl,user_xattr   0 1

The only related journal log entries are included below. They start with a trace of the first mount logged, and end with the trace log of the re-mount (with no intervening log entries in journalctl -b output):

Nov 06 09:35:27 HOST kernel: EXT4-fs (nvme0n1p8): mounted filesystem with ordered data mode. Opts: (null)
Nov 06 09:35:27 HOST systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
Nov 06 09:35:27 HOST systemd[1]: Mounting Huge Pages File System...
Nov 06 09:35:27 HOST systemd[1]: Mounting POSIX Message Queue File System...
Nov 06 09:35:27 HOST systemd[1]: Mounting Kernel Debug File System...
Nov 06 09:35:27 HOST systemd[1]: Mounting Kernel Trace File System...
Nov 06 09:35:27 HOST systemd[1]: Condition check resulted in File System Check on Root Device being skipped.
Nov 06 09:35:27 HOST systemd[1]: Starting Remount Root and Kernel File Systems...
Nov 06 09:35:27 HOST systemd[1]: Mounted Huge Pages File System.
Nov 06 09:35:27 HOST systemd[1]: Mounted POSIX Message Queue File System.
Nov 06 09:35:27 HOST systemd[1]: Mounted Kernel Debug File System.
Nov 06 09:35:27 HOST systemd[1]: Mounted Kernel Trace File System.
Nov 06 09:35:27 HOST systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 251 (systemd-binfmt)
Nov 06 09:35:27 HOST systemd[1]: Mounting Arbitrary Executable File Formats File System...
Nov 06 09:35:27 HOST systemd[1]: Mounted Arbitrary Executable File Formats File System. 
Nov 06 09:35:27 HOST kernel: EXT4-fs (nvme0n1p8): re-mounted. Opts: errors=remount-ro,data=ordered,acl,user_xattr
Nov 06 09:35:27 HOST systemd[1]: Finished Remount Root and Kernel File Systems.

Any pointers as to why this is happening ?
It looks as if systemd first mounts the root partition as is, in order to go through with setting up the Huge Page table, message queuing, kernel debug and trace, before taking the time to correctly mount the root partition (/dev/nvme0n1p8) with its specified mount options. This may well be part of the normal boot sequence for our friend systemd, but I am not familiar with it.

An explanation would be great. Or is it just a case of booting from usb, mounting the volume on /mnt/ and fsck'ing / repairing it ?

Cbhihe
  • 2,549
  • 2
  • 21
  • 30
  • 1
    Look into answers here: https://unix.stackexchange.com/q/400851/126755 – Vlastimil Burián Nov 05 '20 at 15:10
  • @LinuxSecurityFreak: From you the content of the provided link, must I understand that you believe I should `fsck` a partition everytime what I described happens ? Your referenced answer is informative, but as I would not check my root FS every time it mounts (basically at every boot), I ask: do I need _**both**_ the boot option in a `/etc/default/grub.d/local.cfg file` with `GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT fsck.mode=force"` ***and also*** issue cmd `$ LC_ALL=C sudo tune2fs -c 5 /dev/nvme0n1p8` ? – Cbhihe Nov 05 '20 at 16:42
  • 1
    You only need to edit `/etc/default/grub` with `GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=yes"` and running `update-grub` and `reboot` – Vlastimil Burián Nov 05 '20 at 16:45

0 Answers0