Login

***starbuck*** · 4th March 2017, 17:09

Small comfort: If you reinstall, you could go with Maui 17.03 right away.

**AJSlye**

(4th March 2017, 15:59)kdemeoz Wrote: Just tried to get TeeJee's Timeshift to restore its 23Feb Snapshot [running TS from within Live session, which is one of its claims]. However, it fell over at the first hurdle:

Code:
"Error Failed to mount devices"
Another step closer to new reinstallation, it appears. :-(

Now, now, If you have your home and DATA directories encrypted, then how did you expect this utility from a live session to mount and/or access these? Timeshift would need to be able to decrypt these partition prior to mounting them. I do believe, you would need to decrypt them yourself first.

kdemeoz · 5th March 2017, 0:06

(4th March 2017, 17:09)starbuck Wrote: Small comfort: If you reinstall, you could go with Maui 17.03 right away.

17.03 ? Current Maui is 2.1, so that's a surprising leap. Pls can you help me better understand?

kdemeoz

(4th March 2017, 23:00)AJSlye Wrote:
(4th March 2017, 15:59)kdemeoz Wrote: Just tried to get TeeJee's Timeshift to restore its 23Feb Snapshot [running TS from within Live session, which is one of its claims]. However, it fell over at the first hurdle:

Code:
"Error Failed to mount devices"
Another step closer to new reinstallation, it appears. :-(

Now, now, If you have your home and DATA directories encrypted, then how did you expect this utility from a live session to mount and/or access these? Timeshift would need to be able to decrypt these partition prior to mounting them. I do believe, you would need to decrypt them yourself first.

Ah, yes, fair point. Oh well, that's another recovery option eliminated.

Any further / final chroot suggestions pls?

**leszek** · 5th March 2017, 0:09

Versioning changed. We now added the year at the beginning. So 17 stands for 2017.
03 stands for 3rd release of Maui and also March release.
Future versions will be based on year and month as far as I understood.

kdemeoz

(5th March 2017, 0:09)leszek Wrote: Versioning changed. We now added the year at the beginning. So 17 stands for 2017.
03 stands for 3rd release of Maui and also March release.
Future versions will be based on year and month as far as I understood.

Aha, ok, thank you. It must have been a timing conflict, as yesterday when i checked the Maui blog there was nothing about the new release [hence i had no idea it existed already], but this morning the info is all there!

For the record, i remain very upset that it's come to this... a broken system & a necessary reinstallation. Had i been doing some crazy-mad cutting-edge experimentation with radical h/w & kernels, maybe i'd not be surprised... but all i was doing was simply using my standard system, doing humdrum day to day vanilla stuff. It should not have come to this disaster.

Finally, as the realisation dawned stronger & stronger on me over the past couple of days that my system apparently really IS irretrievably dead & hence i probably was going to have to reinstall, i've been agonising about the question/choice of the damn GPU. For better or worse i've decided to keep the Nvidia GT610 out of the Tower & just use the integrated Intel. That has seemed to be ok in all the subsequent LiveUSB sessions i've done since the cold-boot [before which the screen had no HDMI signal at all], & i suppose on that basis i should feel encouraged that it'll probably also be good enough once Tower is properly running again. I have a kind of foreboding though that if it's not good & i have to reinstall the Nvidia, everything might go to hell in a handbasket once again. Yes, i'm feeling pretty battered, bruised & uncertain at the moment...

kdemeoz · 6th March 2017, 14:21

Tower is finally back in business, again, with 17.03 Plasma 5.9.3. It also was so, 24 hrs ago, until i "cleverly" bricked it by accidentally/carelessly restoring a large swathe of old 2.1 Plasma 5.8.4 config files from an Aptik backup. Maui didn't like that at all, going all weird immediately, & then entirely failing to boot [horrible nasty errors on-screen about all sorts of missing stuff].

Anyway, Tower is now still running without the Nvidia gpu card installed, & so far the integrated Intel gpu seems to be doing quite ok [although the Cairo-Dock does occasionally exhibit high frequency "trembles" now, which did not occur with Nvidia]. Other than that, graphically it seems to be quite sweet... though the big question will be ... have the terrible freezes now gone away?

However, the bad thing that is now present, without the Nvidia, is that there is no sound output at all from the standard rear-panel port into which my speakers used to connect. I knew from previous inxi command outputs that the Nvidia was handling the graphics and audio, but i expected then the Intel would also take over the audio, given the current inxi:

Code:
Graphics:  Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller

           Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.00hz

           GLX Renderer: Mesa DRI Intel Haswell Desktop GLX Version: 3.0 Mesa 12.0.6

Audio:     Card-1 Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller driver: snd_hda_intel

           Card-2 Intel 9 Series Family HD Audio Controller driver: snd_hda_intel

           Sound: Advanced Linux Sound Architecture v: k4.4.0-65-generic

But clearly something's wrong. For now, all i have managed is to plug the speakers into the front-panel headphone port [yes, i know that's wrong], so at least now i hear faint audio... it's waaaaaaaaaaaaay too quiet.

It would be ironic if i end up needing to reinstall the Nvidia not for urgent graphics needs, but for audio...

kdemeoz · 8th March 2017, 7:23

Oh dear. Tower just suffered another complete freeze requiring hard-reset. First since i rebuilt it after the recent disaster, ie, first with Maui 17.03 Plasma 5.9.3, + with NO Nvidia GT610 gpu installed [only the integrated Intel GPU], + HWE. Unbelievable!!!

It occurred at 14:45, almost immediately that Update Manager had just completed some important updates, including kernel 4.8.0-39 to 4.8.0-41 [also 4.4.0-65 to 4.4.0-66], network-manager, & desktop-file-utils. I had just begun closing my open pgms to do the reboot, when it all froze.

Here's an excerpt from syslog spanning the critical time, but i cannot see anything overtly nasty; just a prominent time-gap at the important moment:

Code:
Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Started ACPI event daemon.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Reloading D-Bus System Message Bus.

Mar  8 14:44:39 GA-Z97-HD3 dbus-daemon[1112]: Unknown username "whoopsie" in message bus configuration file

Mar  8 14:44:39 GA-Z97-HD3 dbus[1112]: [system] Reloaded configuration

Mar  8 14:44:39 GA-Z97-HD3 dbus-send[21075]: method return time=1488944679.550282 sender=org.freedesktop.DBus -> destination=:1.378 serial=3 reply_serial=2

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Reloaded D-Bus System Message Bus.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Reloading.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Configuration file /etc/systemd/system/vyprvpn.service is marked executable. Please remove executable permission bits. Proceeding anyway.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: [/etc/systemd/system/vyprvpn.service:9] Executable path is not absolute, ignoring: killall vyprvpn_service

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: apt-daily.timer: Adding 8h 39min 56.168679s random time.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: snapd.refresh.timer: Adding 1h 58min 27.196036s random time.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Started CUPS Scheduler.

Mar  8 14:44:39 GA-Z97-HD3 systemd[1]: Started ACPI event daemon.

Mar  8 14:50:14 GA-Z97-HD3 rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="1142" x-info="http://www.rsyslog.com"] start

Mar  8 14:50:14 GA-Z97-HD3 rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]

Mar  8 14:50:14 GA-Z97-HD3 rsyslogd: rsyslogd's groupid changed to 108

Mar  8 14:50:14 GA-Z97-HD3 rsyslogd: rsyslogd's userid changed to 104

Mar  8 14:50:14 GA-Z97-HD3 systemd-modules-load[391]: Inserted module 'lp'

Mar  8 14:50:14 GA-Z97-HD3 systemd-modules-load[391]: Inserted module 'ppdev'

Mar  8 14:50:14 GA-Z97-HD3 loadkeys[390]: Loading /etc/console-setup/cached.kmap.gz

Mar  8 14:50:14 GA-Z97-HD3 resolvconf[414]: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

Mar  8 14:50:14 GA-Z97-HD3 systemd[1]: Started udev Kernel Device Manager.

Note that I manually inserted the blank line here for emphasis; the original file is continuous.

Whilst it makes no sense to me that the updates should have triggered this bad reaction, i find the timing to be more than innocently coincidental [also the absence of "bad stuff" in the log], so for now i shall assume this was a once-off incident rather than yet another failure in the litany of this thread. However, if there is even one more repeat of this after now, i shall immediately reinstall the Nvidia gpu & abandon this experiment [ie, the working hypothesis that the Nvidia gpu was causing all these freezes would then be disproved].

This is all just so exasperating.

kdemeoz · 8th April 2017, 3:39

It's now a solid month of operation without a single further freeze. My 6 March comment remains applicable:

Quote:Tower is now still running without the Nvidia gpu card installed, & so far the integrated Intel gpu seems to be doing quite ok [although the Cairo-Dock does occasionally exhibit high frequency "trembles" now, which did not occur with Nvidia]. Other than that, graphically it seems to be quite sweet

It is tempting to conclude that the root cause of all those myriad freezes was the Nvidia gpu card, & indeed maybe it was [if so, WHY?]. However, there's another factor which instead might be the cause, or it might have been a combination of both. Way back on the day when i reluctantly pulled out the Tower from under my desk [sitting on a timber board which itself sat on the carpeted floor], & then removed the casing's side panel to access the interior, i was shocked to discover that everything was covered [quite thickly in places] with lint/fluff from the carpet & general airborne particles. By everything i include the cpu, the gpu... AND the power-supply.

Now, a possible thermal overload had long been one of my theories all along, but i had never been able to fully believe it as i very frequently monitor all the measured temperatures with Psensor, & its reported temps for MB, CPU & GPU were many tens of degrees below each of their OEM's spec limits, every time i checked. The PSU however was not monitored, & frankly it never crossed my mind that it might be vulnerable. Once i saw how thickly it was covered in lint, including its air inlet, i wondered if that might have been the cause of the frequent random freezes, & maybe not the GPU at all...?

I'll never know, because now that the Tower has proven to be reliable again [& now sits on top of my desk, >1m above the carpet], i'm not willing to experiment by reinstalling the Nvidia GPU & fighting all over again with its drivers [& of course thereby risking a possible new outbreak of freezes].

I am now marking this thread as SOLVED, & i'd like to thank all those who generously & patiently helped me along the way.

**leszek** · 8th April 2017, 9:05

As for the nvidia card. I doubt that nvidia and nouveau screwed up their drivers. But maybe the hardware had the issues and a combindation of dust and the flawed card might be the issue. All speculation though.

Glad that it works for you.
Btw. As an alternative to cairo dock perhaps take a look at latte dock one of the new additions to plasma by some third party developer that got high praises lately.

Login
Username:
Password:	Lost Password?
	Remember me