Hi, On Tue, Feb 02, 2021 at 07:13:16PM -0500, hobie of RMN wrote: > My brother's Debian system suddenly says on attempt to boot, "/dev/sda1: > UNEXPECTED INCONSISTENCY:Runfsck manually", and, "inodes that were part of > a corrupted orphan linked list found." > > He enters "fsck" or "fsck /dev/sda1", and in a short while gets fsck > identifying it's version, and nothing else.
There can be issues trying to run fsck on a mounted filesystem. What happens if you do: # touch /forcefsck # reboot ? That will force the system to do a fsck on boot, before the filesystem is mounted for use. If that doesn't help I think you will indeed have to try this from a live or rescue environment. The Debian install media can boot into a rescue mode for tasks like this. The only time I've had something like this was when I created an ext4 filesystem in Debian buster and then used it as a root filesystem for CentOS 7. The ext code in buster used a new filesystem feature that isn't present in the ext4 driver in CentOS 7, so when CentOS 7 tried to mount its root filesystem it said there were "inconsistencies" every time. Yet doing a fsck in CentOS or trying the /forcefsck strategy I mentioned above just said the filesystem was fine, and the filesystem seemed fine in everyday use. This was because the fsck in CentOS also could not understand the new filesystem feature. In the end I had to fsck it from Debian buster and then remove the feature with tune2fs. CentOS 7 was happy with it then. I am not saying this is what has happened to you. I'm just giving an example of one weird set of circumstances that can lead to something like this. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
