Antw: [EXT] Infinite loop at startup on var fsck failure

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Vito Caputo <vcaputo@xxxxxxxxxxx> schrieb am 25.02.2020 um 01:01 in
Nachricht
<7343_1582589314_5E546582_7343_4690_1_20200225000143.nowls5peec5sxg7v@xxxxxxxxxx

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.

> 
> Stopping, disabling, masking, none of those obvious options to prevent
> 'systemd‑fsck@dev‑mapper‑ssd\x2var.service' from starting again in
> this loop worked, and I don't recall seeing any guidance in the journal on
> what was the appropriate course of action.
> 
> Eventually I resorted to `systemctl emergency` which seemed to get things
> quieted down enough for me to run the fsck manually.
> 
> All's well that ends well, but what an *awful* user experience.  Is this
> really how things are supposed to play out when a fsck on something like
> /var fails?  I was very much left in the dark at a root shell with systemd
> pointlessly spinning its wheels hopelessly running the same fsck
> repeatedly.
> 
> It's possible this is already better in a newer systemd release, but I just
> wanted to document this experience in case it's an area that still needs
> improvement.
> 
> This is on an old release (v232) in Debian 9.11 amd64.
> 
> Regards,
> Vito Caputo
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel