Systemstart scheitert nach Upgrade auf Jessie

[halo44]

Beim Versuch auf Debian Jessie upzugraden hatte ich gestern zunächst Probleme mit der Nvidia-Grafikkarte die aber in diesem Thread viewtopic.php?f=12&t=155697 gelöst wurden.

Leider fährt mein Debian Jessie mit systemd aber heute morgen nicht mehr hoch. Auch im recovery-Modus scheitert es. Mit sysvinit hingegen startet der Rechner.

Beim Start über systemd erfolgen zu Beginn Meldungen dieses Musters

Code: Alles auswählen
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: SET FEATURES
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 22
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }


Weitere Meldungen dieses Musters erfolgen mehrfach mit Pausen.
Dann läuft der Start weiter bis er für 1 minute und 30 Sekunden diese Meldung bringt

(1 of 2) A start job ist runing for dev-disk-by- ....


Dann gehts weiter bis ich im Emergency Mode lande. Das angebotene Kommando "journalctl -xb" ist nicht sehr hilfreich, weil die Auswertung im Emergency Mode ermüdend scheint.

Übrigens erfolgen die oben erwähnten Meldungen zu "ata1.00 usw." auch beim Start über sysvinit, aber das System kommt hoch.

Jetzt sehe ich zwei Möglichkeiten :

Entweder lade ich meine Wheezy-Sicherung mit dem Stand vom installierten nvidia-legacy Treiber zurück und führe anschließend den Upgrade auf Jessie erneut durch - oder ich versuche die Reparatur (mit Eurer Hilfe) des status quo. In diesem Fall müßte ich sicher ein neues Thema aufmachen.

Die Möglichkeit über sysvinit weiter zu fahren, möchte ich eigentlich nicht in Betracht ziehen. Schließlich läuft mein Notebook sehr gut mit systemd (Startup finished in 1.608s (kernel) + 2.745s (userspace) = 4.354s).

Was ratet Ihr mir?

Gruss H.

[rendegast]

syslog auf solche Meldungen durchforsten, auch die älteren Exemplare syslog.X.gz / messages.X.gz.
Scheint kein smart-relevanter Fehler zu sein, aber der Vollständigkeit halber auch SMART.

Hardwaretest.
Kabel zur Platte prüfen.
Stromversorgung durch Netzteil prüfen.

[halo44]

Im Moment möchte ich nur einen Zwischenstand durchgeben, da ich gleich einen auswärtigen Termin habe.

1.) Syslog wird nur bei den sysvinit-Starts geschrieben. Bei den Fehlversuchen mit systemd nicht.

2.) Gestern abend um 18:27 gelang der erste Start mit systemd. Und jetzt eben wieder um 16:12 !!!!!!

3.) Dazwischen nur Fehlstarts mit systemd. Fünf erfolgreiche Starts mit sysvinit.

4.) Bei den erfolgreichen Starts mit sysvinit scheitert allerdings der resume from RAM (Bildschirm bleibt dunkel - System muß per Power off runter gefahren werden). Also doch Probleme mit der Grafikkarte?

Später mehr.

Gruss H.

[NAB]

Deine Fehlermeldungen deuten auf Probleme eines Laufwerkes hin.

Erst mal solltest du klären, was "ata1" überhaupt ist:

Code: Alles auswählen

dmesg | grep ata1

Der Befehl, der "ata1" Probleme macht, ist dieser hier:
ata1.00: failed command: SET FEATURES

Wiederholt sich dieser Befehl, oder ändert der sich?

[KP97]

(1 of 2) A start job ist runing for dev-disk-by- ....

Und genau die Punkte sind wichtig, die solltest Du uns nicht verheimlichen.
Es könnte ein Hinweis auf ein Device in der fstab sein. Also auch prüfen...
Ich habe jetzt auch Punkte gemacht, aber ohne Hintersinn.

[halo44]

Deine Fehlermeldungen deuten auf Probleme eines Laufwerkes hin ...
...

Es sieht fast so aus. Allerdings läuft sysvinit (in der gleichen Partition wie systemd) und auch eine ebenfalls auf dem Laufwerk installierte openSuse Distribution.

Ich suche morgen weiter.

... Und genau die Punkte sind wichtig, die solltest Du uns nicht verheimlichen ...

Ich verheimliche nichts.

Mehr ist nicht zu erkennen.

Gruss H.

[towo]

blkid

und dann guckw
en, welche falsche UUID in deiner /etc/fstab steht

[NAB]

Es sieht fast so aus. Allerdings läuft sysvinit (in der gleichen Partition wie systemd) und auch eine ebenfalls auf dem Laufwerk installierte openSuse Distribution.

Ja ... es "sieht so aus" ... es könnte aber auch ganz andere Gründe haben, warum systemd scheitert - siehe die Hinweise von towo.

Es "könnte" auch sein, dass systemd auf einem defekten Teil der Festplatte liegt, Sysvinit nicht. Für genauere Spekulationen braucht's genauere Hinweise

[Taomon]

Als root:

Code: Alles auswählen

lsblk -o NAME,UUID,FSTYPE,MOUNTPOINT

Code: Alles auswählen

cat /etc/fstab

Gruß Taomon

[halo44]

Die Einträge in der /etc/fstab sind richtig. Zumal ja auch sysvinit und systemd mit der gleichen /etc/fstab arbeiten.

Trotzdem hier die gewünschten Informationen :

Code: Alles auswählen

root@dt-debian:~#     lsblk -o NAME,UUID,FSTYPE,MOUNTPOINT
NAME          UUID                                 FSTYPE      MOUNTPOINT
sda                                                            
├─sda1        cc994141-f530-4797-a038-bbf6f7b2170f ext4        
├─sda2        8bfa47d1-801b-47c2-a22c-1daba863c855 ext4        
├─sda3        faad2f33-edd8-4c64-bba6-310beceba691 swap        [SWAP]
├─sda4                                                         
├─sda5        bb3fd7f2-436f-453c-933d-dd8faa3b8578 ext4        /
├─sda6        c277ad69-b72e-4809-bcf8-606aef13d0c1 ext4        /home
└─sda7        df6c1970-250b-44c3-a722-071cd96902e1 crypto_LUKS 
  └─_dev_sda7 0df57ce1-64b8-4e33-a4b9-ddeb6e556b58 ext4        /lokalsicherung
sdb                                                            
├─sdb1        81bff621-4b5c-4c16-b3bf-9787a1b01eda crypto_LUKS 
│ └─_dev_sdb1 fb576a36-2023-46f5-a613-b66b3b632cac ext4        /Datenpartition
├─sdb2        77ddc2c1-be73-41ae-a368-de793fd33070 ext4        /Daten-1
├─sdb3        dce53eb2-443d-499f-9ffc-6de9777a522c ext4        /Daten-Zwischenspeicher
├─sdb4                                                         
├─sdb5        07a7836c-ea34-437e-9498-616d2a4f7a32 ext4        /Daten-2
├─sdb6        26d95e8f-1aea-4607-a456-de01f1247b83 ext4        /Daten-Filme
└─sdb7        7012f286-8e1d-4db4-8722-854ed1672ae0 ext4        /Daten-Sicherungen
sdc                                                            
└─sdc1        5557-E5EF                            vfat        
sr0                                                            

Die /etc/fstab :

Code: Alles auswählen

UUID=bb3fd7f2-436f-453c-933d-dd8faa3b8578 /                 ext4    errors=remount-ro,discard,noatime 0       1
UUID=c277ad69-b72e-4809-bcf8-606aef13d0c1 /home             ext4    acl,user_xattr,discard,noatime    0       2
UUID=faad2f33-edd8-4c64-bba6-310beceba691 none              swap    sw                                0       0
#
UUID=77ddc2c1-be73-41ae-a368-de793fd33070 /Daten-1     	          ext4    acl,user_xattr              1       2
UUID=07a7836c-ea34-437e-9498-616d2a4f7a32 /Daten-2	          ext4    acl,user_xattr              1       2 
UUID=26d95e8f-1aea-4607-a456-de01f1247b83 /Daten-Filme	          ext4    acl,user_xattr              1       2 
UUID=7012f286-8e1d-4db4-8722-854ed1672ae0 /Daten-Sicherungen      ext4    acl,user_xattr              1       2 
UUID=dce53eb2-443d-499f-9ffc-6de9777a522c /Daten-Zwischenspeicher ext4    acl,user_xattr              1       2
#
###############################
#  NFS-Freigaben für andere
###############################
#
/Daten-Filme				  /nfs4exports/daten-filme	 none	noauto,comment=systemd.automount,rw,bind 0 0 
#
#############################################
#  NFS- und Samba-Freigaben auf dem Notebook
#############################################
#
nb-debian:/datenpartition-notebook	  /mnt/datenpartition-notebook	 nfs4	noauto,soft,timeo=10,user 0 0 
nb-debian:/daten-1-notebook		  /mnt/daten-1-notebook	  	 nfs4	noauto,soft,timeo=10,user 0 0 
#//nb-suse/FG-Zwischenspeicher		  /mnt/zwischenspeicher-notebook cifs	noauto,soft,timeo=12,user 0 0 
#
##########################################
#  NFS-Freigaben auf ap-suse
##########################################
#
ap-suse:/daten-suse-ap			  /mnt/daten-suse-ap	  	 nfs4	noauto,soft,timeo=10,user 0 0 
ap-suse:/windows-d-ap			  /mnt/windows-d-ap	  	 nfs4	noauto,soft,timeo=10,user 0 0 
#
###############################
#  NFS-Freigaben auf dem NAS
###############################
#
NAS-01:/datenpartition-nas		  /mnt/datenpartition-nas 	 nfs4	noauto,soft,timeo=10,user 0 0 
NAS-01:/daten-1-nas			  /mnt/daten-1-nas	  	 nfs4	noauto,users 0 0 
NAS-01:/daten-filme			  /mnt/daten-filme-nas	  	 nfs4	noauto,users 0 0 
#
###############################
#  Samba-Freigabe auf dem NAS
###############################
#
//NAS-01/FG-NAS01-Filme			  /mnt/daten-filme-nas	  	 cifs	noauto,soft,user 0 0 
#
###############################################
#  Freigabe auf dem USB-Stick an der Fritzbox
###############################################
#
#//192.168.2.1/FRITZ.NAS			  /mnt/fritz-nas		 cifs	rw,user=ftpuser,passwd=62326193 0 0 
#
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sdf1       /media/usb0     auto    rw,user,noauto  0       0
/dev/sdf2       /media/usb1     auto    rw,user,noauto  0       0

Vielleicht wichtige weitere Informationen. Der betroffene Rechner läuft unter Linux immer schon nur mit der Bootoption "nolapic" oder auch "noapic".

Die Systemplatte ist eine Samsung SSD 840 EVO 250 GB. Sie war zum ersten Mal im Juli 2014 gestört und an Samsung eingeschickt. Dort wurde sie "repariert". Die zweite Störung erfolgte im Januar 2015. Diesmal tauschte Samsung sie gegen eine komplett neue SSD. In beiden Fällen ergab der smartctl Langzeittest keine Fehler.

Ich werde auch jetzt wieder diesen Langzeittest durchführen.

Gruss H.

[halo44]

Ich habe den Langzeittest noch nicht gestartet. Mich dafür aber lieber doch mal mit dem Befehl "journalctl -xb" innerhalb des emergency-Mode beschäftigt. Hierbei fand ich tatsächlich interessante Informationen.

Alle Informationen wurden bei der Ausgabe rechts abgeschnitten (Zeile zu kurz) :

Code: Alles auswählen

systemd-fstab-generator [142]: Failed to create mount u 

Code: Alles auswählen

Timed out waiting for device dev-disk-by\x

Code: Alles auswählen

dev-disk-by\x2duuid-c277ad69\x2db72e\x2d4809\x2dbcf8\x2d606aef1

Code: Alles auswählen

... Dependency failed for /home

Da scheinen wohl Probleme mit /home vorzuliegen. Obwohl sysvinit anscheinend darüber wegkommt.

Ich suche weiter.

Gruss H.

[rendegast]

Ein Fehler in fstab sollte keine ata-Fehler geben.
Der Bootvorgang würde einfach abgebrochen und der Rescue-Single-Login zur Behebung angeboten.




Mir aufgefallen:

Code: Alles auswählen

NAS-01:/daten-filme           /mnt/daten-filme-nas         nfs4   noauto,users 0 0
#
###############################
#  Samba-Freigabe auf dem NAS
###############################
#
//NAS-01/FG-NAS01-Filme           /mnt/daten-filme-nas         cifs   noauto,soft,user 0 0 

Der jeweils letzte Mount wird zwar einfach über den vorhergehenden gelegt, ist aber vielleicht so nicht gedacht.
Anwendungsprogramme mit Handles dorthin könnten Probleme bekommen.

[halo44]

... Mir aufgefallen:

Code: Alles auswählen

NAS-01:/daten-filme           /mnt/daten-filme-nas         nfs4   noauto,users 0 0
#
###############################
#  Samba-Freigabe auf dem NAS
###############################
#
//NAS-01/FG-NAS01-Filme           /mnt/daten-filme-nas         cifs   noauto,soft,user 0 0 

Der jeweils letzte Mount wird zwar einfach über den vorhergehenden gelegt, ist aber vielleicht so nicht gedacht.
Anwendungsprogramme mit Handles dorthin könnten Probleme bekommen.

Ja, eine entsprechende Meldung erfolgt auch :

Code: Alles auswählen

systemd-fstab-generator[144]: Failed to create mount unit file /run
/mnt-daten\x2dfilme\x2dnas.mount, as it already exists. Duplicate entry in /etc/fstab?

Dieser habe ich aber keine weitere Bedeutung beigemessen, weil ich daraufhin einen der Einträge auskommentiert habe. Der Systemstart gelang aber auch dann nicht. Weiter hat ja auch sysvinit, openSuse und Debian Wheezy kein Problem damit.

Hier jetzt das Ergebnis des smartctl Langzeittests :

Code: Alles auswählen

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1146
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       509
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       3
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   075   062   000    Old_age   Always       -       25
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   099   099   000    Old_age   Always       -       55
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       208
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       1731551388

SMART Error Log Version: 1
No Errors Logged

Hierzu habe ich jedoch eine Frage. Ich habe als root ausgeführt :

Code: Alles auswählen

smartctl -t long /dev/sda

und nach 80 Minuten :

Code: Alles auswählen

smartctl -a /dev/sda

Ich nehme an, daß dieser Befehl mir das Ergebnis des Langzeittests zeigt. Zumindest finde ich auf Anhieb keinen Hinweis in der manpage auf eine eventuell vorhandene Logdatei als Testresultat.

Gruss H.

[rendegast]

smart dieser Platte ist unauffällig.
Ist sie denn am "richtigen" ata?

Code: Alles auswählen

dmesg -T | egrep "ata|sd" -C1

(Im Hinterkopf, ich vermute, daß sich obige ata-Fehler nicht im smart zeigen.)

[halo44]

... Ist sie denn am "richtigen" ata?

Code: Alles auswählen

dmesg -T | egrep "ata|sd" -C1

...

Die Ausgabe des dmesg beim Fehlstart kann ich Dir nicht zeigen, weil das System (wie erwähnt) nicht hochkommt.

Bei Start mit sysvinit zeigt sich keine Unauffälligkeit. Das System kommt schließlich auch hoch, also sollte sie am "richtigen" ata sein.

Sollte ich Dich nicht richtig verstanden haben, zeige ich Dir gerne auch noch das Ergebnis des dmesg (allerdings vom startenden sysvinit). Erstmal schenke ich mir das, weil es auch recht umfangreich ist.

Gruss H.

[NAB]

Erst mal solltest du klären, was "ata1" überhaupt ist:

[halo44]

Erst mal solltest du klären, was "ata1" überhaupt ist:

Beantworte ich gerne: ata1 ist die erwähnte SSD, also /dev/sda.

Aber eigentlich scheint sich systemd ja irgendwie an der home-Partion (natürlich auf der ata1) zu "verschlucken", wie weiter oben (heute morgen 10.20 Uhr) gepostet :

... Dependency failed for /home

Gruss H.

[halo44]

Da mein Debian 8 beim Start mit systemd ja offensichtlich ein Problem mit der Homepartition hat, habe ich heute morgen folgendes versucht :

Ich habe eine neue Partition für home angelegt, dann aus openSuse heraus die Problempartition mittels tar dorthin kopiert.

Danach habe ich Debian 8 über systemd sauber starten können, das System aber gleich wieder runter gefahren und nochmals gestartet. Prompt traten (fast) die gleichen Fehler wie mit der "alten" home-Partition auf. Das System brachte 5 mal die ata1-Fehler im Abstand von 15 Sekunden und landete dann im emergency mode.

Nun habe ich einen dritten Start unternommen. Es folgten diesmal 2 ata1-Fehler und nun zusätzlich noch 2 running-start-jobs für jeweils 1 Minute und 30 Sekunden, bevor wieder der emergency mode erreicht wurde.

Beim Sichten des Journals mit journalctl -xb erfuhr ich, daß die Probleme die neue home-Partition und offensichtlich nun auch die swap-Partition betraffen.

Ich beabsichtige nun meine Systemsicherung von Wheezy (mit installiertem nvidia-legacy-Treiber) zurückzuladen und den Upgrade auf Jessie zu wiederholen. Sollten hiernach die gleichen Fehler auftreten, werde ich noch weiter zurückgehen und die Wheezy-Sicherung vor dem legacy-Treiber laden, diesen dann erneut installieren und folgend wieder den Upgrade auf Jessie fahren.

Ob ich beim Wiederauftreten der Fehler aufgebe (d.h. bei Wheezy bleiben) oder statt des Upgrades eine Neuinstallation in Angriff nehmen werde, möchte ich erst später entscheiden.

Gruss H.

[NAB]

ata1 ist die erwähnte SSD, also /dev/sda.

Mist ... ich hatte gehofft, dass das ein zickiger USB-Stick oder ein optisches Laufwerk ist.

Gibt es ein Firmware-Update für die SSD? Sonst schau mal, ob du sie an einen anderen Port anschließen kannst.

So richtig klar ist mir nicht, woran es bei dir hakt, aber die ata1-Meldungen sind bisher das einzige handfeste, was wir haben.

Und ansonsten ... lohnt der ganze Aufwand, wenn es mit Sysvinit problemlos läuft? Sooo toll ist systemd nun auch nicht ...

[catdog2]

Und ansonsten ... lohnt der ganze Aufwand, wenn es mit Sysvinit problemlos läuft? Sooo toll ist systemd nun auch nicht ...

Nur weil man das Problem dann nicht sieht heisst das noch lange nicht, dass es nicht da ist. Sieht ja eher nach einen Hardware oder Kernel Problem aus.

//edit: eventuell mal die ganzen Energiespardinger ausschalten, also hdparm -B 255 /dev/sda (hat hier mal geholfen bei einer SSD mit SATA Fehlen, allerdings keine Samsung) und das SATA Link Power Management.

[halo44]

... Gibt es ein Firmware-Update für die SSD? Sonst schau mal, ob du sie an einen anderen Port anschließen kannst.

So richtig klar ist mir nicht, woran es bei dir hakt, aber die ata1-Meldungen sind bisher das einzige handfeste, was wir haben.

Und ansonsten ... lohnt der ganze Aufwand, wenn es mit Sysvinit problemlos läuft? Sooo toll ist systemd nun auch nicht ...

Kürzlich erschien wohl eine neue Firmware (EXT0DB6Q) für die SSD. Allerdings finden sich im Netz Hinweise auf Bugs in dieser Version, u.a. hier : https://bugzilla.redhat.com/show_bug.cgi?id=1218662.

Den Versuch mit einem anderen Port werde ich heute abend mal angehen.

Systemd wäre mir nur deswegen lieber, weil sowohl mein Notebook als auch meine openSuse-Distribution schon damit laufen.

... eventuell mal die ganzen Energiespardinger ausschalten, also hdparm -B 255 /dev/sda ... und das SATA Link Power Management.

Meine SSD meint zu hdparm "APM_level = not supported". Für die zweite Platte (ehemalige Notebookplatte) erfahre ich "APM_level = 254", also kein Energiesparbetrieb(?). Das SATA Link Power Management steht auf "max performance".

Gruss H.

[NAB]

Systemd wäre mir nur deswegen lieber, weil sowohl mein Notebook als auch meine openSuse-Distribution schon damit laufen.

Versteh ich ... ich hab's auch gerne einheitlich ...

OpenSuse läuft auf dem selben Rechner? Dann ist der ja schon mal nicht generell allergisch gegen Systemd. Läuft OpenSuse auch von der selben SSD?

Du könntest mal eine Jessie-Testinstallation auf einem USB-Stick oder einer alten HDD machen ... einfach um zu testen, ob die ata1-Meldungen überhaupt was mit dem Streik von Systemd zu tun haben - da bin ich mir nämlich absolut nicht sicher.

Hast du eigentlich mal die Ausgabe von "dmesg" durchgeschaut (unter sysvinit)? Eventuell hakt's ganz woanders und Sysvinit kaschiert das eleganter (oder wartet die nötigen paar Milisekunden länger).

[halo44]

... OpenSuse läuft auf dem selben Rechner? Dann ist der ja schon mal nicht generell allergisch gegen Systemd. Läuft OpenSuse auch von der selben SSD?

Ja, auf dem selben Rechner und auch von der selben SSD.

... Du könntest mal eine Jessie-Testinstallation auf einem USB-Stick oder einer alten HDD machen ... einfach um zu testen, ob die ata1-Meldungen überhaupt was mit dem Streik von Systemd zu tun haben - da bin ich mir nämlich absolut nicht sicher.

Das wäre dann ja in jedem Fall eine Neuinstallation und kein Upgrade wie bei meinem Problem. Auf meinem Notebook läuft Jessie ja als Neuinstallation sogar auf einer SSD gleichen Typs und gleicher Grösse problemlos.

... Hast du eigentlich mal die Ausgabe von "dmesg" durchgeschaut (unter sysvinit)? Eventuell hakt's ganz woanders und Sysvinit kaschiert das eleganter (oder wartet die nötigen paar Milisekunden länger).

Hier auszugsweise alle Meldungen von "dmesg" zu ata1 bei sysvinit :

Code: Alles auswählen

[    0.578756] ata1: SATA max UDMA/133 abar m8192@0xfe224000 port 0xfe224100 irq 11

[    0.896041] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[    0.897893] ata1.00: supports DRM functions and may not be fully accessible
[    0.897933] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[    0.897937] ata1.00: ATA-9: Samsung SSD 840 EVO 250GB, EXT0CB6Q, max UDMA/133
[    0.897941] ata1.00: 488397168 sectors, multi 1: LBA48 NCQ (depth 31/32)
[    0.898128] ata1.00: supports DRM functions and may not be fully accessible
[    0.898166] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[    0.898172] ata1.00: configured for UDMA/133
[    0.898353] scsi 0:0:0:0: Direct-Access     ATA      Samsung SSD 840  CB6Q PQ: 0 ANSI: 5

[   17.828080] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[   17.828119] ata1.00: failed command: SET FEATURES
[   17.828151] ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 2
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)                                                            
[   17.828192] ata1.00: status: { DRDY }
[   17.828223] ata1: hard resetting link
[   18.148066] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   18.149996] ata1.00: supports DRM functions and may not be fully accessible
[   18.150063] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[   18.150312] ata1.00: supports DRM functions and may not be fully accessible
[   18.150380] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[   18.150386] ata1.00: configured for UDMA/133
[   18.150410] ata1: EH complete

Interessant ist in diesem Zusammenhang, daß obiger Fehlerblock (Sekunden 17/18) bei sysvinit nur einmal erscheint (und der Rechner dann weiter hochfährt), während bei den Versuchen mit systemd die Fehler immer um etwa 5 mal im Abstand von 15 Sekunden auftreten bevor der Start scheitert. Bei den zwei erfolgreich verlaufenen Starts von systemd wurden meiner Erinnerung nach nur jeweils 2 Fehlerblocks ausgegeben. Insofern liegst Du mit Deiner Vermutung hinsichtlich Zeitproblem vielleicht richtig.

Gruss H.

[NAB]

Das wäre dann ja in jedem Fall eine Neuinstallation und kein Upgrade wie bei meinem Problem. Auf meinem Notebook läuft Jessie ja als Neuinstallation sogar auf einer SSD gleichen Typs und gleicher Grösse problemlos.

Also ich vermute ein schlechtes Zusammenspiel von Kernel, Mainboard und SSD als Ursache des Problems. Und du meinst, die Ursache liegt im Dist-Upgrade? Naja ... "wissen" tu ich es auch nicht ...

Wenn du nach dieser Zeile googelst

Code: Alles auswählen

[    0.897933] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1

findest du eine ganze Menge Treffer, die auf eine neue Firmware für die SSD hinauslaufen. Z.B. diesen hier:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1338706
Da wird ein Zusammenhang zum Trim-Befehl gesehen.

Da fehlt aber die bei dir folgende Exception ... aber der Bugreport stammt auch von einem älteren Kernel.

Schau doch mal, was der Suse-Kernel zu "NCQ" sagt. Und ob du irgendwelche Hinweise findest zu Kernel 3.16, deinem Mainboard und NCQ.

[halo44]

... Also ich vermute ein schlechtes Zusammenspiel von Kernel, Mainboard und SSD als Ursache des Problems ...

So wirds wohl sein, um nicht zu sagen Volltreffer! Wenn ich nämlich mit dem Kernel 3.2.0-4-amd64 boote, bekomme ich keine Fehler und das System fährt sauber als Jessie mit systemd hoch.

Den Versuch mit anderem Sata-Port habe ich vorher ohne Erfolg versucht. Auch die Entfernung des "discard" in der /etc/fstab brachte keine Änderung.

Ich tendiere im Moment dazu zunächst beim "alten" Kernel zu bleiben. Ich muß das Ganze erstmal auf mich wirken lassen.

Ich bedanke mich herzlich bei allen Helfern.

Gruss H.

P.S. Habt Ihr einen Vorschlag, wie ich den Thread markieren soll? "Gelöst" scheint mir übertrieben.