Sie sind nicht angemeldet.

Anzeigen

**Wir werden in den kommenden Tagen einen Umzug auf einen neuen Server durchführen. Im Rahmen dieser Maßnahme wird das Forum ca. 1 Stunde nicht erreichbar sein.** nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

Lieber Besucher, herzlich willkommen bei: Die NSLU2 Community****wenns ums speichern und streamen geht****. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Samstag, 15. Juli 2006, 12:49

Lösung des "Kopierproblems" mit OpenSlug 3.1

Hi Leute,
wie bei einigen anderen von Euch ist meine NSLU mit allen Firmware-Versionen bei Kopierprozessen, die eine hohe/längere Disk-Auslastung zur Folge hatten, "stehen geblieben".

"Stehen geblieben" ist hier bewußt gewählt denn sie ist grundsätzlich nicht immer abgestürzt, wenn man mehrere Minuten gewartet hat (teilweise auch bis zu einer halben Stunde) und ein zweites Shell-Fenster offen HATTE, sprach sie wieder mit einem - jedoch nicht immer bzw. ich hatte nicht immer den Nerv, so lange zu warten!

So, ganz kurz DIE WESENTLICHEN DINGE umrissen wie ich vorgegangen bin und was letztendlich bei MIR zur einer Lösung des Problems geführt hat:

- sämtliche Firmwares ausprobiert, kein Unterschied. Habe mich letztendlich für OpenSlug entschieden, da es hierfür "mehr" vorkompilierte Debian-Pakete gibt

- Im Logfile /var/log/messages fand ist stets beim Auftreten des Problems den Hinweis, dass das SCSI-Device, auf das kopiert wurde, nicht mehr verfügbar ist. Anschließend wurden alles USB-Devices vom OS neu initiiert (was wie gesagt auch mal bis zu einer halben Stunde dauern konnte). Das war unabhängig davon, ob der Kopierprozess via LAN oder lokal per SSH eingeleitet wurde.

- Gut, den USB-Treiber für die Devices als mögliches Problem ansehend fand ich einen Hinweis, dass jemand sein Problem damit beheben konnte, dass er seine Festplatten neu formatiert hat (und vorher den gleichen Eintrag im Logfile hatte)

- Fein, checken wir also mal unser File-System der angeschlossenen Festplatten (indem wir erst das Device unmounten und dann e2fsck rüber jagen). Resultat: e2fsck -yf <device> lief nicht durch, stieg in Stage 5 mit einer "nichts sagenden" Fehlermeldung aus (nachdem es vorher allerdings diverse Dinge schon behoben hatte).

- Googlen brachte, das dies ein Problem von e2fsck in der 1.38er-Version (Original auf OpenSlug 3.1) ist. Also habe ich mir die 1.39er-Version besorgt und auf der Slug kompiliert, Vorgang wiederholt und es lief ohne Probleme durch. Jetzt gab es zwar keine "File System"-Probleme mehr auf meinen Laufwerken, das Problem war aber immer noch da :(

- Ok, udev ist primär für die Einbindung von USB-Laufwerken in OpenSlug verantwortlich (zusammen mit diversen anderen Dingen, aber eines nach dem anderen). Version 0.89 ist bei OpenSlug dabei, 0.96 ist mittlerweile die aktuellste Version. Da das Kompilieren von udev alles andere als "trivial" ist machte ich erst gar nicht den Versuch es selbst zu kompilieren sondern nutzte ein kompiliertes Debian-Package der Version 0.93 (sowie zwei dafür notwendige Libraries). Alle Konfigurationsdatein und Startup-Scripte von OpenSlug habe ich unverändert gelassen (also das komplette /etc-Verzeichnis), alle anderen Komponenten des Programms (libs, sbin, usr) nach einem Backup der Originaldateien jedoch durch die neue Version ersetzt und udev neu gestartet.

!!! ERFOLG !!!

Bisher habe ich AM STÜCK mehr als 600GB zwischen vier USB-HDDs kopiert, getarrt und was nicht sonst noch alles, die NSLU läuft wie eine Uhrwerk :) Vorher bereits mehrere Reboots, keine Probleme. Auch "scheint" die Datenübertragung deutlich (!!!) schneller zu sein über den USB-Bus - was ich jedoch nicht belegen kann, es ist nur ein (sehr deutliches) subjektives Empfinden.


Das war die Vorgehensweise, jetzt ein paar Hinweise, wo Ihr vorkompilierte Debian-Pakete für BigEndian (armeb) findet und wie Ihr diese Lösung hier (auf eigene Gefahr! Legt Euch Backups an!) bei Euch unkompliziert umsetzen könnt:

- Vorkompilierte Debian-Pakete für OpenSlug 3.1 findet Ihr hier:
http://armeb.debian.net/debian-armeb/pool/main/
Diese müßt Ihr dann mit dpkg oder ZipZag (Windows) entpacken. Euch interessiert nur das data.tar.gz, da sind die Binaries drin

- Die kompilierten e2fsprogs 1.39 hänge ich für OpenSlug 3.1 an diesen Beitrag an. Falls Ihr sie verwenden möchtet ersetzt einfach die originalen Versionen mit den Binaries in diesem Archiv.

- Das udev 0.93-Paket, wie es bei mir läuft (mit den notwendigen Libraries) hänge ich ebenfalls an. Um udev "updaten" zu können müßt Ihr wie folgt vorgehen:

1. tar auf die Slug kopieren und entpacken (tar -xzf udev-093_with_libs_armeb.tar.gz)
2. udev stoppen (/etc/init.d/udev stop)
3. ALTE DATEN SICHERN!
4. Neue Daten kopieren (mv -f udev-093_with_libs/* /)
5. Libraries dem System bekannt machen (ldconfig)
6. neues udev starten (/etc/init.d/udev start)
7. SOLLTE DER START FEHL SCHLAGEN, DIE SLUG NICHT NEU STARTEN! Dann müßt Ihr das Backup einspielen und testen, ob udev startet. Neustart ohne funktionstüchtiges udev wird nicht funktionieren!


Letztendlich kann ich nicht sagen, ob es NUR an udev gelegen hat oder auch das Filesystem mit dafür verantwortlich gewesen ist. So war mein Vorgehen, das bei mir zum Erfolg geführt hat.
Ich hänge auch die originalen (kompletten) udev-Daten von OpenSlug 3.1 mit an falls jemand vergessen haben sollte alles zu sichern und nach dem Update Probleme damit hat.

Abschließend noch einmal der Hinweis: so hat es bei mir funktioniert auf einer 266er NSLU2, an der ein USB-Stick an Port2 als Root-Partition läuft und via HUP an Port 1 vier EXT3-HDDs hängen. Nachahmung auf eigene Gefahr!

Hoffe der eine oder andere von Euch findet diese Hinweise nützlich.

Bye Alex
»alexatunix« hat folgende Dateien angehängt:

Anzeigen

Social Bookmarks