Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] dd-Kommando hängt  (Read 3767 times)

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
[DE] dd-Kommando hängt
« on: 2011/05/04, 15:24:05 »
Hallo zusammen,
ich habe mit einen LENOVO T60 z.Zt. ein Problem beim Schreiben großer Dateien (vermute ich) auf ein NAS das per NFS gemountet ist. Das Problem liegt vermutlich am Kernel oder systemnahen Paketen die upgedatet wurden.

Die Situation stellt sich folgendermaßen dar. Wenn ich eine Sicherung einer LVM-Partition mit dem dd-Kommando auf das NAS-Laufwerk schreibe hängt seit einigen Tagen das Shellscript. Die CPU-Last steigt durch das dd-Kommando auf 100% und es wird nicht mehr weiter geschrieben. Nach einer Rücksicherung (Stand 22.04.2011) des System läuft alles wieder korrekt. Nach der Rücksicherung habe ich den Kernel 2.6.38-3.slh.4-aptosid-686.

Testweise habe ich, ausgehenden von diesem Stand, nur den Kernel upgedatet (auf 2.6.38-5.slh.1-aptosid-686). Es wurden nicht nur der aptosid-Kernel aktualisiert, sondern auch der gcc und paar zugehörige Komponenten (kann ich nicht mehr genau festellen). Danach trat wieder das gleiche Fehlerbild auf.

Hat jemand von euch ähnliche Probleme oder ist das ein bekanntes Problem des aktuellen Kernels?

EDIT1: Hier die Paketliste nach der Rücksicherung des Systems.

EDIT2: Hier der Output was alles bei einem d-u upgedatet würde nach der Rücksicherung des Systems. Wenn man das "schuldige" Paket eingrenzen könnte wäre das schon mal ein Anfang. Wie oben geschildert hat es sehr wahrscheinlich mit dem Kernel selbst bzw. gcc zu tun.

Offline michaaa62

  • User
  • Posts: 299
dd-Kommando hängt
« Reply #1 on: 2011/05/05, 11:07:51 »
Kann es an der Netzwerkverbindung liegen? Wlan (welcher Chip? Etwa gar Atheros-basiert?) oder Kabel? Platz ist genug auf dem NAS?

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
dd-Kommando hängt
« Reply #2 on: 2011/05/05, 14:10:58 »
Hi michaaa62,
das NAS ist via Kabel angeschlossen. Platz ist genug vorhanden. Das NAS-Filesystem (ext4) "hängt" via NFS am NB.
Code: [Select]

diskstation:/volume1/Backup_Diskimages     1,8T   425G  1,4T   24%   /mnt/diskstation/diskdump

Nach dem Rücksichern des kompletten Systems geht's auch wieder. Entweder ist der Kernel oder ein systemnahes Paket dafür verantwortlich.

Ich hab eines dieser Pakete in Verdacht, weil's danach nicht mehr funktioniert. Aber welches?
Code: [Select]

# apt-get install linux-headers-2.6.38-5.slh.1-aptosid-686 linux-image-2.6.38-5.slh.1-aptosid-686 -s
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut      
Statusinformationen werden eingelesen... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  binutils cpp-4.6 gcc-4.6 gcc-4.6-base libgcc1 libgfortran3 libgomp1 libquadmath0 libstdc++6
Vorgeschlagene Pakete:
  binutils-doc gcc-4.6-locales gcc-4.6-multilib libmudflap0-4.6-dev gcc-4.6-doc libgcc1-dbg libgomp1-dbg
  libquadmath0-dbg libmudflap0-dbg binutils-gold linux-doc-2.6.38
Die folgenden NEUEN Pakete werden installiert:
  cpp-4.6 gcc-4.6 linux-headers-2.6.38-5.slh.1-aptosid-686 linux-image-2.6.38-5.slh.1-aptosid-686
Die folgenden Pakete werden aktualisiert (Upgrade):
  binutils gcc-4.6-base libgcc1 libgfortran3 libgomp1 libquadmath0 libstdc++6
7 aktualisiert, 4 neu installiert, 0 zu entfernen und 357 nicht aktualisiert.
Inst linux-image-2.6.38-5.slh.1-aptosid-686 (2.6.38-29 Debian:unstable [i386])
Inst libgomp1 [4.6.0-3] (4.6.0-6 Debian:unstable [i386]) []
Inst gcc-4.6-base [4.6.0-3] (4.6.0-6 Debian:unstable [i386]) [libstdc++6:i386 libgfortran3:i386 libgcc1:i386 libquadmath0:i386 ]
Conf gcc-4.6-base (4.6.0-6 Debian:unstable [i386]) [libstdc++6:i386 libgfortran3:i386 libgcc1:i386 libquadmath0:i386 ]
Inst libstdc++6 [4.6.0-3] (4.6.0-6 Debian:unstable [i386]) [libgfortran3:i386 libgcc1:i386 libquadmath0:i386 ]
Conf libstdc++6 (4.6.0-6 Debian:unstable [i386]) [libgfortran3:i386 libgcc1:i386 libquadmath0:i386 ]
Inst libgfortran3 [4.6.0-3] (4.6.0-6 Debian:unstable [i386]) [libgcc1:i386 libquadmath0:i386 ]
Inst libquadmath0 [4.6.0-3] (4.6.0-6 Debian:unstable [i386]) [libgcc1:i386 ]
Inst libgcc1 [1:4.6.0-3] (1:4.6.0-6 Debian:unstable [i386])
Conf libgcc1 (1:4.6.0-6 Debian:unstable [i386])
Inst binutils [2.21.0.20110327-3] (2.21.51.20110421-3 Debian:unstable [i386])
Inst cpp-4.6 (4.6.0-6 Debian:unstable [i386])
Inst gcc-4.6 (4.6.0-6 Debian:unstable [i386])
Inst linux-headers-2.6.38-5.slh.1-aptosid-686 (2.6.38-29 Debian:unstable [i386])
Conf linux-image-2.6.38-5.slh.1-aptosid-686 (2.6.38-29 Debian:unstable [i386])
Conf libgomp1 (4.6.0-6 Debian:unstable [i386])
Conf libquadmath0 (4.6.0-6 Debian:unstable [i386])
Conf libgfortran3 (4.6.0-6 Debian:unstable [i386])
Conf binutils (2.21.51.20110421-3 Debian:unstable [i386])
Conf cpp-4.6 (4.6.0-6 Debian:unstable [i386])
Conf gcc-4.6 (4.6.0-6 Debian:unstable [i386])
Conf linux-headers-2.6.38-5.slh.1-aptosid-686 (2.6.38-29 Debian:unstable [i386])

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
dd-Kommando hängt
« Reply #3 on: 2011/05/12, 09:58:28 »
Hallo zusammen,
so nun habe ich mich mit dem Problem beschäftigt. Gestern hat ich wieder den ersten d-u nach dem gesamten Rücksichern des Notebooks erfolreich durchgeführt. Den Kernel habe ich durch das Löschen der Metapakete vom Update ausgeschlossen. Der nachfolgende Testlauf mit meinen Script das die einzelnen Partitionen per dd wegsichert lief erfolgreich durch. Danach habe den Kernel aktualisiert auf Version 2. 2.6.38-6.slh.1-aptosid-686 und einen erneuten Test  mit meinen Script durchgeführt. Mit diesen Kernel ist nun das selbe Fehlerbild wieder aufgetreten, d.h. nach einer gewissen Laufzeit bei der Ausführung des dd-Kommandos steigt die CPU-Auslastung des NB auf 100% und das Script "hängt". Es sind keinerlei Schreibaktivitäten auf der Platte mehr festzustellen.

Nun meine Frage dazu, gibt es zwischen dem Kernel 2.6.38-3.slh.4-aptosid-686 (hier läuft es ohne Probleme) und 2. 2.6.38-6.slh.1-aptosid-686 (hier tritt der Fehler auf) irgendwelche signifikanten Unterschiede die dieses Verhalten erklären könnten. Wo könnten die Ursachen liegen?

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
dd-Kommando hängt
« Reply #4 on: 2011/05/13, 12:03:05 »
Hallo zusammen,
nachdem ich bei meinem Problem nicht wirklich die Ursachen erkennen kann fällt mir nur noch zur Lösung ein den Kernel auf meinen aptosid-System gegen den neuesten Original-Debian Kernel aus SID auszutauschen (2.6.38-5).

Spricht dagegen etwas grundsätzliches oder handle ich mir ggf. neue Probleme ein?

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.838
dd-Kommando hängt
« Reply #5 on: 2011/05/13, 13:22:27 »
ich würde das problem ja mal auf .com schildern, damit $kerneldev das auch liest.

greetz
devil

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
Re: dd-Kommando hängt
« Reply #6 on: 2011/05/13, 13:57:53 »
Quote from: "devil"
ich würde das problem ja mal auf .com schildern, damit $kerneldev das auch liest.

Hi devil,
könnte ich wenn ich dort einen Account hätte und dort meine  Anwesenheit von den Verantwortlichen erwünscht wäre, das aber aus bekannten Vorfällen aus vergangenen sidux Zeiten mir nicht sinnvoll und möglich erscheint. Trotzdem Danke für deinen Vorschlag.