[SOLVED] - Major Maui Meltdown.

[kdemeoz]

Following on from my last 3 posted answers, have you had a chance to consider any further actions i should take pls?

[leszek]

You need to run the filesystem check from a live system or unmounted partition.
So either go into a tty (logout your normal user from plasma to not screw stuff around) and login as user and switch to root with and sudo -i and run then

Code:

umount /dev/sda3 && fsck.ext4 /dev/sda3

or use the live system to boot up and run

Code:

sudo fsck.ext4 /dev/sda3

without prior mounting this partition.

As far as I remember you have a ecryptfs home partition and are not using full disk encryption (LUKS) on home.
So that means its a normal filesystem to check.

Lets try this and hopefully that is the only issue here.
Otherwise I am completely out of ideas as it makes no sense to suddenly appear with no update responsible for this issue.

[kdemeoz]

    EUREKA !!!  

leszek, you are a genius [& a helpful genius, what's more]. You have solved it for me!

You were right that i don't use LUKS, only ecryptfs. I chose to boot from my Maui2 ISO usb-stick & run your command therein the Live system. Errors were found & fixed:

Code:

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

maui@maui:~$ sudo fsck.ext4 /dev/sda3
e2fsck 1.43.1 (08-Jun-2016)
home contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 5242958 was part of the orphaned inode list.  FIXED.
Inode 5243232 was part of the orphaned inode list.  FIXED.
Inode 5637299 was part of the orphaned inode list.  FIXED.
Inode 5644099 was part of the orphaned inode list.  FIXED.
Inode 5644198 was part of the orphaned inode list.  FIXED.
Inode 5644247 was part of the orphaned inode list.  FIXED.
Inode 5644249 was part of the orphaned inode list.  FIXED.
Inode 5644250 was part of the orphaned inode list.  FIXED.
Inode 5644251 was part of the orphaned inode list.  FIXED.
Inode 5644283 was part of the orphaned inode list.  FIXED.
Deleted inode 5644344 has zero dtime.  Fix<y>? yes to all
Inode 5644615 was part of the orphaned inode list.  FIXED.
^[[A^[[A^[[APass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(2105376--2105384) -(2105472--2105569) -(2105576--2105599) -2105664 -(2105666--2105695) -(2105728--2105786) -2106125 -(2110507--2110529) -(2110632--2110668) -2120459 -2127311 -2128521 -(9496864--9496886) -(21039446--21039570) -22554401 -22583010 -(22727783--22727787) -(26712064--26712092) -(28444944--28444955) -(28444962--28444964) -(30838944--30838966) -(30839296--30839426) -(31641600--31643647) -(31707136--31711231) -(31715328--31717375) -(31744000--31746047) -(31750144--31752191) -(31850496--31852543) -(31971328--31973375) -(31977472--31979519) -(32053248--32053810) -(32921344--32921599)
Fix? yes

Free blocks count wrong for group #64 (17813, counted=18094).
Fix? yes

Free blocks count wrong for group #289 (32739, counted=32762).
Fix? yes

Free blocks count wrong for group #642 (25439, counted=25564).
Fix? yes

Free blocks count wrong for group #688 (23193, counted=23194).
Fix? yes

Free blocks count wrong for group #689 (1089, counted=1090).
Fix? yes

Free blocks count wrong for group #693 (26018, counted=26023).
Fix? yes

Free blocks count wrong for group #815 (7714, counted=7743).
Fix? yes

Free blocks count wrong for group #868 (15397, counted=15412).
Fix? yes

Free blocks count wrong for group #941 (27169, counted=27323).
Fix? yes

Free blocks count wrong for group #965 (25561, counted=27609).
Fix? yes

Free blocks count wrong for group #967 (11846, counted=17990).
Fix? yes

Free blocks count wrong for group #968 (3580, counted=7676).
Fix? yes

Free blocks count wrong for group #972 (4056, counted=6104).
Fix? yes

Free blocks count wrong for group #975 (2662, counted=6758).
Fix? yes

Free blocks count wrong for group #978 (11994, counted=12557).
Fix? yes

Free blocks count wrong for group #1004 (1857, counted=2113).
Fix? yes

Free blocks count wrong (26416597, counted=26436482).
Fix? yes

Inode bitmap differences:  -5242958 -5243232 -5637299 -5644099 -5644198 -5644247 -(5644249--5644251) -5644283 -5644344 -5644615
Fix? yes

Free inodes count wrong for group #640 (3543, counted=3545).
Fix? yes

Free inodes count wrong for group #688 (178, counted=186).
Fix? yes

Directories count wrong for group #688 (609, counted=608).
Fix? yes

Free inodes count wrong for group #689 (1717, counted=1719).
Fix? yes

Free inodes count wrong (9622154, counted=9622166).
Fix? yes


home: ***** FILE SYSTEM WAS MODIFIED *****
home: 216426/9838592 files (2.9% non-contiguous), 12886621/39323103 blocks
maui@maui:~$ sudo fsck.ext4 /dev/sda3

I thereafter [nervously] performed a "normal boot" &... it booted normally   -- oh yes, at last.

I make the following remarks:
1. I realise that it's impossible for you to know what specifically caused the corruption, but could you pls give me an idea of the sorts of things that generically might do such damage?
2. Curses to that 2nd Maui splash-screen with its vanishing text. I suspect that IF that text would not always vanish, so i could have read it, then i could have solved this fault all by myself on the same day it happened, without needing to bother anyone.
3. The ongoing support from Maui to your Users is simply outstanding. I sincerely thank you.

[leszek]

Glad that it worked for you and you have a normally working system now.

Regarding 1: Corruption of the filesystem can be caused by various issues. Most common is an unclean shutdown while the system was writing something to that filesystem.
Of course the disk itself also might write corrupt data from time to time (hdd and ssd have error correction built in but that not always helps) especially older models heavily used ones.

[rocky7x]

Hi kdemeoz, indeed great news to hear that this was solved. But, I would like to ask leszek, if indeed fsck needed to be run at boot, why did it fail? Indeed as you said, this happens from time to time, and windows users can especially encounter that with that "disk check needs to be performed" boot thing, but this should be normal and booting from live disk to solve this should not be needed. Any idea what went wrong here?

[leszek]

I am not really sure. But we have a special case here as the proprietary nvidia driver was in use here. I fear that the fsck at boot run and it was asking about correcting the corruption detected but the nvidia driver stopped that message from displaying.
Otherwise a regulary fsck is of course run every 30 days or 120 mounts anyway and should fix such issues. As the plymouth splash was not the problem here the only culprit on my list can be the nvidia driver.