Maui Forums

Full Version: [Solved] - Tower's 1st [no, 3rd] Hard-Reset since clean-reinstall.
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
(18th January 2017, 12:18)Pliny.D.Elder Wrote: [ -> ]
(18th January 2017, 11:43)kdemeoz Wrote: [ -> ]Oh rats Pliny -- it took me ages to compose my previous reply, & once i'd posted it, i saw that you had added some stuff to the end of your original post -- haven't had time to look into any of that, but will later - thanks.

And might I say your previous reply was written with the mastery of a great Mozart symphony.
!st.... I was not suggesting that you make some of them changes permanent. Was only to see if there was any improvement over the next few days. You could back up your settings with Timeshift before doing any changes.
2nd....The history.log was only useful if you have a good idea when your problems started.
3rd....Did you at least try........

sudo apt-get install --reinstall xserver-xorg-input-all kwin
4th.... It is only advice, so you obviously must make the decision of whether it sounds right for you. I have found a lot of glitches can be remedied by elimination, at least that's how I stratagize.
5th.....Yeah I forgot those links the first post so I edited them in. Good luck

Hi Pliny

First, thanks for your poetic kindly words. Second, i love your animated avatar - that's very clever [not to mention boppy].

Yes i did certainly understand your advice was meant as temporary changes for troubleshooting purposes only, not permanent. I'm sorry i did a poor job of explaining. What i had tried to explain (i hope i do a better job this time] is that if, say, my current preferred Workspace Appearance settings "suite" of Breeze widgets, Plastik Window Decorations, Oxygen Desktop Theme, my much-customised system Colours, Oxygen Icons, Crux GTK2 Theme, Emacs GTK3 Theme, Hicolour Icon theme, & GNOME Fallback Icon theme, turned out to be THE root cause of these rare freezes, then i would simply have to accept that i will keep having said occasional freezes, given i am simply not willing to have to use [eg] the crappy Breeze GTK3 Theme, or Breeze Icons, or especially not the lousy Breeze Desktop Theme, as my permanent arrangement. 

Now, take all my [sincerely-meant] words just written, & combine with this: these freezes are RARE. If these were a daily or weekly occurrence, my attitude would be very different, & i would feel much more displeased with Maui. But they are not frequent at all. Sure, i am always upset/cranky when they do occur, but the reality is they hardly ever actually occur. So, on balance, my calculus is that even IF my settings WERE to be the root cause, i am prepared to have these unpleasant RARE freezes, but in-between enjoy a system with aesthetics & functionality i LOVE, rather than no more occasional freezes but all the time a system whose aesthetics & functionality i intensely dislike. 

Obviously, i hope the freeze root-cause is something else entirely, & that sooner or later i will discover & solve it. You might well disagree, & think me nuts, but at least i hope i explained a bit better this time.

Timeshift -- i discovered this several months ago, & back then read In the end i did not try it, but thought it sounded potentially great. I chickened-out for two reasons; [1] does it really work, is it completely safe & reliable? [2] is it specifically compatible with Maui? The "latest" comments on his page are now pretty old, so how can i tell if it remains still viable for newer distros [like Maui]? Logically, the fact that you've now mentioned it to me must mean that you use it, know it works, & fully trust it...?

If i was to try...

sudo apt-get install --reinstall xserver-xorg-input-all kwin

...would it overwrite all my present personalisation settings in .local & .kde ? Is there any downside to me trying it, given i now have a nicely-customised & [mostly] well-running system?

I hope to have time later today to read those links you gave. 

Mad Speculation? --> I like to, & do, run my /tmp as a ram-disk via tmpfs in my fstab file:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

I do this partly for longterm privacy [given /tmp thus gets wiped at reboot], & partly for possible longer SSD life [less system & programs (eg, browsers) short-term file writing to SSD]. I'm aware that the default setting allocates 50% of available RAM to tmpfs /tmp tmpfs. As i have 32 GB RAM, nominally ~16 GB is allocated. In practice, every time i monitor /tmp it seems to sit at ~15.2 GB free [per Dolphin].

So here's my crazy "what-if" speculation... what if occasionally/rarely, "something" [what???] happens [goes wrong?] that suddenly eats up all the remaining free space in /tmp... wouldn't that then crash the system, possibly manifesting as one of those rare freezes? There's probably so many holes in this speculation that you can drive a truck through them, & i'm extremely reluctant to stop running /tmp in RAM "just in case" [given i have no proof, & it's doubtless a stupid thing to worry about as a potential root cause of the freezes]. Anyway, i do monitor /tmp in Dolphin very often, & have never yet seen any evidence of dangerously low free space in it. 
Sounds like you know what your doing, and there's plenty of ram there.
You can run that command. No decorations or kwin effects will change.
Timeshift, ukuu, aptik, are all immensely useful tools. I have them installed.

Here's a good read...
(18th January 2017, 9:40)Pliny.D.Elder Wrote: [ -> ]You could try one of these possible solutions.
And this an old post but looks promising.

I have now read those pages per your links - thanks. The key theme therein seems to be to edit grub from its Maui-standard:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" become:
GRUB_CMDLINE_LINUX_DEFAULT="atkdb.reset i8042.nomux quiet splash"
The link says "This also works on 16.04".

My associated question is this; the context for that putative solution on those pages is "Every time it resumes from being suspended, neither the keyboard nor mouse work". However that is not a fair description of my scenario. I Suspend both my Tower & my Lappy [each runs Maui] every night, before going to bed, then Resume them the following day to continue my activities. As best i can recollect, Lappy's Maui has never misbehaved with the dead lockscreen at Resume, & though Tower has done so, it is once-only since my 31/12/16 rebuild, & maybe twice maximum since my Sept 2016 original installation, until 31/12. 

That being so, do you Pliny, or you leszek, or anyone else who cares to comment, really feel my rare instances of this fault justify making that grub edit? I am not resistant to it, only i want to know that any change i make is actually valid AND necessary [oh, & not with bad side-effects either, of course]. 
(19th January 2017, 9:05)Pliny.D.Elder Wrote: [ -> ]Sounds like you know what your doing, and there's plenty of ram there.
You can run that command. No decorations or kwin effects will change.
Timeshift, ukuu, aptik, are all immensely useful tools. I have them installed.

Here's a good read...

Yes, Pjotr's stuff is good, isn't it? I have that linked page already bookmarked & i used it during my post-installation optimisation of Maui. I used its predecessor page a few years ago for the same reason in Mint 17.x KDE. 

Thanks for the reassurance for Timeshift. I already use TeeJee's Aptik [fantastic!], so i will now tryout his TS too. 

So you don't reckon my "Mad Speculation" tmpfs /tmp idea holds any water? Fine, i am most happy to now officially ditch that crazy what-if. 

Have now run this & rebooted [nothing seemed to explode]:
sudo apt-get install --reinstall xserver-xorg-input-all kwin
Further to my "18/1/17 EDIT" in my OP above:   This morning, after Resuming Tower, & successfully unlocking lock-screen, & using pc for less than 5', it AGAIN abruptly entirely locked up / froze ... dead to all inputs (including REISUB], again. Only a hard reset was possible, again. This is now the 4th Hard Reset needed since my 31/12/16 Maui clean reinstallation.

As i had to do this hard reset now anyway, i chose to insert my Maui Live USB stick into the port before pressing the button, to boot from it, & thence again run fsck on both /sda5 [= /] & /sda6 [= DATA]. Both were clean, again.

I rebooted after this, still from LiveUSB, but this time did not let the Live Maui session start, instead i picked its 3rd boot option to check the file system. It generated the usual sky blue Maui splash screen but with a white-font msg that it was checking ... something something ... but i recall it included the word "casper" in it. This took several minutes to run, at the end of which it said 1 error was found & told me to reboot. It gave no info about this error [where was it? what was it? was it fixed?].

Disappointed, confused...
Due to this morning’s latest freeze, i decided reluctantly it is time to stop resisting the prior recommendations of leszek, Pliny & Rocky, to test my system reliability after changing from the NVidia proprietary GPU driver to the Nouveau driver. My erstwhile intransigence was due to my misapprehension that this would prevent me using 1920 x 1080 screen resolution, & also disable at least some of my KWin Desktop Effects*

Having now changed to the Nouveau driver & rebooted again, i feel rather foolish for my previous stubbornness:
1.Screen resolution is still good @ the same 1920 x 1080.
2.ALL my previously set Screen Edges & Desktop Effects continue to work just fine:
   a) Desktop Grid [screen bottom edge]
   b) Present Windows - All Desktops [screen RHS edge]
   c) Present Windows - Current Desktop [screen LHS edge]
   d) Activities [Screen Top RHS Corner]
   e) Desktop Cube [Screen Top RHS Corner]
   f) Show Desktop [Screen Bottom RHS Corner]
   g) Wobbly Windows, Zoom, Screen Edge, Thumbnail Aside, Magic Lamp, Slide Back.

* I had tried the Nouveau driver back in my Mint 17.x KDE4 days, & it definitely did muck up at least some of the KWin Desktop Effects, but clearly the Ubuntu / KDE Neon / Maui Devs must have resolved that problem since then. 

So, time will tell if this improves my system reliability... Fingers crossed.
Hi kdemeoz,

Nouveau has gone a loooong way since Mint 17 & KDE4 days. For an old card like you have, I would maybe even go so far and say it's a better solution than the proprietary driver (maybe not for gaming, but for desktop definitely). My friend has an even older Nvidia card (but not so old that it would fall into legacy driver support) and Maui doesn't even come up with proprietary driver - it says that no OpenGL 2.1 support was found. But with Nouveau ALL works correctly. So I have only good experience with Nouveau. Of course, you cannot try it with the newest Nvidia cards, but with Kepler and older ones I would say that the experience is very good (especially if gaming is not required).
Hi Rocky

Well that's great to hear about the Nouveau progress. I'm still feeling rather silly for my previous naive stubbornness, & [especially given the apparently improved Nouveau design] am now feeling cautiously optimistic that now i'm finally using it, hopefully those irritating freezes will be a thing of the past...

Just to clarify... this thread concerns my Tower, not my Lappy. In you correctly recognised that my Lappy's "NVIDIA Corporation GF108M [GeForce GT 420M] [10de:0df1] (rev a1) (prog-if 00 [VGA controller])" was rather elderly. However my Tower is newer than my Lappy, & its GPU is "NVIDIA GF119 [GeForce GT 610] bus-ID: 01:00.0". I've now modified this thread's subject line to make it easier to tell to which pc it applies. Sorry for the confusion.

Nvidia series 600 (first Kepler cards) is in the same basket as Nvidia series 400 (Fermi architecture), when it comes to Nouveau. All cards up to the Kepler architecture (which ends with some Nvidia GT 8xx - 800 was mixed Kepler/Maxwell) should work fine, since they all have re-clocking enabled.
Gloom, doom, melancholy.

Another morning, another system lock-up [but with a twist], another Hard Reset [again, REISUB also failed].

Last night as i prepared for bed i Suspended the Tower as usual, but noticed it took a few seconds longer than usual to complete that process [usually extremely quick, but clearly perceptibly slower last night]. I clearly recall saying to myself then, "uh oh, that's different, i wonder if i'll have trouble tomorrow morning?".

Sure enough, this morning i Resumed, & was struck with the instant visual indicator of "uh oh"... instead of the Lock Screen, i was looking at one of my open programs on one of my VDs [= Bad Thing #1], & next i realised that [almost*] all mouse & k/b inputs were dead [= Bad Thing #2]. Somewhere hidden "behind" the frozen Plasmashell, Maui itself was apparently still operating to some extent, as i heard the audible indicator of new emails being received by Thunderbird [one of the several pgms open when i Suspended last night].

* I could still toggle over to TTY2, where i logged in & tried:
sudo systemctl restart sddm
This instantly took me to a normal-looking Plasmashell Login Screen, except all inputs remained dead, so it was of no practical use to me. I returned to TTY2 & then tried:
loginctl unlock-sessions
I knew that was not really appropriate, but hey, was getting desperate... It indicated success, but when i toggled back to TTY7, the same Login Screen was still dead re inputs. However now, i was stuck here; i could no longer return to TTY2.

I tried REISUB, but it was completely ignored. I had to Hard Reset [ie, = 5th Hard Reset needed since my 31/12/16 Maui clean reinstallation, & 1st since changing from NVidia to Nouveau GPU driver only two days ago]. 

Gloom, doom, melancholy.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16