>>> Michael Biebl schrieb am 26.02.2020 um 10:39 in Nachricht
:
> Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl
> :
>>
>> >>> Vito Caputo schrieb am 25.02.2020 um 01:01 in
>> Nachricht
>>
> <7343_1582589314_5E546582_7343_4690_1_20200225000143.nowls5peec5sxg7v@shells.g
>
> nu
>>
>> eneration.com>:
>> > Hello list,
>> >
>> > Today I experienced an unclean shutdown due to battery dying unexpectedly,
>> > and it left my /var in a state requiring a manual fsck to repair errors.
>>
>> I wonder: Shouldn't be a fsck just be a journal reply these days? For ext >=3
>> this should be quite fast. ReiserFS was rather slow several years ago (it
> did
>> replay too much IMHO), but haven't used it the last five years.
>>
>> >
>> > The normal startup process failed and dropped me to a rescue shell after
>> > asking for my root password. But I was unable to immediately run fsck
>> > manually, because systemd was endlessly trying to fsck /var.
>>
>> That's not a problem of fsck.
>
>
> I suspect that the real problem is, that fsck failed to fix the file
> system, so as a result, systemd tried repeatedly to start the fsck job
> for /var as var.mount was pulled in as a dependency (e.g. for
> journald).
The exit code should help:
The exit code returned by fsck is the sum of the following conditions:
0- No errors
1- File system errors corrected
2- System should be rebooted
4- File system errors left uncorrected
8- Operational error
16 - Usage or syntax error
32 - Fsck canceled by user request
128 - Shared library error
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
