Maui Forums
[SOLVED] - Major Maui Meltdown. - Printable Version

+- Maui Forums (https://forums.mauilinux.org)
+-- Forum: Maui Support (https://forums.mauilinux.org/forumdisplay.php?fid=74)
+--- Forum: Plasma Desktop (https://forums.mauilinux.org/forumdisplay.php?fid=84)
+--- Thread: [SOLVED] - Major Maui Meltdown. (/showthread.php?tid=24099)

Pages: 1 2 3 4 5 6 7

RE: Major Maui Meltdown. - kdemeoz - 15th November 2016

Will do, thanks again to you both. I've run out of time today, but hopefully tomorrow morning i can get right back onto this.

RE: Major Maui Meltdown. - kdemeoz - 16th November 2016

Here's the 4 files.

.zip   syslog_(for Maui forum).zip (Size: 8.56 KB / Downloads: 561)

.zip   syslog.1_(for Maui forum).zip (Size: 27.61 KB / Downloads: 569)

.zip   fstab (Tower's _etc_; for Maui forum).zip (Size: 1.53 KB / Downloads: 589)

.zip   grub.cfg.zip (Size: 1.95 KB / Downloads: 586)

I have not yet tried to do the "switching the plymouth theme to something else" experiment, as there's been a couple of parallel conversations going on in this thread. Do you still wish me to try this?

RE: Major Maui Meltdown. - leszek - 16th November 2016

As for the syslogs

The only thing I found in the logs were these ones here.
Code:
Nov 16 16:41:02 moi-Z97-HD3 kernel: [86808.013022] EXT4-fs (sda3): error count since last fsck: 5
Nov 16 16:41:02 moi-Z97-HD3 kernel: [86808.013025] EXT4-fs (sda3): initial error at time 1478465657: ext4_mb_generate_buddy:758
Nov 16 16:41:02 moi-Z97-HD3 kernel: [86808.013026] EXT4-fs (sda3): last error at time 1479169354: ext4_mb_generate_buddy:758

Code:
Nov 15 11:22:34 moi-Z97-HD3 kernel: [13230.632733] EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 64, block bitmap and bg descriptor inconsistent: 17808 vs 17812 free clusters
Nov 15 11:22:34 moi-Z97-HD3 kernel: [13230.632740] JBD2: Spotted dirty metadata buffer (dev = sda3, blocknr = 0). There's a risk of filesystem corruption in case of system crash.

So something with the ext4 partition on sda3 seems to be wrong. I found those messages in both syslogs.

Code:
Nov 16 10:39:29 moi-Z97-HD3 kernel: [65114.655435] masterpdfeditor[3820]: segfault at 0 ip 00007f1ef85209da sp 00007ffe08230ce8 error 4 in libc-2.23.so[7f1ef8482000+1bf000]
Nov 16 10:40:06 moi-Z97-HD3 kernel: [65151.968570] masterpdfeditor[3849]: segfault at 0 ip 00007fcffea649da sp 00007ffdfc1eba28 error 4 in libc-2.23.so[7fcffe9c6000+1bf000]
Nov 16 10:42:04 moi-Z97-HD3 kernel: [65270.197622] masterpdfeditor[3894]: segfault at 0 ip 00007fc683a6f9da sp 00007ffd692d9c38 error 4 in libc-2.23.so[7fc6839d1000+1bf000]
Seems to be this issue: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1576055

From the rest I cannot tell much as the syslog itself shows no bootup messages sadly.
Is there maybe a boot.log aswell in /var/log (usually it shouldn't but the syslog shouldn't aswell in systemd times)

RE: Major Maui Meltdown. - kdemeoz - 16th November 2016

Here's boot.log. Nobody asked me to boot prior to getting those files, so i didn't. Current Uptime = 2d 0h 24m, which is i think maybe just outside the date-span of those other files i gave earlier. Do you want me to do a new boot, then resupply the new files? Also, i did also ask, in my last post; "I have not yet tried to do the "switching the plymouth theme to something else" experiment, as there's been a couple of parallel conversations going on in this thread. Do you still wish me to try this?".

.zip   boot.log_(for Maui forum).zip (Size: 1.85 KB / Downloads: 565)

RE: Major Maui Meltdown. - leszek - 16th November 2016

Yes please do both. I also think you need to boot a live system after normal boot try to not clear the boot.log file.

P.S. Found another problem with filesystem and checking in the boot.log

Code:
[FAILED] Failed to start File System Check o...da3-2ffd-453b-9973-94398ab4f789.


RE: Major Maui Meltdown. - kdemeoz - 16th November 2016

Re the filesystem problems you mention, i'm sorry but i am not knowledgeable enough to know what i should do about those.

With the "switching the plymouth theme" procedure, is there any risk that doing this might render my Tower unbootable even with the recovery option?

Again, my knowledge is still not yet good enough; "you need to boot a live system after normal boot try to not clear the boot.log file" --> could you pls give me a bit more info on exactly what you need me to do here?

RE: Major Maui Meltdown. - leszek - 16th November 2016

Quote:With the "switching the plymouth theme" procedure, is there any risk that doing this might render my Tower unbootable even with the recovery option?

Usually not as it is switched off during recovery.
However rebuilding initrd always has a small risk of things not working after that.


Quote:Re the filesystem problems you mention, i'm sorry but i am not knowledgeable enough to know what i should do about those.
Can you manually run a sudo fsck.ext4 /dev/sda3 to check if it spits out any error message.

Quote:could you pls give me a bit more info on exactly what you need me to do here?
1. Step boot up normally and wait 1-2 mins after it freezes to reboot
2. Boot with a live media so that the recovery boot is not overwriting the boot.log file
3. In the live system mount the local filesystem and extract out the boot.log file and save it somewhere else (not /tmp as this is empty on reboot)

Then attach that boot.log file here.

RE: Major Maui Meltdown. - kdemeoz - 17th November 2016

(16th November 2016, 13:50)leszek Wrote:
Quote:Re the filesystem problems you mention, i'm sorry but i am not knowledgeable enough to know what i should do about those. 
Can you manually run a sudo fsck.ext4 /dev/sda3 to check if it spits out any error message.

Thank you for your various answers. Of necessity there will be delays between my various responses; it will take me some time to try each thing. Hence i will be supplying a series of responses, one issue at a time.

Code:
Z97-HD3:~$ sudo fsck.ext4 /dev/sda3
[sudo] password for moi:
e2fsck 1.43.1 (08-Jun-2016)
/dev/sda3 is mounted.
e2fsck: Cannot continue, aborting.

/sda3 is my encrypted /home partition; did you really intend that one? I did also try /sda1, ie, root, but received the same result [of course]. I hope you didn't actually intend me to try this instead from a live-media boot, coz whilst then my real partitions would be unmounted, i won't have access to /home due to its .ecryptfs encryption.

RE: Major Maui Meltdown. - kdemeoz - 17th November 2016

(14th November 2016, 10:40)leszek Wrote:
Quote:P.S.: Ok new idea. Before you try anything with the nividia -> nouveau thing try first switching the plymouth theme to something else. I guess the non readable text might be an issue of the default plymouth theme (having the colors set wrongly or problems on setting them with nvidia-kms). 
So please run



Code:
sudo update-alternatives --config default.plymouth
in a terminal. It should allow you switching the default theme to spinner.plymouth at least. (by default the only other option)
Try doing that.
After that it is important to update the initramfs for the changes to also land in initrd.
So run as well:






Code:
sudo update-initramfs -u


After that try restarting with a normal boot. You should see another bootsplash and hopefully some error message whith which we can analyze whats going wrong on your machine all the sudden.

I have not yet done this in my "real" Maui, as i wanted to do a "test-run" first in one of my Maui 2 Plasma 5.8.3 VMs. So i executed both commands & rebooted the VM. I did not notice any apparent visual differences in the way that VM booted, all the way through to its Maui login screen. Wondering if i'd made an error, I redid the first command to check the current default, which as you can see in my pic has correctly changed. I wonder though about the "manual mode"... what does that mean / should i do something different as it boots?
   

RE: Major Maui Meltdown. - kdemeoz - 17th November 2016

(16th November 2016, 13:50)leszek Wrote:
Quote:could you pls give me a bit more info on exactly what you need me to do here?
1. Step boot up normally and wait 1-2 mins after it freezes to reboot
2. Boot with a live media so that the recovery boot is not overwriting the boot.log file
3. In the live system mount the local filesystem and extract out the boot.log file and save it somewhere else (not /tmp as this is empty on reboot)

Then attach that boot.log file here.

Ha, that was a very clever idea!! I wish i was good enough to think of doing stuff like that by myself. Here is the file. It appears to contain some nasty stuff, but i don't really understand the deeper implications.

.zip   boot.zip (Size: 1.86 KB / Downloads: 568)