LM18.3 Cinnamon merkwürdiger Absturz, persönliches Verzeichnis weg
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
19.08.2018, 13:59:45

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
Statistiken
  • Beiträge insgesamt: 544381
  • Themen insgesamt: 43754
  • Heute online: 370
  • Am meisten online: 680
  • (27.03.2018, 20:17:41)
Benutzer Online

Autor Thema:  LM18.3 Cinnamon merkwürdiger Absturz, persönliches Verzeichnis weg  (Gelesen 1300 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Moin,
gestern Abend hatte ich mein erstes echtes Negativerlebnis mit LM18.3 Cinnamon.

Mitten im Schreiben eines Themas hier im Bord unter Verwendung des google-chrome Browsers meldete sich kurz das google-calender Applet zur Sicherheitsabfrage des Google-Acounts, die Icons auf dem Schreibtisch verschwanden in kurzer Folge bald darauf wurde der Bildschirm dunkel und und kurz darauf öffnete sich der lightdm Benutzer Login. Dort fiel mir sofort auf das außer meinem Benutzer mein Notfalluser nicht mehr zur Auswahl stand. Ich logte mich ein und mir wurde der eigentlich abgewählte Willkommensbildschirm angezeigt, mmh. Mein angepasstes Haupt-Menü war inhaltlich komplett auf Standard zurückgestellt, aber Alle bisher installierten Anwendungen waren noch erhalten. Persönlicher Hintergrund, persönlich angepasste Theme, Leisteneinstellungen, Batterie Leisten-Applet, google-calendar und Wetter Desklets sowie Dokumentenverknüpfungen auf dem Schreibtisch waren weg, alles auf Standard.

OK dachte ich mir und wollte auf einen vor Kernel 4.4.0.130 mit Systemback angelegten Wiederherstellungspunkt zurücksetzen, aber es stand keiner der vier zuvor existierenden Punkte mehr zur Verfügung. Im /home auf eigener Partition (sda7) gab es nur noch mein Benutzerverzeichnis, kein Verzeichnis von: admin, lost+found und Systemback, wie kann das sein?

Edit: Nach einem Neustart stellt ich fest das grub ebenfalls defekt war, meine Reparaturversuche schlugen fehl. Edit-Ende.
Über meinen xfce-mini Notfallstick bootete ich und konnte meine kürzlich noch unter Kernel 4.4.0-124 mit qt5-fsarchiver angelegten Partitionen /root (sda5) und /home (sda7) zurückspielen.

Erkenntnis: das Systembackverzeichnis wird zukünftig nach Erstellen eines Wiederherstellungspunktes sofort extern gesichert, ich muss das erst noch manuell erledigen da meine Datenpartitionen noch ntfs Formatiert sind und Systemback nur auf ext formatierte Partitionen sichern kann.

Nun läufts erst mal wieder wenn gleich noch einiges zu tun ist, aber ein bitterer Nachgeschmack bleibt auf das Warum?

Ich hänge mal einen aktuellen Systemüberblick an:
~ $ inxi -Fz
System:    Host: K52jc-lm18 Kernel: 4.4.0-130-generic x86_64 bits: 64 Desktop: Cinnamon 3.6.7
           Distro: Linux Mint 18.3 Sylvia
Machine:   Type: Laptop System: ASUSTeK product: K52Jc v: 1.0 serial: <filter>
           Mobo: ASUSTeK model: K52Jc v: 1.0 serial: <filter> BIOS: American Megatrends v: K52Jc.216
           date: 01/25/2011
Battery:   ID-1: BAT0 charge: 18.3 Wh condition: 70.3/75.9 Wh (93%)
CPU:       Topology: Dual Core model: Intel Core i5 M 460 bits: 64 type: MT MCP L2 cache: 3072 KiB
           Speed: 1599 MHz min/max: 1199/2534 MHz Core speeds (MHz): 1: 1599 2: 2133 3: 1599 4: 2266
Graphics:  Card-1: Intel Core Processor Integrated Graphics driver: i915 v: kernel
           Card-2: NVIDIA GT218M [GeForce 310M] driver: nvidia v: 340.104
           Display: x11 server: X.Org 1.18.4 driver: modesetting,nvidia resolution: 1366x768~60Hz
           OpenGL: renderer: GeForce 310M/PCIe/SSE2 v: 3.3.0 NVIDIA 340.104
Audio:     Card-1: Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel
           Sound Server: ALSA v: k4.4.0-130-generic
Network:   Card-1: Intel Wireless 7260 driver: iwlwifi
           IF: wls1 state: up mac: <filter>
           Card-2: JMicron JMC250 PCI Express Gigabit Ethernet driver: jme
           IF: ens5f5 state: down mac: <filter>
Drives:    HDD Total Size: 756.33 GiB used: 394.19 GiB (52.1%)
           ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB
           ID-2: /dev/sdb vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB
           ID-3: /dev/sdc type: USB vendor: PNY model: USB 3.0 FD size: 57.68 GiB
Partition: ID-1: / size: 19.56 GiB used: 10.31 GiB (52.7%) fs: ext4 dev: /dev/sda5
           ID-2: /home size: 49.09 GiB used: 30.91 GiB (63.0%) fs: ext4 dev: /dev/sda7
           ID-3: swap-1 size: 12.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda6
Sensors:   System Temperatures: cpu: 61.0 C mobo: N/A gpu: nvidia temp: 62 C
           Fan Speeds (RPM): N/A
Info:      Processes: 285 Uptime: 1h 22m Memory: 7.59 GiB used: 1.85 GiB (24.4%) Shell: bash inxi: 3.0.15
« Letzte Änderung: 08.07.2018, 21:19:51 von kuehhe1 »

Zitat
Erkenntnis: das Systembackverzeichnis wird zukünftig nach Erstellen eines Wiederherstellungspunktes sofort extern gesichert, ich muss das erst noch manuell erledigen da meine Datenpartitionen noch ntfs Formatiert sind und Systemback nur auf ext formatierte Partitionen sichern kann.
Genau deswegen hab ich mir gleich eine Partition extra in ext4 für Timeshift angelegt.

Dennoch klingt das sehr merkwürdig, was dir da passiert ist. Wie kann das gehen?

Dennoch klingt das sehr merkwürdig, was dir da passiert ist. Wie kann das gehen?
Stimmt, wie gesagt nichts gebastelt, aktuell geöffnet waren Thunderbird und google-chrome mit geöffneter Forumsseite und aktivem Editor.

Morgens kamen diese Upgrades herein:Commit Log for Thu Jul  5 09:24:18 2018

Die folgenden Pakete wurden aktualisiert:
inxi (3.0.13-1-1~16.04) to 3.0.15-1-1~16.04

und Mittags diese:Commit Log for Thu Jul  5 12:54:59 2018

Die folgenden Pakete wurden aktualisiert:
apt (1.2.26) to 1.2.27
apt-doc (1.2.26) to 1.2.27
apt-transport-https (1.2.26) to 1.2.27
apt-utils (1.2.26) to 1.2.27
libapt-inst2.0 (1.2.26) to 1.2.27
libapt-pkg5.0 (1.2.26) to 1.2.27
libdrm-amdgpu1 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-amdgpu1:i386 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-common (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-intel1 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-intel1:i386 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-nouveau2 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-nouveau2:i386 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-radeon1 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm-radeon1:i386 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm2 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libdrm2:i386 (2.4.83-1~16.04.1) to 2.4.91-2~16.04.1
libegl1-mesa (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libgbm1 (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libgl1-mesa-dri (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libgl1-mesa-dri:i386 (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libgl1-mesa-glx (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libgl1-mesa-glx:i386 (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libglapi-mesa (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libglapi-mesa:i386 (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libgles2-mesa (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libwayland-egl1-mesa (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
libxatracker2 (17.2.8-0ubuntu0~16.04.1) to 18.0.5-0ubuntu0~16.04.1
Anschließend verhielt sich das System bis zum Abend absolut normal.

Genau deswegen hab ich mir gleich eine Partition extra in ext4 für Timeshift angelegt.
Das werde ich bei einer zukünftigen Neuistallation hier auch berücksichtigen, dann wird zumindest Win7 gelöscht und Platz für eine zusätzliche Sicherungspartition geschaffen.
« Letzte Änderung: 06.07.2018, 20:27:25 von kuehhe1 »

@kuehe1
Ich habe dann über meinen xfce-mini Notfallstick gebootet und meine kürzlich noch unter Kernel 4.4.0-124 mit qt5-fsarchiver angelegten Partitionen meiner  /root (sda5) und /home (sda7) zurückgespielt.
Damit hat sich dein Beitrag, hinsichtlich der Ursachenforschung, aber auch (fast) erledigt.
Obwohl, oder weil, keiner möglichen Ursache mehr nachgegangen werden kann ist der Vorfall immerhin noch tauglich für ein paar gute "Verschwörungstheorien".
Schauen wir mal ob sich wer findet. Ist nicht böse gemeint.
Wäre bspw. interessant gewesen zu prüfen ob z.B. der Notfalluser (also nicht nur sein Verzeichnis unter /home) aus /etc/group verschwunden war.
Warten wir also einmal darauf ob/bis der Vorfall eine Neuauflage finden wird.  ;D
« Letzte Änderung: 06.07.2018, 16:15:06 von lmumischabln »

Damit hat sich dein Beitrag, hinsichtlich der Ursachenforschung, aber auch (fast) erledigt.
Ja das denke ich auch nach dem nächtlichen Rückspielen ist nix mehr zu reproduzieren.
Wäre bspw. interessant gewesen zu prüfen ob z.B. der Notfalluser (also nicht nur sein Verzeichnis unter /home) aus /etc/group verschwunden war.
Warten wir also einmal darauf ob/bis der Vorfall eine Neuauflage finden wird. 
auf den notfalluser in /etc/group achte ich beim nächsten mal.
Heute wurden alle Upgrades nachgeholt und ich hoffe mal vorsichtig das es sich nicht wiederholt.

Eigentlich hatte ich den Vorfall nur thematisiert da zahlreiche Upgrades der Aktualisierungsverwaltung vorausgingen, hätte ja sein können das ich nicht allein da stehe.
« Letzte Änderung: 06.07.2018, 21:35:34 von kuehhe1 »

Hallo,
wenn mir mal so etwas passieren sollte, was bisher noch nicht vorgekommen ist, würde ich als erstes in den syslog gucken.
Eventuell, kann man da schon nachvollziehen was passiert sein könnte.

würde ich als erstes in den syslog gucken.
Eventuell, kann man da schon nachvollziehen was passiert sein könnte.
du wirst es nicht glauben, aber das syslog hatte ich noch gesichert. Wer sich darin besonders gut auskennt könnte mal einen Blick hineinwerfen, die Crashzeit war am 5.7.2018 bei ca.19:00-19:30h gegen Ende des logs. Die Suche darin nach "BAD" und "crash" zeigt einiges und obwohl die angezeigten Speicherfehler schon sei längerer Zeit darin auftauchen zeigen sie sich nicht im Speichertest aus Grub heraus.

Persönlicher Hintergrund, persönlich angepasste Theme, Leisteneinstellungen, Batterie Leisten-Applet, google-calendar und Wetter Desklets sowie Dokumentenverknüpfungen auf dem Schreibtisch waren weg, alles auf Standard.
...
Partitionen meiner  /root (sda5) und /home (sda7) zurückgespielt.
...
Warum?
So wie du das hier beschreibst, wird schlicht und ergreifend deine home-Partition nicht eingehängt gewesen sein. Hast du denn vor dem Zurückschreiben überprüft, ob von dieser die Daten überhaupt gelöscht waren oder hast du sie einfach so wieder hergestellt?

Wenn du möchtest, kannst du das ganze auch noch einmal nachvollziehen, dazu brauchst du nur die Zeile dein /home betreffend in der fstab auskommentieren und neu zu starten.

So wie du das hier beschreibst, wird schlicht und ergreifend deine home-Partition nicht eingehängt gewesen sein.
die /home ausgehängt das kann eigentlich nicht sein, denn zum einem hatte ich den Rechner bereits längere Zeit mit Büroarbeit in Benutzung und mitten im hiesigen Forumsposting stieg Cinnamon aus. Wer oder Was sollte die home-Partition ausgehängt haben. Außerdem zeigte das Tool Laufwerke alle Partionen als Eingehängt an und mit nemo konnte ich auf Dateien z.B. im ~/Downloads,  ~/Bilder,  ~/Dokumente zugreifen. Einzig nicht mehr vollständig war der Inhalt von ~/.cinnamon/config, da fehlte vieles an Verzeichnissen.

Im weiteren Verlauf stellte ich nach Neustart fest das grub ebenfalls defekt war, denn beim Booten wurde gemeldet das kein Betriebssystem vorhanden sei. Zuerst hatte ich noch versucht grub mit einem 18.3 Life-Stick und der SG2D und der chroot Methode zu reparieren aber das scheiterte an einer Fehlermeldung nach dem vierten Befehl:sudo mount /dev/sda1 /mnt
sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /sys /mnt/sys
sudo mount -t proc /proc /mnt/proc
in der Art: ~ Verzeichnis nicht gefunden, den genauen Wortlaut habe ich mir (leider) nicht notiert, es war auch das erste Mal das ich mich an die chroot Methode heranwagte. Mich würde es schon interessieren was ich da falsch gemacht habe oder haben könnte.
Erst als die Rettungsversuche nichts bewirkten hab ich die Partionen sda5 ( / ) und sda7 ( /home ) mit qt5-fsarchiver und gesicherten Backups wiederhergestellt.

Wenn du möchtest, kannst du das ganze auch noch einmal nachvollziehen, dazu brauchst du nur die Zeile dein /home betreffend in der fstab auskommentieren und neu zu starten.
erst bei übernächster Gelegenheit denn ich bin Froh das mein Produktivsystem wieder läuft. ;)
« Letzte Änderung: 09.07.2018, 09:02:01 von kuehhe1 »

So wie du das hier beschreibst, wird schlicht und ergreifend deine home-Partition nicht eingehängt gewesen sein.

Wenn du möchtest, kannst du das ganze auch noch einmal nachvollziehen, dazu brauchst du nur die Zeile dein /home betreffend in der fstab auskommentieren und neu zu starten.
Ich hab das gerade mal getestet,
meine /home Partition (sda7) in der fstab auskommentiert und geschaut ob ich noch an meine Einstellungen und Verzeichnisse im ~/ gelange, das funktioniert weiterhin alles einwandfrei. Erst nach Neustart gibts Probleme, dann komme ich noch bis zum lightdm Anmeldefenster aber die Anmeldung gelingt nicht, nach Eingabe des Benutzerkennwortes gehts wieder zur Anmeldung, quasi Endlosschleife. Das Aushängen der /home (sda7) kann also nicht die Ursache gewesen sein.
« Letzte Änderung: 09.07.2018, 13:54:39 von kuehhe1 »

Verschwörungstheorien an!

Das könnte auch auf Hardwarefehler hinweisen, vielleicht steigt der Controler der Platte aus, oder Netzteil altert langsam, oder das Board gibt auf. Könnte sovieles sein.

Netzteil an sich scheidet beim Notebook aus,
Akku ist 6 Wochen alt, tlp sagt i.O:+++ Battery Status
/sys/class/power_supply/BAT0/manufacturer                   = ASUSTek
/sys/class/power_supply/BAT0/model_name                     = K52F-44
/sys/class/power_supply/BAT0/cycle_count                    = (not supported)
/sys/class/power_supply/BAT0/energy_full_design             =  75900 [mWh]
/sys/class/power_supply/BAT0/energy_full                    =  70268 [mWh]
/sys/class/power_supply/BAT0/energy_now                     =  68013 [mWh]
/sys/class/power_supply/BAT0/power_now                      =   9229 [mW]
/sys/class/power_supply/BAT0/status                         = Charging

die Beiden Samsung SSD evo850 250/500GB verhalten sich bisher normal, aber Laufwerk sda 250GB (enthält die / Part.) zeigt im Laufwerke-Tool eine UDMA-CRC Fehlerrate von 330 an, was bedeutet dabei der Wert 99 "Normalisiert"?
smart sda
smart sda
Da muß ich das Samsung Tool "Magician" bemühen, Samsung bietet es leider nur für Win an, gibts das eigentlich auch für Linux/Ubuntu?
« Letzte Änderung: 10.07.2018, 17:25:24 von kuehhe1 »

Die Antwort ist einfach: SSD, Controler oder Board sind defekt (gewichtet nach Warscheinlichkeit).
Hab mal bei mir den SSD-UDMA-CRC Wert angeschaut = 0.
Das hört sich bei Dir gar nicht gesund an.

Prüfe das SATA Kabel. Gegebenfals nimm welche mit Verriegelung.
Wenn OK, dann raus mit dem Ding, sonst wirst Du nicht glücklich.

Zitat
Magician
Gibt es nicht für Linux.
« Letzte Änderung: 10.07.2018, 00:33:04 von Linux_4_Ever »

Prüfe das SATA Kabel. Gegebenfals nimm welche mit Verriegelung.
Die SSD steckt fest im Notebook, da gibts kein Kabel.

Hab mal bei mir den SSD-UDMA-CRC Wert angeschaut = 0.
als Refferenz hab ich meine zweite "SSD Samsung evo 850 500GB" gecheckt, die zeigt einen UDMA-CRC Fehlerwert von 0.

Ich bin nun überfragt ob ich die SSD Reklamieren kann, Samsung gibt ja 5 Jahre Garantie oder einen max. TBW Wert (Total Bytes Written) von 75 TB und der aktuelle TBW Wert liegt laut Magician bei 7,9TB. Samsung Spezifikation: https://www.samsung.com/de/memory-storage/850-evo-sata-3-2-5-inch-ssd/MZ-75E250BEU/#specs

EDIT: Win 10 gebootet,
Magician zeigt es anders detailiert an als das Tool "Laufwerke", es meldet ebenfalls UDMA-CRC Fehler: 99 Ist, 330 Raw Data, Zustand "GUT".
Screenshot Win10>Magician:
Magician CRC Fehler Samsung 250 GB
Magician CRC Fehler Samsung 250 GB

Ein Test mit dem Win Tool "Everest Ultimate Edition" meldet Ultra-ATA CRC Fehler: 99 Ist, 330 Daten, Status: OK: Keine Fehler.
Screenshot Win10>Everest:
Everest CRC Fehler Samsung 250 GB
Everest CRC Fehler Samsung 250 GB


Somit sind die ausgelesenen Smartwerte der Tools "Laufwerke", "Magician" und "Everest Ultimate" ersteinmal identisch.

Nun muss man noch die Werte relativieren, Laufwerke stellt den Wert von 330, Raw Data (Rohdaten) in erster Spalte dar, klar das man da schnell ins grübeln kommt. Sieht man sich die Fehlerbeschreibung (Spaltentexte) genauer an sieht es schon wieder anders aus und in welchem Verhältnis steht Raw Data zu Current Value (99) und Worst Value (99)?

Sicher ist ein Wert größer als "0" schlechter aber fraglich ist auch ob ein Wert von 99 als absolut kritisch anzusehen ist, denn alle drei Tools melden gleichzeitig ein: OK !?

Dumm ist, das die aufgelaufenen UDMA-CRC Fehler keinen Zeitstempel benutzen, ohne Protokoll weis man gar nicht wie lang sie zurückliegen so es ist einfach die Summe aufgelaufener Fehler.

Ich habe mir schon mal die Rechnung herausgesucht und werde den Samsung und Amazon Support ansprechen mal sehen was sich ergibt. Weiterhin werden die SMART-Werte im Auge behalten.

Für weitere Ratschläge wäre ich dankbar.

« Letzte Änderung: 13.07.2018, 19:25:56 von kuehhe1 »

Hallo noch mal,
ich hab Antwort vom Samsung Support erhalten.
Zitat
Um heraus zu finde ob es die SSD ist oder das Kabel/Port, könnten Sie die SSD vielleicht an einem anderen Rechner eine Zeit laufen lassen und dann den Test nochmal durchführen. Wenn der Wert stehen bleibt, lag es am Rechner, sollte der Wert auch an einem anderen PC steigen, liegt es eher an der SSD.

Problem ist, ich habe keinen zweiten Rechner und zum Anderen hat sich der UDMA-CRC Wert von 330 nicht erhöht. Ich weis ja auch gar nicht wann der Wert hochgelaufen ist.

Der Support möchte gern ausschließen das die SATA Datenverbindung zur SSD sda keinen Defekt hat, andererseits wäre eine schlechte Verbindung vorhanden würde sich doch der Wert verändern. Auf Klopfen (Erschütterung), Temperaturwechsel und mechanisches Druck während des Betriebes auf den SATA Sockel des Boards erfolgt keine Reaktionen der BS oder UDMA-CRC Wert-Änderung.

Hat Jemand bereits ähnliche Fehler bei einer Samsung SSD EVO 250gb festgestellt?

« Letzte Änderung: 16.07.2018, 10:06:40 von kuehhe1 »