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.
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. 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
