Systemd-fsck and tune2fs failed with kernel 6.8

[robin0800]

I am sure you are right but if you want systemd-fsck that won’t work.

[cscs]

… I know.

The point is not to be using systemd-fsck in order to avoid the extra time penalty it incurs while obtaining the benefits of using the systemd hook (such as replacing for base, udev, usr, and resume hooks).

At least thats why I set it up that way.

@cscs

The systemd hook does a lot more than just the fsck.

@cscs

But you will of course need it there to make use of systemd-fsck.
As well as remove the fsck if you intend to let systemd do it (along with setting ro).

@cscs

You can have both (as in my case) … using the systemd hook as well as the fsck hook, without mounting things once as ro then again as rw. You could also have neither if you wanted to.

EDIT.
Since I wanted to go looking and double check my words …
All the things are set as described, with rw and fsck, etc.

# 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=false

I verified fsck is indeed being run early in boot, before devices are mounted.
But funny enough. Its still systemd-fsck, label-wise anyways.

   29ms systemd-fsck@dev-disk-by\x2duuid-666A\x2d4156.service
   22ms systemd-fsck-root.service

Now that does strike me as somewhat peculiar. But its probably just semantics.

[GaVenga]

Kernel 6.8:

sudo tune2fs -c 5 /dev/nvme0n1p2               
 [sudo] Password for xxxxxxx: 
 tune2fs 1.47.0 (5-Feb-2023)
 tune2fs: The device or resource is busy trying to open /dev/nvme0n1p2
 A valid file system superblock cannot be found.

Kernel 6.6:

sudo tune2fs -c 5 /dev/nvme0n1p2
 [sudo] Password for xxxxxxx: 
 tune2fs 1.47.0 (5-Feb-2023)
 The maximum number of mounts is set to 5

[GaVenga]

Kernel 6.8 and kernel 6.9:

the drives must be unmounted for tune2fs -i /dev/sdxn to work!
This wasn’t necessary with kernel 6.1 and kernel 6.6…
EDIT:
the system drives can only be accessed using kernel 6.8 and higher
by a live medium - unmounting (root) or (home) doesn’t work…
Has someone found a reason for this new behavior??

[Nachlese]

@GaVenga

EDIT:
the system drives can only be accessed using kernel 6.8 and higher
by a live medium - unmounting (root) or (home) doesn’t work…
Has someone found a reason for this new behavior??

Since this is marked as an “edit”, I assume this was added after the topic was marked as solved.

I would not have expected that unmounting / would ever have worked with any kernel.
That is certainly totally expected behavior.
… it would be roughly equivalent to pulling the proverbial rug out from under your feet …

Different story for /home - if it is on a separate partition.
Your ability to do that then depends on whether you where logged in from a user account and simply used sudo or su to gain the necessary admin rights to run the command
or whether you just went to a TTY and logged in as root directly.

Two different scenarios.

The first one I’d expect to fail, the second one should succeed.
(in the first, /home is already in use - and it is no surprise that you can’t unmount it at that point
in the second, this is not the case)

I’m curious and will play a bit and test …

---

---

after testing:
it is certainly strange and probably a bug
that tune2fs will not work with kernel 6.8 on a mounted file system - while it will happily work with … any other
(as is expected)

but the rest is as I said

one cannot unmount /

I cannot easily test this for a separate /home partition since I don’t have one.
But I do have a partition which I use to share the pacman cache between multiple VM’s
(/var/cache/pacman/pkg is on it’s own separate partition)

It can, of course, be unmounted and mounted at will.
… so long as you did not change directory to somewhere in there
for example:
cd /var/cache/pacman/pkg
and then try to unmount - this will not work - and it is expected for the above given reason

[GaVenga]

@Nachlese

separate /home partition

I have a separate /home partition - and the strange behavior is verified…

[Nachlese]

it’s even more strange:

• with a separate /home (I now have one …)
• with both kernel 6.8 and kernel 5.15

boot and do not log in to a user account - but switch to a TTY
and log in as root there
→ /home can be unmounted

boot and do log in to a user account -
graphical session, for example -
then log out again
and then switch to a TTY and log in as root
(so that you theoretically should be able to unmount /home)

/home can’t be unmounted

Same behavior with both kernels.
But at least consistent

So: yes
/home can be unmounted with any kernel version - just not when it has been accessed/used before doing so
even if it is no longer used (because logged out of user account that would require access to /home)