Systemd-fsck gives "fsck failed with exit status 8" for root in kernel 6.8

Support
,
1

First off, I’m familiar with this thread, but it was closed 14 hours ago, so I cannot participate.
I’ve read through it, but I’m uncertain what the conclusion was. To get rid off systemd-fsck, and set the fsck hook again? Perform file system checks in a live environment?

huhti 16 19:00:51 jp-gentoo systemd-fsck[332]: fsck failed with exit status 8.
huhti 16 19:00:51 jp-gentoo systemd-fsck[332]: Ignoring error.
huhti 16 19:00:51 jp-gentoo apparmor.systemd[323]: Restarting AppArmor
huhti 16 19:00:51 jp-gentoo apparmor.systemd[323]: Reloading AppArmor profiles
huhti 16 19:00:51 jp-gentoo systemd-modules-load[335]: Inserted module 'uinput'
huhti 16 19:00:51 jp-gentoo systemd-fsck[346]: fsck.ext4: Device or resource busy while trying to open /dev/sda2
huhti 16 19:00:51 jp-gentoo systemd-fsck[346]: Filesystem mounted or opened exclusively by another program?

I’ve set the root filesystem to be mounted as read-only in my grub file:

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically. We use 'fsck' by default, which
# needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be
# removed from 'mkinitcpio.conf' to make 'systemd-fsck' work.
# See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking
GRUB_ROOT_FS_RO=true

My HOOKS:

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap block filesystems mdadm_udev

My fstab:

# <file system> <mount point> <type> <options> <dump> <pass>

UUID=B5D2-5542	/boot/efi	vfat	umask=0077	0	2
UUID=c28c9ba1-1ab9-48ed-a6c3-a5cf6794acea	/	ext4	defaults,noatime	0	1
tmpfs	/tmp	tmpfs	defaults,noatime,mode=1777	0	0
UUID=9477a9d1-47fc-4f4b-a05f-24cd2755ab8e	/mnt/faaast	ext4	defaults,noatime	0	2
/mnt/faaast/swap	none	swap	defaults	0	0

To clarify: I’ve been using the read-only method for years. I didn’t not set these today.

2

It might have something to do with your rather strange location of your swap (file?).

Not at all sure though.

What I know is that swap is not a file system - and thus cannot be mounted in the way you did (try to).

It can be a partition.
Like: /dev/sdb2 for instance - but it cannot be mounted to a directory like you wrote it in your /etc/fstab

or it can be a file - the name is “swapfile” by default - and is then located directly under /

GRUB_ROOT_FS_RO=true
in
/etc/default/grub
is the default
so:
you effectively changed nothing by uncommenting the option

your HOOKS are missing the fsck hook at the last position

(all I did was comparing it to mine)

1 Like
3

I’ve gone back to the read/write mount in the GRUB file, added fsck back to my HOOKS, regenerated images, reinstalled GRUB configs. Seems my root (sda2) is still not being checked:

journalctl -b-0 | grep fsck                                                                                                                                                                                                                                                   ✔ 
huhti 16 21:46:40 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 16 21:46:40 jp-gentoo systemd-fsck[521]: /dev/md0: clean, 904067/48807936 files, 142696138/195228672 blocks
huhti 16 21:46:40 jp-gentoo systemd-fsck[581]: fsck.fat 4.2 (2021-01-31)
huhti 16 21:46:40 jp-gentoo systemd-fsck[581]: /dev/sda1: 5 files, 74/130812 clusters

sda2 is mounted read/write twice :thinking:

journalctl -b-0 | grep sda2                                                                                                                                                                                                                                               0|1 ✘ 
huhti 16 21:46:40 jp-gentoo kernel:  sda: sda1 sda2
huhti 16 21:46:40 jp-gentoo kernel: EXT4-fs (sda2): mounted filesystem c28c9ba1-1ab9-48ed-a6c3-a5cf6794acea r/w with ordered data mode. Quota mode: none.
huhti 16 21:46:40 jp-gentoo kernel: EXT4-fs (sda2): re-mounted c28c9ba1-1ab9-48ed-a6c3-a5cf6794acea r/w. Quota mode: none.

–

false is the default; you uncomment this line to enable it.

This has to be removed when mounting root read-only.

4

#GRUB_ROOT_FS_RO=true

is what is in my /etc/default/grub

which I took as the default

But it seems to be a convoluted explanation,
involving whether you use sd-* hooks or the “old” ones
and also then , whether “rw” or “ro” is added to the kernel command line to match the intention

I’ll bail out of the discussion at this point - my brain can’t handle this right now.

Sorry for the noise.

re swap:
yes, I think I get the picture now

5

I tried kernel 6.6, but sda2 isn’t being checked there either…
I found sessions between which the file system check behaviour for root changes.

journalctl -b-13 | grep fsck
huhti 11 02:08:31 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 11 02:08:31 jp-gentoo systemd-fsck[348]: /dev/sda2: clean, 821374/30498816 files, 78826231/121965313 blocks
huhti 11 02:08:32 jp-gentoo systemd-fsck[537]: /dev/md0: clean, 816504/48807936 files, 142984244/195228672 blocks
huhti 11 02:08:32 jp-gentoo systemd-fsck[611]: fsck.fat 4.2 (2021-01-31)
huhti 11 02:08:32 jp-gentoo systemd-fsck[611]: /dev/sda1: 5 files, 74/130812 clusters
huhti 11 02:10:40 jp-gentoo systemd[1]: systemd-fsck@dev-disk-by\x2duuid-B5D2\x2d5542.service: Deactivated successfully.
huhti 11 02:10:40 jp-gentoo systemd[1]: systemd-fsck@dev-disk-by\x2duuid-9477a9d1\x2d47fc\x2d4f4b\x2da05f\x2d24cd2755ab8e.service: Deactivated successfully.
huhti 11 02:10:40 jp-gentoo systemd[1]: Removed slice Slice /system/systemd-fsck.
huhti 11 02:10:40 jp-gentoo systemd[1]: systemd-fsck-root.service: Deactivated successfully.

journalctl -b-12 | grep fsck 
huhti 11 02:11:09 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 11 02:11:09 jp-gentoo systemd-fsck[329]: fsck failed with exit status 8.
huhti 11 02:11:09 jp-gentoo systemd-fsck[329]: Ignoring error.
huhti 11 02:11:09 jp-gentoo systemd-fsck[344]: fsck.ext4: Device or resource busy while trying to open /dev/sda2
huhti 11 02:11:09 jp-gentoo systemd-fsck[344]: Filesystem mounted or opened exclusively by another program?
huhti 11 02:11:09 jp-gentoo systemd-fsck[536]: /dev/md0: clean, 816504/48807936 files, 142984244/195228672 blocks
huhti 11 02:11:09 jp-gentoo systemd-fsck[588]: fsck.fat 4.2 (2021-01-31)
huhti 11 02:11:09 jp-gentoo systemd-fsck[588]: /dev/sda1: 5 files, 74/130812 clusters
huhti 12 04:57:20 jp-gentoo systemd[1]: Requested transaction contradicts existing jobs: Transaction for systemd-logind.service/start is destructive (system-systemd\x2dfsck.slice has 'stop' job queued, but 'start' is included in transaction).
huhti 12 04:57:21 jp-gentoo systemd[1]: systemd-fsck@dev-disk-by\x2duuid-B5D2\x2d5542.service: Deactivated successfully.
huhti 12 04:57:22 jp-gentoo systemd[1]: systemd-fsck@dev-disk-by\x2duuid-9477a9d1\x2d47fc\x2d4f4b\x2da05f\x2d24cd2755ab8e.service: Deactivated successfully.
huhti 12 04:57:22 jp-gentoo systemd[1]: Removed slice Slice /system/systemd-fsck.
huhti 12 04:57:22 jp-gentoo systemd[1]: systemd-fsck-root.service: Deactivated successfully.

The latter is the first time booting with 6.8.

Here’s what I have installed via pacman around this time, but everything seems to have functioned as it should based on journal timestamps:

[2024-04-11T02:06:21+0300] [ALPM] upgraded amd-ucode (20240312.3b128b60-1 -> 20240409.1addd7dc-1)
[2024-04-11T02:06:21+0300] [ALPM] upgraded imagemagick (7.1.1.29-2 -> 7.1.1.30-2)
[2024-04-11T02:06:21+0300] [ALPM] upgraded libarchive (3.7.2-2 -> 3.7.3-1)
[2024-04-11T02:06:21+0300] [ALPM] upgraded libxmlb (0.3.17-1 -> 0.3.18-1)
[2024-04-11T02:06:21+0300] [ALPM] upgraded linux-firmware-whence (20240312.3b128b60-1 -> 20240409.1addd7dc-1)
[2024-04-11T02:06:22+0300] [ALPM] upgraded linux-firmware (20240312.3b128b60-1 -> 20240409.1addd7dc-1)
[2024-04-11T02:06:22+0300] [ALPM] upgraded linux66 (6.6.25-1 -> 6.6.26-1)
[2024-04-11T02:06:22+0300] [ALPM] upgraded taglib (2.0-1 -> 2.0.1-1)
[2024-04-11T02:06:22+0300] [ALPM] upgraded yt-dlp (2024.03.10-1 -> 2024.04.09-1)

This was via Manjaro Settings Manager UI:

[2024-04-11T02:10:02+0300] [PACMAN] Running '/usr/bin/pacman --noconfirm --noprogressbar -S linux68'
[2024-04-11T02:10:06+0300] [ALPM] transaction started
[2024-04-11T02:10:06+0300] [ALPM] installed linux68 (6.8.5-1)
[2024-04-11T02:10:06+0300] [ALPM] transaction completed
[2024-04-11T02:10:06+0300] [ALPM] running '30-systemd-update.hook'...
[2024-04-11T02:10:06+0300] [ALPM] running '60-depmod.hook'...
[2024-04-11T02:10:07+0300] [ALPM] running '90-mkinitcpio-install.hook'...
[2024-04-11T02:10:07+0300] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux68.preset: 'default'
[2024-04-11T02:10:07+0300] [ALPM-SCRIPTLET] ==> Using default configuration file: '/etc/mkinitcpio.conf'
[2024-04-11T02:10:07+0300] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-6.8-x86_64 -g /boot/initramfs-6.8-x86_64.img
[2024-04-11T02:10:07+0300] [ALPM-SCRIPTLET] ==> Starting build: '6.8.5-1-MANJARO'
[2024-04-11T02:10:07+0300] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2024-04-11T02:10:08+0300] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2024-04-11T02:10:08+0300] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2024-04-11T02:10:08+0300] [ALPM-SCRIPTLET]   -> Running build hook: [microcode]
[2024-04-11T02:10:08+0300] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2024-04-11T02:10:08+0300] [ALPM-SCRIPTLET]   -> Running build hook: [kms]
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'xhci_pci'
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET]   -> Running build hook: [mdadm_udev]
[2024-04-11T02:10:09+0300] [ALPM-SCRIPTLET] Custom /etc/mdadm.conf file will be used in initramfs for assembling arrays.
[2024-04-11T02:10:10+0300] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2024-04-11T02:10:10+0300] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.8-x86_64.img'
[2024-04-11T02:10:10+0300] [ALPM-SCRIPTLET]   -> Early uncompressed CPIO image generation successful
[2024-04-11T02:10:12+0300] [ALPM-SCRIPTLET] ==> Initcpio image generation successful
[2024-04-11T02:10:12+0300] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux68.preset: 'fallback'
[2024-04-11T02:10:12+0300] [ALPM-SCRIPTLET] ==> Using default configuration file: '/etc/mkinitcpio.conf'
[2024-04-11T02:10:12+0300] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-6.8-x86_64 -g /boot/initramfs-6.8-x86_64-fallback.img -S autodetect
[2024-04-11T02:10:12+0300] [ALPM-SCRIPTLET] ==> Starting build: '6.8.5-1-MANJARO'
[2024-04-11T02:10:12+0300] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2024-04-11T02:10:13+0300] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2024-04-11T02:10:13+0300] [ALPM-SCRIPTLET]   -> Running build hook: [microcode]
[2024-04-11T02:10:13+0300] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2024-04-11T02:10:13+0300] [ALPM-SCRIPTLET]   -> Running build hook: [kms]
[2024-04-11T02:10:14+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'ast'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'xhci_pci'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qla1280'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'bfa'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qed'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'wd719x'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'aic94xx'
[2024-04-11T02:10:16+0300] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qla2xxx'
[2024-04-11T02:10:17+0300] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2024-04-11T02:10:17+0300] [ALPM-SCRIPTLET]   -> Running build hook: [mdadm_udev]
[2024-04-11T02:10:17+0300] [ALPM-SCRIPTLET] Custom /etc/mdadm.conf file will be used in initramfs for assembling arrays.
[2024-04-11T02:10:18+0300] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2024-04-11T02:10:18+0300] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.8-x86_64-fallback.img'
[2024-04-11T02:10:18+0300] [ALPM-SCRIPTLET]   -> Early uncompressed CPIO image generation successful
[2024-04-11T02:10:28+0300] [ALPM-SCRIPTLET] ==> Initcpio image generation successful
[2024-04-11T02:10:28+0300] [ALPM] running '99-update-grub.hook'...
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Generating grub configuration file ...
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found theme: /usr/share/grub/themes/manjaro/theme.txt
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found linux image: /boot/vmlinuz-6.8-x86_64
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.8-x86_64.img
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-6.8-x86_64-fallback.img
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found linux image: /boot/vmlinuz-6.7-x86_64
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.7-x86_64.img
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-6.7-x86_64-fallback.img
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found linux image: /boot/vmlinuz-6.6-x86_64
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found initrd image: /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Warning: os-prober will not be executed to detect other bootable partitions.
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Systems on them will not be added to the GRUB boot configuration.
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Check GRUB_DISABLE_OS_PROBER documentation entry.
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Adding boot menu entry for UEFI Firmware Settings ...
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Found memtest86+ image: /boot/memtest86+/memtest.bin
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] Adding poweroff option.
[2024-04-11T02:10:29+0300] [ALPM-SCRIPTLET] done

I have rolled back to prior touching 6.8. The root is being check once again, so I guess I can rule out hardware issues?

journalctl -b-0 | grep fsck 
huhti 16 22:44:26 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 16 22:44:26 jp-gentoo systemd-fsck[345]: /dev/sda2: clean, 825131/30498816 files, 79117487/121965313 blocks
huhti 16 22:44:27 jp-gentoo systemd-fsck[535]: /dev/md0: clean, 904070/48807936 files, 142699462/195228672 blocks
huhti 16 22:44:27 jp-gentoo systemd-fsck[538]: fsck.fat 4.2 (2021-01-31)
huhti 16 22:44:27 jp-gentoo systemd-fsck[538]: /dev/sda1: 5 files, 74/130812 clusters

Update: I have updated everything via pacman, and tested on both EOL 6.7, and the LTS 6.6. The check is still happy, so this seems like a bug of some sort, introduced by 6.8. What’s weird that 6.6 was affected as well after installing 6.8…

6

Then you do not want to set the ro, and you do want the fsck hook.

Those together should have regular fsck running instead of systemd-fsck, which requires mounting first as read-only.

Probably also run

sudo mkinitcpio -P && sudo grub-mkconfig -o /boot/grub/grub.cfg
7

Yes, I did try all of this. I know how the read-only method works, I’ve been using it for about two years. See the logs etc. further down. Everything seems to have gone wrong after installing linux68.
It’s late here. I’ll try installing 6.8 again tomorrow to see if the issue resurfaces.

8

I’d just avoid using it if it would give me problems.

I read/heard of several.

… if I didn’t have to use it for some reason

for the limited amount of time I’ve used it in a VM, there where no problems with it (for me)

515 LTS works - so I’ll keep using it

1 Like
9

I was more responding to what seemed to be confusion about the options.

Maybe not on your part.

I would similarly agree about the kernels but its still all odd.
(why does installing 6.8 break fsck boot checking for other kernels?)

I can report here that my 6.8 checks seem to run OK.
Though mine is a non-manjaro kernel.

1 Like
10

If I check current Manjaro Installation using an “UBUNTU 22.04 Live-Medium” (Disks (Gnome)),
there will be errors: e2fsprog version is too old - unknown field C12 in filesystem (as far as I remember)…
Maybe kernel 6.8 uses too modern version of fsk/filesystem (speculation)…

11

The file system (the Manjaro one) was created with support for a new feature - I forgot what it was for or what the name is.
The older e2fsck or e2fsprog versions do not know this feature and cannot deal with it.

One way to solve this is to disable the feature with tune2fs from within Manjaro.

edit:

https://askubuntu.com/questions/1497523/feature-c12-e2fsck-get-a-newer-version-of-e2fsck

seems to be the answer

2 Likes
12

Ok, so running 6.8 is the problem, for sure.
I did the updates that arrived today, and rebooted. sda2 is checked during boot.
Then I install linux68 via the Manjaro Settings Manager UI, and reboot but staying at LTS 6.6. The checking still works. I reboot once again, now switching to 6.8, and the root cannot be checked anymore:

journalctl -b-0 | grep fsck
huhti 17 21:14:28 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 17 21:14:28 jp-gentoo systemd-fsck[331]: fsck failed with exit status 8.
huhti 17 21:14:28 jp-gentoo systemd-fsck[331]: Ignoring error.
huhti 17 21:14:28 jp-gentoo systemd-fsck[344]: fsck.ext4: Device or resource busy while trying to open /dev/sda2
huhti 17 21:14:28 jp-gentoo systemd-fsck[344]: Filesystem mounted or opened exclusively by another program?
huhti 17 21:14:28 jp-gentoo systemd-fsck[522]: /dev/md0: clean, 984542/48807936 files, 143821657/195228672 blocks
huhti 17 21:14:28 jp-gentoo systemd-fsck[581]: fsck.fat 4.2 (2021-01-31)
huhti 17 21:14:28 jp-gentoo systemd-fsck[581]: /dev/sda1: 5 files, 74/130812 clusters

Another reboot, going back to 6.6. Unlike yesterday, the checking is still functional on LTS:

journalctl -b-0 | grep fsck 
huhti 17 21:15:47 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 17 21:15:47 jp-gentoo systemd-fsck[353]: /dev/sda2: clean, 821893/30498816 files, 79311966/121965313 blocks
huhti 17 21:15:47 jp-gentoo systemd-fsck[537]: /dev/md0: clean, 984542/48807936 files, 143821657/195228672 blocks
huhti 17 21:15:47 jp-gentoo systemd-fsck[612]: fsck.fat 4.2 (2021-01-31)
huhti 17 21:15:47 jp-gentoo systemd-fsck[612]: /dev/sda1: 5 files, 74/130812 clusters

I’ll stick with 6.6 'til this is solved. Or is going back to read/write method a better option, objectively (performance, reliability etc.)? And before any of you are trying to be funny, yes, the older method is more reliable at the moment :laughing:

13

Its what Arch suggests. The systemd/ro variant incurs a slight time penalty due to needing to mount ro, dismount, mount as rw for the session.

14

I’m getting the same issue. Everything works fine on 6.6 and 6.7 but on 6.8 systemd-fsck-root.service fails with a very unhelpful message. Nothing else is changed between boots.

systemctl status systemd-fsck-root.service 
     Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; enabled-runtime; preset: disabled)
     Active: active (exited) since Wed 2024-04-17 21:09:05 CEST; 16min ago
       Docs: man:systemd-fsck-root.service(8)
    Process: 207 ExecStart=/usr/lib/systemd/systemd-fsck (code=exited, status=0/SUCCESS)
   Main PID: 207 (code=exited, status=0/SUCCESS)
        CPU: 13ms

Apr 17 21:09:05 kanji-pc systemd-fsck[231]: fsck.ext4: Device or resource busy while trying to open /dev/sda3
Apr 17 21:09:05 kanji-pc systemd-fsck[231]: Filesystem mounted or opened exclusively by another program?
Apr 17 21:09:05 kanji-pc systemd-fsck[207]: fsck failed with exit status 8.
Apr 17 21:09:05 kanji-pc systemd-fsck[207]: Ignoring error.
Apr 17 21:09:05 kanji-pc systemd[1]: Finished File System Check on Root Device.

There doesn’t seem to be mentions of this issue outside of this forum so it looks like a Manjaro specific issue. Arch has util-linux on version 2.40 so maybe that has something to do with it? Manjaro testing also has it so switching branches would be one way to test it. I might give it a shot.

16

I’m having this issue on Manjaro Unstable, so even closer to Arch than Testing.

I went back to trying the read/write method, and sda2 was omit from journals yet again. Next, I tried adding systemd to my HOOKS, and this looks like a success to me :grin:
In both 6.6 and 6.8:

journalctl -b-0 | grep fsck                                                                                                                                                                                                                                                 
huhti 18 00:08:13 archlinux systemd-fsck[242]: /dev/sda2: clean, 823601/30498816 files, 79306139/121965313 blocks
huhti 18 00:08:20 jp-gentoo systemd[1]: Created slice Slice /system/systemd-fsck.
huhti 18 00:08:21 jp-gentoo systemd-fsck[491]: fsck.fat 4.2 (2021-01-31)
huhti 18 00:08:21 jp-gentoo systemd-fsck[491]: /dev/sda1: 5 files, 74/130812 clusters
huhti 18 00:08:21 jp-gentoo systemd-fsck[593]: /dev/md0: clean, 993652/48807936 files, 144025848/195228672 blocks

So, is the hook now a requirement for the read/write mount fsck to work?

I think I gamed myself last night with all the permutations I tried, that I didn’t realise I hadn’t tested 6.6 with the read-only setup as-is. So mere existence of 6.8 in my system wasn’t the cause, after all. :facepalm:

Can I say “I run Arch btw” with this? :stuck_out_tongue:

17

I always thought it was. Though I dont see explicit mention of it in the wiki.

What do your HOOKS look like now?

18 
HOOKS=(base systemd udev autodetect microcode modconf kms keyboard keymap block filesystems mdadm_udev fsck)

I think there’s some redundant ones there now with the inclusion of systemd? udev is probably redundant here.

19

Yes. I dont know what you actually need.

base and udev are both likely unneeded.

keymap may not be needed or may be replaced by sd-vconsole.

(and I assume mdadm_udev is there on purpose because of RAID or something?)

20

Yes, it is for that purpose.
I’ll trim out some of the now-redundant ones.

21

Exactly what I thought, thank you.
May be the 6.8 kernel has an own method dealing with filesystems…
Who knows, please tell us unworthy creatures. :innocent: