You mentioned loss of power during an upgrade, that would trick any Linux into checking the filesystem for errors and loss of data. It wasn't the faulty upgrade, it was that you lost power abruptly during your system's operation.
Did you wait for fsck to finish its work? fsck (filesystem check) isn't a fast utility.
Any Linux system operates on different runlevels: depending on user settings, system resources and seemingly catastrophic occurences, a different set of interactive tools will be made available to you to interact with the system. Every runlevel has a set of sensible defaults and on a normally booted system you can switch between runlevels, or in the new systemd parlance they are called targets, each target depending on the previous one to be loaded to start, which on turn depends on system resources to become available.
Start playing with switching between runlevels/targets on your system while in normal operation so that in case you start thinking that GUI isn't available, you would know how to revert back to GUI. In the incident you described above, GUI wouldn't be available while fsck is running anyway...
👋 Hey there, I am Waylon Walker
I am a Husband, Father of two beautiful children, Senior Python Developer currently working in the Data Engineering platform space. I am a continuous learner, and sha
You mentioned loss of power during an upgrade, that would trick any Linux into checking the filesystem for errors and loss of data. It wasn't the faulty upgrade, it was that you lost power abruptly during your system's operation.
Did you wait for fsck to finish its work? fsck (filesystem check) isn't a fast utility.
Any Linux system operates on different runlevels: depending on user settings, system resources and seemingly catastrophic occurences, a different set of interactive tools will be made available to you to interact with the system. Every runlevel has a set of sensible defaults and on a normally booted system you can switch between runlevels, or in the new systemd parlance they are called targets, each target depending on the previous one to be loaded to start, which on turn depends on system resources to become available.
Start playing with switching between runlevels/targets on your system while in normal operation so that in case you start thinking that GUI isn't available, you would know how to revert back to GUI. In the incident you described above, GUI wouldn't be available while fsck is running anyway...
Ya I put kids to bed and came back hours later to fine id still at 7xxx/7xxx complete. the fsck was complete as far as I could tell.