SATA.Festplatte lässt beim mounten System einfrieren

V-Treiber · 3. September 2026

Code

thosto@localhost:~> sudo smartctl --all /dev/sdb
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-6.4.0-150600.23.103-default] (SUSE RPM)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital AV-GP
Device Model:     WDC WD5000AVDS-63U7B1
Serial Number:    WD-WCAV9CZ46473
LU WWN Device Id: 5 0014ee 25e01dd7c
Firmware Version: 01.00A01
User Capacity:    500.107.862.016 bytes [500 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database 7.5/5894
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Thu Sep  3 16:18:42 2026 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Status command failed: Die Wartezeit für die Verbindung ist abgelaufen
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

Alles anzeigen

Dachstein · 3. September 2026

Ja OK, die Platte wird noch gefunden. Ich meinte aber welche S.M.A.R.T. Werte von dieser Platte angezeigt werden ?

EDIT : OK. Hat sich gerade mit Deinem letzten Post überschnitten.

Da ist doch offenbar ein Fehler zu sehen :

Code

SMART Status command failed

V-Treiber · 3. September 2026

Ja klar. Das ein Time-Out auftreten könnte, das war schon nach der GParted-Aktion zu erwarten.

Aber all das erklärt nicht, warum das System ohne Fehlermeldung komplett einfriert, wenn man versucht die Platte zu mounten. Ob jetzt per auto-mount oder manuell im Terminal.

Dachstein · 3. September 2026

Zitat von V-Treiber

Aber all das erklärt nicht, warum das System ohne Fehlermeldung komplett einfriert, wenn man versucht die Platte zu mounten. Ob jetzt per auto-mount oder manuell im Terminal.

Du meinst Leap 16.0 und der Linux Kernel sei ohne Bugs und sei so robust dass er auf jedes x-beliebige Fehlverhalten der Hardware eine passende Antwort hätte ?

Ich bleibe erstmal dabei : Deine Platte hat irgend einen Schuss weg ...

Sauerland · 3. September 2026

Lass doch mal top mitlaufen, wenn du die Platte versuchst zu mountest...

top im größeren Fenster, mount im kleineren sodass du etwas siehst.

Evtl. ist das System ja ausgelastet.

V-Treiber · 3. September 2026

Sauerland

Ich wüsste zwar nicht mit was das System (4 Kerne, 32GB RAM, xfce, 1 Firefox, 1 Terminal) ausgelastet sein sollte...

aber

dmesg liefert nach dem Mount-versuch Folgendes (wenigstens kein Absturz dies Mal)

Code

Do,  3. Sep 2026, 17:00:56] [   T5810] EXT4-fs (sdb): VFS: Can't find ext4 filesystem
[Do,  3. Sep 2026, 17:00:56] [   T5810] EXT4-fs (sdb): VFS: Can't find ext4 filesystem
[Do,  3. Sep 2026, 17:00:56] [   T5810] EXT4-fs (sdb): VFS: Can't find ext4 filesystem
[Do,  3. Sep 2026, 17:00:56] [   T5810] FAT-fs (sdb): bogus number of reserved sectors
[Do,  3. Sep 2026, 17:00:56] [   T5810] FAT-fs (sdb): Can't find a valid FAT filesystem

Wie gesagt auf der Platte ist ein brfs und ein xfs?

Und in top ist auch nichts los.

Code

 1597 root      20   0 1549028 181256 114608 S 4,313 0,562   1:05.54 Xorg.bin                                                                                                               
   1999 thosto    20   0 3825180 759416 279872 S 4,313 2,355   5:17.92 firefox                                                                                                                
   2848 thosto    20   0 3011172 434012 138032 S 2,986 1,346   2:10.98 Isolated Web Co                                                                                                        
   2003 thosto    20   0  447004  52412  40400 S 0,663 0,163   0:05.41 xfce4-terminal                                                                                                         
      8 root       0 -20       0      0      0 I 0,332 0,000   0:02.31 kworker/0:0H-acpi_thermal_pm                                                                                           
    830 root      20   0   38956  12800   8448 S 0,332 0,040   0:00.16 systemd-udevd                                                                                                          
   1890 thosto    20   0 1371576 123584  94080 S 0,332 0,383   0:23.75 xfwm4                                                                                                                  
   5082 root      20   0       0      0      0 I 0,332 0,000   0:01.80 kworker/6:0-events                                                                                                     
   5140 root      20   0       0      0      0 I 0,332 0,000   0:01.47 kworker/3:0-events                                                                                                     
   5566 root      20   0       0      0      0 I 0,332 0,000   0:00.34 kworker/4:3-events                                                                                                     
   5646 thosto    20   0   10728   6016   3712 R 0,332 0,019   0:02.74 top                                                                                                                    
      1 root      20   0   24756  15952  11504 S 0,000 0,049   0:01.49 systemd

Alles anzeigen

Sauerland · 3. September 2026

Bohre Löcher in die Platte und gib sie ab......

V-Treiber · 3. September 2026

Zitat von Sauerland

Bohre Löcher in die Platte und gib sie ab......

Ja, und mit dem Windowsverhalten muss ich dann wohl leben.

luigi · 3. September 2026

Zitat von Dachstein

Standardmäßig bleiben die letzten drei Kernel auf dem System drauf. Wenn er also von Leap 15.6 erst vor Kurzem das Update auf 16.0 gemacht hat kann es durchaus
sein dass dieser Kernel noch da ist. Hatte ich auch nach meinem Update for einem Monat.

Bei mir wurden die 15.6 Kernels nach einem komplett erfolgreichen upgrade auf Leap 16.0 immer automatisch gelöscht.

Daher stellt sich mir die Frage, ob sich das System überhaupt in einem geordneten Leap 16.0 Zustand befindet. Wenn nicht, dann ist auch nicht auszuschließen, dass das seltsame Verhalten beim Zugriff auf die Festplatte damit zusammenhängen könnte.

Egal, ich würde jedenfalls keinen 15.6 Kernel unter Leap 16.0 laufen lassen.

V-Treiber · 3. September 2026

Zitat von luigi

Bei mir wurden die 15.6 Kernels nach einem komplett erfolgreichen upgrade auf Leap 16.0 immer automatisch gelöscht.
Daher stellt sich mir die Frage, ob sich das System überhaupt in einem geordneten Leap 16.0 Zustand befindet. Wenn nicht, dann ist auch nicht auszuschließen, dass das seltsame Verhalten beim Zugriff auf die Festplatte damit zusammenhängen könnte.

Egal, ich würde jedenfalls keinen 15.6 Kernel unter Leap 16.0 laufen lassen.

Ich sage nur AMD/Raedon, den 6.12 muss ich noch umkonfigurieren, damit er den Treiber amdgbu rechtzeitig lädt.

Da das System sowohl mit meinen internen SSD als auch mit meinen ext. USB HDD wunderbar klar kommt, inkl. neu Partitionierung und fs-Wechsel erscheint es mir ziemlich unwahrscheinlich das es nun ausgerechnet bei einer Platte aussteigt, die in einem 15.3 Rechner lief.

SATA.Festplatte lässt beim mounten System einfrieren

First Adobe, Now Autodesk? SolidCraft Wants to Replace Fusion

Tumbleweed-Update bricht ab

GNOME OS Preview: Ein Schritt in Richtung Alltagsbetrieb

Ubuntu 26.10 „Stonking Stingray“ ist erschienen

KDE Plasma 6.8 verabschiedet sich von X11

pit1958ffm

Wanderratte

k.113

aitexturegenerator

Giorgio68

Teilen

Tags