KDE catastrophe

[jaegermeister]

Hello,

today i switched the system on and, after logon in lightdm, KDE splash screen took ages to clear, plasma desktop also, kmenu tray etc are disappeared, dolphin takes ages and then also plasma crashes.

It's a similar situation to what I had on a previous install which made me go fresh install with the latest 2014.1.

Basically, before showing up, last modifications to system were a small du (yes, in init 3) and the installation of kdeconnect (which was in tray... maybe this??? a problem similar to the one I reported about milou, but completely untied to .kde/ files, as going with a default new profile does not change anything).

So, before reinstalling the whole machine I would like to hear your suggestions, also because if I do not understand what the hell happened, this may show up again. I can produce any needed output in order to debug, but at the moment I have no clues.

Please help!
THX

[michaaa62]

Did you check for available space in RAM, swap-, root- and home-partitions?

Code: [Select]

free
df

[jaegermeister]

This is a 24GB RAM box and plenty of storage, have fun with stats:

             total       used       free     shared    buffers     cached
Mem:      24677652    4027096   20650556      12484      82540    1551640
-/+ buffers/cache:    2392916   22284736
Swap:            0          0          0

/dev/sda2      xfs        30G   15G     15G  51% /
udev           devtmpfs   10M     0     10M   0% /dev
tmpfs          tmpfs     4,8G  2,1M    4,8G   1% /run
tmpfs          tmpfs      12G   84K     12G   1% /dev/shm
tmpfs          tmpfs     5,0M  8,0K    5,0M   1% /run/lock
tmpfs          tmpfs      12G     0     12G   0% /sys/fs/cgroup
/dev/sdc1      xfs       280G   88G    192G  32% /mnt/w
/dev/sdb1      xfs       1,9T  754G    1,1T  41% /mnt/x
/dev/sda1      fuseblk    50G   31G     20G  61% /mnt/c
/dev/sda3      xfs       194G  115G     79G  60% /home
tmpfs          tmpfs     2,4G  4,0K    2,4G   1% /run/user/1000
tmpfs          tmpfs     2,4G     0    2,4G   0% /run/user/0
tmpfs          tmpfs     2,4G  4,0K    2,4G   1% /run/user/105

I do not think it's anywhere close to the solution.

[dibl]

Is it all the same hardware that ate your earlier system?  If so, I would start taking a hard look at the memory and also the GPU and its memory.

[ayla]

Is it all the same hardware that ate your earlier system?  If so, I would start taking a hard look at the memory and also the GPU and its memory.

and also check your drive for read errors. If you have a lot of them, check your SATA-cables. If there are cheap ones, especially without clip to hold it in position, try better ones. That made me install my system a few times a while ago till I got it...

greets ayla

[sunrat]

Concerning kdeconnect, my system is running perfectly since installing it. 64 bit December with kdenext and recently d-u.

[musca]

hello jaegermeister ( heh, i must smile everytime i see that name),

please login in text mode as user and "mv .kde .kde-old". (this will force KDE to create a new profile for your user).

Alternatively you can create a new user 

Both procedures will show you if the kde software or your user profile is broken.


greetings
musca

[jaegermeister]

Hello,

a general catch-all answer:

- no the hardware is different
- I am running on SAS disks but will eventually change them to clear up doubts
- been running on xfs since sidux times not a single glitch; a blackout once killed an ext3 sys of mine, xfs is a tank!
- already created a new profile, also had a spare one I created when there was the milou incident, none worked, therefore is KDE plasma borked
- I also think that kdeconnect has nothing to do with the incident

Any other ideas?
THX

[absolut]

just for the sake of completeness: did you run memtest and check s.m.a.r.t. status of the drive(s)?

[jaegermeister]

smart status of system disk is "OK", nevertheless next week will be changed with a new SAS disk
memtest 5.01 does not provide any single error, but runs blazingly fast

is there a way to completely reset KDE without reinstalling the system?
from dpkg-reconfigure till black magic suggestions are welcome!!!

[belze]

have you tried to set a new kde profile?
first backup your current kde profile (better do it in init3 or while not being logged in kde)

Code: [Select]

mv ~/.kde ~/.kde_backup
NOTE this will move everything inside that folder: amarok dbs, kdepim resources ecc

restart your DM (or reboot)

Code: [Select]

systemctl restart lightdm.service
and wait until kde creates a new profile.

It is also possible to create a new user on your box and login in kde using this new user

[jaegermeister]

Yes, as i specified in my first mail.
It's not something user/profile tied.

It's like plasma desktop files are messed up.

Right now I am, sadly, in process to transfer data and reformat, as I have put inside a brand new SAS disk.
But would rather try on the old disk to experiment, in order to see if things are solvable. Call this IT-gym....

[DeepDayze]

Is it all the same hardware that ate your earlier system?  If so, I would start taking a hard look at the memory and also the GPU and its memory.

and also check your drive for read errors. If you have a lot of them, check your SATA-cables. If there are cheap ones, especially without clip to hold it in position, try better ones. That made me install my system a few times a while ago till I got it...

greets ayla

That same bug bit me too, so I went and got some nice Asus cables compatible with my WD SATA 3 drives. The old reliables I had didn't cut it as I was getting disk errors which went away after I replaced the cables.

As for memory and GPU, yes check them too as newer kernels, mobos and other hardware can stress memory and GPU in ways that expose bugs and glitches.

[jaegermeister]

Sorry for you my friend,

I just got out of the mess this afternoon, after finishing reinstalling/migrating everything.

Nevertheless this story of the cables got me kinda dubious, as the used ones are those factory ones that link the motherboard to the SAS backplane. My hypotesis is more about the old disk (which has now been replaced) with a shiny new one (also attached to a different port with a different cable). Also, RAM shouldn't be the case because I thoroughly tested the 24GB ECC and there was no single glitch reported. Just for the records, a smartctl of the old disk:

Code: [Select]

smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.18-3.towo.2-siduction-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              ST330057SSUN300G
Revision:             0605
User Capacity:        300.000.000.000 bytes [300 GB]
Logical block size:   512 bytes
Rotation Rate:        15000 rpm
Logical Unit id:      0x5000c5000949ef03
Serial number:        000938G042EH        3SJ042EH
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Mon Jan 26 18:36:24 2015 CET
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     37 C
Drive Trip Temperature:        68 C

Manufactured in week 38 of year 2009
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  63
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 4048096758
  Blocks received from initiator = 1806038199
  Blocks read from cache and sent to initiator = 1712702269
  Number of read and write commands whose size <= segment size = 1091948753
  Number of read and write commands whose size > segment size = 498487

Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 29973,20
  number of minutes until next internal SMART test = 43

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   707373595       92         0  707373687   707373687       3211,619           0
write:         0        0         0         0          0     638749,823           0
verify: 220199186       60         0  220199246   220199260       6755,157          14

Non-medium error count:     4592

No self-tests have been logged

The almost 30.000 hours and the huge number of corrected errors could be good evidence of a crime which will never have a clear villain.