Equivalent of fsck.repair when using mkinitcpio to fsck at boot time

Support
1

Hi,

First, some context. On can use either mkinitcpio or systemd to fsck the root file system at boot time.
(see fsck - ArchWiki)

When using systemd, fsck.repair can be set to have systemd-fsck performs repairs and/or optimizations.
(see systemd-fsck@.service(8) — Arch manual pages)

With fsck.repair=preen, the performed action is e2fsck -p.
(see e2fsck(8) — Arch manual pages)

With fsck.repair=yes, the performed action is e2fsck -y.
(see e2fsck(8) — Arch manual pages)

However, fsck.repair is only for systemd.
(see Fsck systemd console fehler - #2 by megavolt)

From the previous link, translated with Google Translate, as the source is not in English:

For security reasons, some repairs are not performed automatically. But to force them (ONLY WITH SYSTEMD), use the following kernel parameters:

fsck.mode=force
fsck.repair=yes

The Arch Wiki is ambiguous on the subject as both mkinitcpio and systemd are mentioned in the parent section (section 1. in the next link) but only a solution mentioning systemd (ie. fsck.repair) is provided (without an equivalent when using mkinitcpio).
(see fsck - ArchWiki)

Then, my question is the following:

How to do e2fsck -p or e2fsck -y for fsck run at boot time when using mkinitcpio instead of systemd?

Of note, an Arch user seems to have either the same question (fsck.repair is only for systemd, not mkinitcpio) or a related issue (fsck.repair does not perform optimizations with either preen or yes). Either option is possible as the thread is unfinished.
(see fsck.repair doesn't repair all problems / System Administration / Arch Linux Forums)

NB: Links are not clickable because as a new user I cannot have so many links…

Thanks

2

The Manjaro default configuration for /etc/mkinitcpio.conf includes the fsck hook, so unless you change that, fsck will always be run at boot. It does however pay to check your /etc/fstab as for whether the pass number — i.e. the last number on the line for each filesystem — is set to 1 for the root filesystem.

Note: If you use btrfs instead of ext4, then you can remove the fsck hook from /etc/mkinitcpio.conf (and rebuild your initramfs) and set the pass field in /etc/fstab to 0, because btrfs always uses its own built-in filesystem integrity check at mount time.

1 Like
3

Just my opinion:
I woudn’t want or dare to instruct e2fsck - or force it - to do such things automatically without interaction.

The fsck that occurs will replay the journal after an unclean shutdown (as far as I have observed) - and “fix” the inconsistent file system that way.
I’m not sure if that is actually the “preen” mode.
That’s ok.

Anything else I’d want to observe and control - not have anything possibly very disruptive done to the file system without even seeing it until after the fact.

If any error requires interaction, I would not want to automate it.

3 Likes
4

Thank you both for your reply.

@Aragorn The fsck hook is included in /etc/mkinitcpio.conf. The pass number is set to 1 for the root filesystem in /etc/fstab. This root filesystem is in EXT4.

To clarify, fsck is run at boot.

I have checked by first executing:

tune2fs -c 1 /dev/mapper/luks-<UUID>

then, after rebooting, by looking at:

dumpe2fs -h /dev/mapper/luks-<UUID> | grep “Last checked”

My question is then not about running fsck at boot but running it with the -p / -y parameter.

@Nachlese I see your point.

The issue is that the output of fsck is not logged (it happens before Welcome to Manjaro Linux!). Then, afterwards, I have no way to know what happened, to know if I need to perform an action. Especially the optimization ones, like correcting the extend trees. Except if I record the screen for this part of the boot process (which happens very quickly). But this isn’t practical.

Unless there is a way to log the output of fsck (without using Plymouth)?

I have read a lot on using fsck at boot time with mkinitcpio and it seems this isn’t possible (yet?).

So, it could be great if fsck could do at least the optimizations automatically.

Would it be possible?

NB: As far as I understood what I have read on the subject, fsck will stop the boot process if -p should be used (ie. one or more error occurred). In this case, I would then manually call e2fsck -p in an interactive environment.

5

I use mkinit with a systemd hooks set (see arch wiki) and at least in this scenario it does log the check and what is wrong in the journal.

1 Like
6

Thanks @Teo for your reply.

Even if there is no explanation, the Arch Wiki states that using the fsck hook is the “recommended default” [1].

Would you know why Arch does not recommend using systemd over Busybox?

[1] https://wiki.archlinux.org/title/Fsck#Mechanism

7

Arch does not recommend busybox, or at least not on x86-64 — aarch64 is a different story.

8

mkinitcpio - ArchWiki common hooks is what i read and i set myself for the systemd init. I only once had corruption because of hard reset, it actually required 2 reboots to fix itself according to the journal.

1 Like
9

I think we might go off topic but I am a bit confused.

First, Manjaro was not installed some years ago with systemd but with busybox on a x86-64 system. Have the defaults changed the last years (ie. new Manjaro installations use systemd by default now)?

Second, if I understand correctly, Arch recommends to use systemd but does not recommend to run fsck with systemd?

See in https://wiki.archlinux.org/title/Fsck#Mechanism :

The first option [ie. not using systemd to run fsck] is the recommended default, and what you will end up with if you follow the Installation guide.

10

The default is still busybox, which is however actually broken :slight_smile:
Note that the installation guide in the arch wiki is the arch guide, the default install differs in some things. Not here i think but not sure, just saying.

12

Good point @Teo. I have assumed there was no difference on the matter with Arch as there is no page in the Manjaro Wiki on BusyBox, systemd, fsck, or the boot process.

13

Before considering this thread as unresolved, maybe @megavolt could know about the issue as Fsck systemd console fehler - #2 by megavolt is one of the clearest and most detailed answer on the topic I have read on the Manjaro Forum.

As a reminder, the issue is: how to get the same behavior as with fsck.repair (specific to systemd) when using BusyBox instead of systemd.

14

If you really need this and don’t want to use systemd, you have no choice but to modify the file /usr/lib/initcpio/init_functions. Line 305, to be precise:

fsck -Ta -C"$FSCK_FD" "$device" -- ${forcefsck+-f}

:arrow_down:

fsck -Ta -C"$FSCK_FD" "$device" -- ${forcefsck+-f} -p

Anyway, there is only one method: fsck.mode=force as

mkinitcpio -H fsck

will tell you.

1 Like
15

Thank you all for your help and feedback!

16

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.