Have no time right now for full smart test (will do in the night for system disk, just in case), i’ve canceled it and checked usual smart (all seems fine no bad sectors of failures), but after i’ve done fsck on all disks i still have that warning message on reboot
Quoting falconindy:
“So, if you now include the ‘fsck’ hook in /etc/mkinitcpio.conf and specify neither ‘ro’ or ‘rw’ on your kernel commandline, or explicitly specify ‘ro’, systemd will fsck your root device again. This is why the warning exists”
Guess this is the important part of his post. So i try to simplify this one:
If fsck hook is in your mkinicpio.conf and you specify either “ro” in your kernel commandline
(-> /etc/default/grub) OR nothing (in your kernel commandline)
THEN
systemd will fsck your root device again. This is why the warning exists
Hope this helps. Maybe you check those points on your system
Just in case i’ve update grub - nothing changed, still have the message…
So, what i don’t understand is why it keeps warning then?
My settings haven’t been changed manually whatsoever, so that freeze + hard reset have lead to something like this failure mechanism to auto-fsck root device, but why it keeps bugging me then, even after manual fsck?
Logically i would assume this mechanism should auto-fsck and then shut up with the warning…
However, when you reboot and remove rw - it still shows warning.
I don’t understand why it works that way, what happened?
I have a feeling that system tells me that something needs to be repaired for defaults to be adequate again, but what?
I’ve runned fsck on all disks already, nothing found, smart is fine…I’ve rebuild grub…
I don’t quite understand.
So adding rw works? If you then remove rw afterwards the message is back again?
If so, why not just leave the option in then? You actually do want to mount the device writable anyway, so I don’t see the downside. Fsck can now potentially run on that device and you don’t have the warning message at boot.
While i agree with your statement here, i still think that is bad as solution, because:
I see no logic in what happened at all and why it’s not resolved with just defaults afterwards
This doesn’t look like how auto-fsck failure mechanism should work
It looks a lot like either bug or system saying something like:
ok, there were some failure, so i’ve tried (not sure even how to check it?) to auto-fix problem, but now to remove warning regardless you need to set rw or disable whole mechanism
So i’m afraid that problem is just still actually there
Hopefully someone else who may had previous experience could clarify what happened and what we maybe missing here…