[SOLVED] - Major Maui Meltdown.

[kdemeoz]

It's seems possible to be a hardware problem !
If you have installed the OS in a SSD (I remember you have SSDs), try this command in the konsole : sudo fstrim -v /  .
I have also the OS in a SSD and I used to run this command once or twice a week. (Normally, the system runs fstrim on a weekly basis but I like doing it myself, just to be sure.....!
And something else.... I hope your PSW (power supply unit) is "strong" enough to support your specific hardware demands ! If you have 2-3 disks , demanding graphics card and other PCI expansion cards , USB devices (powered by the PC) ...etc..etc... you need a decent 650W PSW .
Keep your eye to the PSW !!! It can cause crazy situations......
I hope you fix the problem.

Thanks. Yes it is an SSD where Maui [& /home] are. I did now manually run fstrim as you suggested [but it should be unnecessary, due to my rc.local excerpt as shown further below], with these results:

Code:

Z97-HD3:~$ sudo fstrim -v /
[sudo] password for ...:  
/: 18.5 GiB (19824160768 bytes) trimmed
Z97-HD3:~$ sudo fstrim -v /home
/home: 102.7 GiB (110245642240 bytes) trimmed
Z97-HD3:~$ sudo fstrim -v /opt
/opt: 27.8 GiB (29857165312 bytes) trimmed

I then tried another reboot, but it was still not fixed.

Bottom of my rc.local file, ie, trimming should occur during every boot (i always edit my Linux OS this way when i have SSD, this is not a new/recent edit]:

Code:

fstrim /
fstrim /home
fstrim /opt

exit 0

My power-supply is  a Silverstone 700W 80plus Gold PSU.

Thank you for trying to help me!

[AJSlye]

I'm not sure running that on every boot is such a great idea, this will greatly dimminish your SSD drives lifespan.

[kdemeoz]

I'm not sure running that on every boot is such a great idea, this will greatly diminish your SSD drives lifespan.

Your advice greatly surprised me, as i'd setup my SSDs this way a couple of years ago [based on what i believed to be a reputable reference; https://sites.google.com/site/easylinuxtipsproject/ssd]. However, when i first bookmarked that page, it was written for Ubuntu 14.04 & Mint 17.x [the latter of which was my Tower & Lappy distros then], & it specifically recommended the preferability for routine boot trimming via rc.local compared to the weekly cron job or especially not the older option of discard in /etc/fstab. To my amazement when i returned to this site just now in prep for this reply, i saw that the author had updated it for Ubuntu 16.04 & Mint 18, & explicitly reversed his earlier recommendation, due to systemd. OMZ! So i've now removed those lines, & after completing this reply, will try another reboot in hope of a better response. 

Thank you for challenging my method, as i'd otherwise not have realised my method had become superseded.

Just as a fyi though, my usual nightly practice is to Suspend my PCs not shutdown, hence the following mornings i Resume them not Boot them, thus in practice the rc.local file trimming would have been occurring far less frequently than you might have imagined [with associated reduction of SSD wear].

[kdemeoz]

No, the reboot after rc.local edit did not help; i still can only boot fully back to desktop via grub kernel recovery option, thence fsck. Otherwise i still get the normal Maui skyblue splashscreen followed by that bad second splash-screen with the momentary text in the 2 bars. This time, in the brief moment the text was visible, i saw a couple of the words (i think]; something maybe including "check", "file", & "system" (i am not confident about any of that]. Here's a pic of that screen:
   

This morning [many hours ago] Update Manager offered me a few updates, including the new kernel 4.4.0-47. That's what i'm now using, but it also has not helped eliminate this problem.

If my SSD really had developed a fault that was causing this problem, as fanisatt & rocky7x suggested, wouldn't that stop me booting entirely, under all conditions? Instead, whilst i can no longer do a normal boot, so far every fallback boot via the grub kernel recovery option fsck has worked. I'm just trying to understand the logic of what might be going on & how i could troubleshoot & solve it.

[leszek]

If it's really the filesystem check why not let it run for let's say an hour with that screen on. That should be enough to check the filesystem
Btw. Did you do try the removal of quiet splash parameters? What does it show then in the tty terminal?

[kdemeoz]

Oh, could it take an hour? I did not know that. I have already let it run for ~15' or 20', but gave up after that, supposing that it was stuck & nothing happening [pls realise, given i cannot read anything on the screen then, & no hdd activity light flickers on my pc, i have no way of knowing it it's frozen or processing]. OK, tonight instead of Suspending my Tower, i will reboot it & let it sit on that screen over night. If ... IF... when i look at it in the morning, & see that it actually did do something, would that be the end of the matter, or would i expect an hour-long delay every boot up from now on [which is obviously unacceptable]?

Yes i did edit out that splash in the booting grub, & i did already reply to you on this. #10 above; https://forums.mauilinux.org/showthread....2#pid40322

[leszek]

Hmm... did not see that due to the strange formatting you used there.

Well it is hard to tell what the problem ist without an proper error message.
Maybe it's the graphics driver.
Maybe a broken initrd. Though then recovery should act up aswell and other kernels should boot up just fine.

[kdemeoz]

Don't know why you blamed my #10 formatting.

Do you still recommend i leave the pc running at that 2nd splash screen? [& what about the related question i asked you?].

[leszek]

Do you still recommend i leave the pc running at that 2nd splash screen?

No I don't think it makes sense if it does not access the ssd at all.

Btw. this reply is one example how I expect answers to specific questions. Using quotes. It Is easier to the eyes to spot the answers especially in long texts.

[kdemeoz]

Do you still recommend i leave the pc running at that 2nd splash screen?

No I don't think it makes sense if it does not access the ssd at all.

I don't understand you. What do you mean by saying it does not access the SSD? Maui is installed on my SSD. I don't recall me ever saying anything to you about not accessing the SSD.

It seems that i have no options left to fix this strange problem. It's very confusing.