On many systems, you can simply
sudo touch /forcefsck
to initiate an early fsck on next boot.
Is there really no better way than having to manually edit the kernel line in the boot menu and adding fsck.mode=force with EOS? Am I maybe missing something?
Not so much here.
In fact - probably not on most distros (any more).
Whats wrong with a boot option?
It can be applied perpetually via config or during a single instance (like by hitting E and editing the options during boot - which are only temporarily applied to that single boot).
There are also the services: https://man.archlinux.org/man/systemd-fsck%40.service.8
Heres the wiki for more:
Yeah, thatâs what I did. But itâs of course complicated for an old man 
⊠over time you have to remember so many kernel line optionsâŠ
Should I infer that means you are not familiar with âpermanentlyâ applying kernel parameters (boot options)?
Like if the bootloader were grub then they can be added to /etc/default/grub (on the CMDLINE line) or to a drop-in like /etc/default/grub.d/force-fsck.cfg (the drop-in containing something like GRUB_CMDLINE_LINUX+=" fsck.mode=force") .. and following up with sudo grub-mkconfig -o /boot/grub/grub.cfg (equal to sudo update-grub).
Of course if the bootloader is not grub then the method is different.
Wiki:
No grub here, guess EOS uses gummiboot (systemd-boot), right?
Have to learn configuring this one of the days, I guess. But anyway, I was only looking for a convenience method if you want to force a fsck only once in a while (like after a REISUB, I donât always trust the dirty flags).
EDIT: Had a quick look around, found /efi/loader/entries/, so should be systemd-boot, right?
Usually yes I suppose.
Something like $ESP/loader/entries/*.conf and the options line.
As seen here:
Also, if I might guess you are using dracut (rather than mkinitcpio) then you can also affect options that way:
Yeah, like I did for my Ventoy persistence mods.
I only wonder if some âboot config generation toolâ (dracut?) would overwrite any extra .confs I manually put there, or if I must somehow generate them using an extra process for systemd-boot.
I have to re-learn a little here, been using only grub for 13+ years. Btw, thanks for the documentation pointers!
For systemd-boot on EOS, you should put your kernel options in /etc/kernel/cmdline and then run sudo reinstall-kernels
Changes in /efi/loader/entries will be overwritten.
Fair enough for the bootloader/systemd-boot examples ..
But would the dracut method (/etc/dracut.conf.d/*.conf) still be fine in that scenario?
Wouldnât anything I put in /etc/kernel/cmdline affect all boot menu entries?
Yes
It would need testing. We build our initrds with --no-hostonly-cmdline since we manage kernel params via the bootloader. I am not sure how those two things interact.
Playtime, probablyâŠ
If you create an entirely custom .conf file in /efi/loader/entries/*.conf it will not be overwritten.
That is only if you change the existing entries.
So not messing in /etc/dracut.conf.d or the like, just adding directly into /efi/loader/entries/*.conf could be good?
To try that out, can I safely âdo what dracut does when rebuildingâ somehow? (To check all works out okay?)
Maybe just sudo reinstall-kernels?
EDIT: Yup, that seems to work.
Yes, if you create a new conf file it should be ignored by our automation.
Thanks @cscs & @dalto for your input. Love learning something new each day!
Iâd prefer to give âsolutionâ to both of you for your help, but I think âsolutionâ should be the post that either solves or best describes it in total, right?
I would think that means that would not work then.
Which would mean we have almost nowhere to persistently add these (when using systemd-boot+dracut)?
Ahhh, ok. That makes more sense.
And there is definitely somewhere to persistently add these options. 
what if you changed the fstab drive value temporarily from 0 to 1 next to the dump option?
That wonât work. The sixth field in fstab only specifies the checking order.