[SOLVED] - Major Maui Meltdown.

[leszek]

You said that the hdd led is not blinking when this broken screen appears. This means it isn't accessing the ssd at that time.
You even mentioned booting without quiet splash did not show a filesystem check.

So it isn't checking the disk.

[kdemeoz]

OK, yes, i see what you mean, but something still does not make sense here. How can it suddenly [just the other day] stop booting normally (ie, it freezes at that weird broken 2nd splash, which did not used to appear at all], but yet still be perfectly bootable via the grub recovery fsck option? Whilst i still would not understand what went wrong, but if it failed to boot both ways, that would sort of "make sense" [eg, maybe then a broken SSD]... but failing one way, & ok the other way... i can't understand this contradiction in its new behaviour. 

Is there nothing else i should do? (i am writing this to you using my same Tower, in Maui... booted via that grub recovery option i keep mentioning, thus proving that the SSD cannot be "dead"].

Oh, i should correct my earlier typo error. When i said "hdd activity light" i should have said "ssd activity light"... & even that still might be wrong... it's the led on the Tower's Reset button, & i don't know actually if the light refers to the SSD or to the CPU. Sorry.

[leszek]

Is there nothing else i should do?

You could try creating a log for the boot process.
First take a look at if it logs more than the actual recovery boot for you.

Code:

sudo journalctl --list-boots

If it only lists one then you need to start logging persistently.

Edit with root rights /etc/systemd/journald.conf and uncomment Storage=auto and change it to

Code:

Storage=persistent

Create the logging directory if not exists by executing

Code:

sudo mkdir -p /var/log/journal

Set correct permissions for that folder

Code:

sudo systemd-tmpfiles --create --prefix /var/log/journal

and finally restart.
This enabled boot logging.
So first take a look at the watch (important to identify the boot log later on to grab the correct log).
Boot like you normally would (to the issue with the black screen).

If it is stuck in there press shutdown button and wait until it shuts down (I hope that works)
Start after up to 5 minutes (again take a look at the watch for better identifying the non working boot) and boot up with the recovery option to have your desktop back.
Execute

Code:

sudo journalctl --list-boots

Take a good look and identify the number (usually -1, 0 and so on) at the beginning with the time and date of your faulty boot.
Then finally log the boot stuff with

Code:

sudo journalctl --boot=INSERT_BOOT_NUMBER_HERE_INSTEAD_OF_TEXT > myFaultyBoot.log

This should give you a myFaultyBoot.log file in your home directory that you can attach here or paste somewhere and give us the link to take a look at.
Hopefully there is an error or info message that can tell us what is going on.

[kdemeoz]

OK thanks. That looks tricky & it's now late night here. I shall try it tomorrow once i'm fresh again & can concentrate properly on it, then let you know.

[rocky7x]

Hi,

Of course try leszek's approach, but I must mention that I had experienced something similar sporadically during my Linux years before the first bad boot happened, have you played with your graphics card or X server settings? If I remember correctly, there is a difference in how X server is started during normal boot and during recovery. This might be a complete blind shot but it's easy to try. When you manage to boot, open the terminal and run this command:

Code:

sudo dpkg-reconfigure -phigh xserver-xorg

It will reset the configuration of the X server. The other possibility I see here is the nomodeset kernel option. When I used it, I had all sort of nonsense behavior, so it could also be that. Maybe try to remove it..

[kdemeoz]

Hi leszek

I did all your CLI steps ... TWICE [with a reboot / boot sequence in-between, of course]... but to my immense frustration, both times once back in my desktop via the reboot with recovery fsck option, this was my "reward":

Code:

Z97-HD3:~$ sudo journalctl --list-boots
Failed to determine boots: No data available

Despite it saying no data, when i instead actually looked with Dolphin in /var/log/journal, there is ONE folder, ac93e735dce94061a9b2ff443759fe8f, holding a few files... but all the timestamps corresponded with the recovery boot not the standard boot.

I rechecked /etc/systemd/journald.conf & confirmed it DOES still have Storage=persistent.

Obviously because you went to all the trouble to guide me step by step you expected it to work, & as i copied & pasted [not typed] each command from your steps i made no typo errors... but it did not store persistent logs all the same. This is probably a stupid question, but does the recovery fsck boot option [currently the only way i can reliably get back to my desktop] somehow ignore the Storage=persistent setting?

[kdemeoz]

Hi rocky7x -- thank you!

No i've not made any changes to the graphics driver for some weeks, & this boot bug only began a few days ago. It's still the same Nvidia 367.57 driver. Equally i promise you i've not touched the X server settings [as i would not know how to].

Re the nomodeset matter, whilst i would be happy to go ahead & remove it again to troubleshoot the current bug, i'd like to point out that it was inserted on 22 October but [again] this boot bug only began a few days ago. Additionally, that edit was done specifically because of https://forums.mauilinux.org/showthread....9#pid39939 ... ie, unless you can tell me an alternative method, removing this will revert me to once again being unable to reach TTY from Plasmashell, which whilst i admit i rarely need to do, i still feel it would be a pity to lose that possibility.

If i do your CLI command to reset the configuration of the X server, will that cause any other settings of mine to alter [am asking coz this is an unfamiliar area for me, & i'm loathe to cause collateral damage if at all possible]? After running it, i'd obviously need to reboot to see if anything changed, but is this a permanent setting that survives reboots [very dumb question, i suspect]?

[rocky7x]

Yes, of course, you can run the command without any problems, it will not do any harm. It will just make sure that the X server is configured correctly. And indeed reboot afterwards, so you see if it worked.

[kdemeoz]

Thanks, rocky. I ran the command, rebooted... but sadly it's still no good [same accursed symptoms]. I then tried removing the nomodeset & rebooted, but still once more no improvement [& as expected, this lost me the capability to get to TTY, so after i rebooted with recovery option fsck & logged back in to my desktop, I reinstated it].

Well, this boot bug seems to be my "new normal" now, but goodness knows why it has hit me out of the blue this week.

[fanisatt]

Very strange indeed..!!
I don't know if you have installed any alternative Linux OS on your tower (other disk)!
If you really have installed any other OS , then you may try to run it, in order to immunize that your hardware is potentially ok.
(In any case it is a good test).
You have also the ability to boot in your Maui via the grub menu of your alternative OS. Booting like this gives you a little chance to see something else ....