Linux Mint 17(.1) für Backup System geeignet?
- Ersteller SPINA
- Erstellt am
Es lag nicht an Linux Mint. Die Grafikkarte ist soeben verstorben. Also ein Hardwaredefekt war die Ursache. Eine Tastatur musste ebenfalls dran glauben. Meine alte Cherry G81-3000 zeigt Ausfallerscheinungen. Die Tasten T und Backspace haben unter anderem nicht mehr reagiert. Ich hätte es nicht für möglich gehalten, dass sie mich je im Stich lässt. Die Hauptplatine zeigt sich ebenfalls von ihrer schlechten Seite. Gestern fiel mir auf, dass die swap Partition zu einem Drittel belegt ist und das System sich zäh anfühlt. Die Ursache war, dass nur die Hälfte des Hauptspeichers erkannt wurde. Zuerst hatte ich Linux Mint im Verdacht, aber nach einem Reboot zeigte mir der POST Screen dasselbe an. Diese Klippe ließ sich jedoch ohne Austausch der Hauptplatine umschiffen.
Es war nicht besagte Radeon HD 4830, sondern eine Radeon HD 56700 aus dem Bestand. Für diese wurde mir der fglrx angeboten. Jetzt werkelt eine Radeon HD 2600 XT im PC. Der "Driver Manager" zeigt bei dieser nicht an mit welchem Treiber sie läuft. Zumindest tut sie dies unauffällig. Nach dem Einbau der nötigen Ersatzteile läuft das Linux Mint nun besser denn je. Mit meiner Peripherie kann es jedoch nicht viel anfangen, aber das wäre auch zuviel verlangt. Den Kyocera Mita FS-720 bekomme ich nicht einmal unter Windows (mangels x86-64 Treiber) zum Laufen und der CanoScan 4200F ist wie ein nicht unbeträchtlicher Teil aller Scanner eine kleine Diva. Ohne an eine Windows XP VM durchgereichte USB Ports wird sich wohl nichts machen lassen.
Das System sieht nun folgendermaßen aus und läuft soweit gut:
- Gigabyte GA-MA69G-S3H (ATi 690G/SB600)
- AMD Athlon 64 X2 4000+
- 2048MB DDR2-800 RAM
- ATi Radeon HD 2600 XT (mit 256MB)
- ASUS U3S6
- Hitachi Deskstar P7K500 (250GB)
- WD Caviar SE WD5000AAJS (500GB)
- Seagate Barracuda 7200.10 (500GB)
Erstaunlich ist, dass die U3S6 auf Anhieb ohne Murren lief. Hier hatte ich Komplikationen erwartet, aber diese blieben aus.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Ok, die Evergreen wäre noch mit dem fglrx gelaufen. Fliegt erst demnächst raus.
Das kann nur noch der OpenSource Treiber sein.
Ist ein reinder GDI-Drucker und somit unter Linux nicht wirklich zu gebrauchen:
http://www.linux-community.de/Community/Fragen/Druckertreiber-fuer-den-Kyocera-FS-720
Wird von sane nicht unterstützt, womit du mit dem wohl auch wenig Glück haben dürftest:
http://www.sane-project.org/sane-mfgs.html
http://www.sane-project.org/unsupported/canon-4200f.html
Da ist nichts Exotisches verbaut, insofern hätte ich da keine Probleme erwartet.
Ja, das war mir beim Kauf schon bewusst. Der Aufpreis für PCL/PS war jedoch zum damaligen Zeitpunkt astronomisch hoch.
Eine letzte Frage noch: Bei LUKS sollte man vermutlich auf den Einsatz von fsck verzichten, oder?
PuckPoltergeist
Grand Admiral Special
Wie kommst du darauf? Natürlich muss zuerst das block device entschlüsselt werden, aber danach wird das Dateisystem so behandelt, wie es unverschlüsselt ebenso der Fall wäre. Also da änderst du nix.
Ja, klappt wunderbar. Das sudo fsck.ext4 -cf /dev/mapper/luks-d14b54a7-da99-45a6-8390-393b64dfc105 ist gerade für die erste LUKS Partition durchgelaufen.
Obwohl ich mir den Parameter -c hätte schenken können. Ich weiß nicht, ob jede virtuelle Adresse immer demselben physikalischen Sektor zugeordnet wird.
Obwohl ich mir den Parameter -c hätte schenken können. Ich weiß nicht, ob jede virtuelle Adresse immer demselben physikalischen Sektor zugeordnet wird.
PuckPoltergeist
Grand Admiral Special
Das kommt darauf an, was du unter virtueller Adresse und physikalischem Sektor verstehst. Was die Platte macht, kann das Dateisystem natürlich nicht kontrollieren, aber jeder Dateisystemblock wird immer der selben LBA-Adresse zugeordnet. Sonst hätte das Dateisystem ja ein Problem, die Daten wiederzufinden.
Es klappt soweit ganz gut - bis auf eine Sache: Größere Datenmengen muss ich mittels USB Festplatten mit dem Linux-PC austauschen. Das Netzwerk hält keine hohe Last aus. Die Samba Freigaben sind unter Windows 7/8(.1) sichtbar und Zugriffe darauf erfolgreich. Man kann sie ohne weiteres als Netzlaufwerke einhängen. Soweit, so gut. Bloß kann man keine längeren Kopiervorgänge vornehmen. Mal reißt die Verbindung nach 16 Gigabyte ab, mal nach der doppelten bis dreifachen Menge. Es scheint jedoch nicht an Samba zu liegen, denn der Linux-PC ist dann überhaupt nicht mehr ansprechbar. Er reagiert nicht auf Pings und wenn man an ihm den Firefox aufruft, lässt sich keine Website laden. Er koppelt sich komplett vom Netzwerk ab. Erst ein Neustart beseitigt diesen Umstand. An dem Netzwerkchip von Realtek scheint es nicht zu liegen. Bootet man von einer CompactFlash Card ein Windows Vista kann man dort Terabytes an Daten verschieben ohne Abriß der Verbindung. Kennt jemand dieses Verhalten von Linux Mint 17.1?
Ich wünsche noch einen angenehmen Sonntag...
Ich wünsche noch einen angenehmen Sonntag...
Dalai
Grand Admiral Special
Wenn das System selbst noch lebt, dann drängt es sich geradezu auf, mal in die Logs zu schauen. Vor allem /var/log/syslog, aber auch die anderen im selben Verzeichnis könnten Aufschluss geben.
MfG Dalai
MfG Dalai
Es lässt sich bis auf die Netzwerkfunktionen noch vollständig ansprechen; so als wäre nichts gewesen.
Gut zu wissen. Da Linux gefühlt ausschließlich aus Log Dateien besteht, wusste ich nicht, wo man den Anfang macht.
Das Netzwerkproblem ist zwar nicht gelöst, aber ich kenne nun die Ursache. Ich überlaste mit überlangen SMB Transfers den Router und dieser macht daraufhin dicht. Dabei beschränkt sich die Blockade auf eine einzige IP Adresse. Ansonsten reagiert der Router wie gewohnt.
Dergestalt sieht die LAN-Topologie zur Zeit aus: Linux PC <-----> Switch <-----> Router <-----> Switch <-----> Windows PC
Überbrücke ich den mittleren Teil, gibt es kein Abreißen der Verbindung mehr. Zuvor habe ich von einem solch ungewöhnlichen Verhalten eines Routers noch nie gehört. Auf die Frage, warum jedes Mal der Linux PC vom Router abgekapselt wird und nicht der beteiligte Windows PC, weiß ich keine Antwort. Dieses Phänomen konnte bisher unentdeckt bleiben, weil sich größere Dateitransfers im Regelfall ohne Zutun des Routers abspielen. Das Netzwerkproblem liegt demnach nicht an Linux Mint, sondern meinem Pfusch. Das Netzwerk ist in den letzten Monaten und Jahren einfach zu stark angewachsen für SoHo Hardware. Infolge dessen scheint (selbst verschuldet) der Wurm drin zu sein. Es wird Zeit für eine Entschlackungskur des Netzwerkes.
Mit Ruhm habe ich mich bei diesem Projekt wirklich nicht bekleckert...
Dergestalt sieht die LAN-Topologie zur Zeit aus: Linux PC <-----> Switch <-----> Router <-----> Switch <-----> Windows PC
Überbrücke ich den mittleren Teil, gibt es kein Abreißen der Verbindung mehr. Zuvor habe ich von einem solch ungewöhnlichen Verhalten eines Routers noch nie gehört. Auf die Frage, warum jedes Mal der Linux PC vom Router abgekapselt wird und nicht der beteiligte Windows PC, weiß ich keine Antwort. Dieses Phänomen konnte bisher unentdeckt bleiben, weil sich größere Dateitransfers im Regelfall ohne Zutun des Routers abspielen. Das Netzwerkproblem liegt demnach nicht an Linux Mint, sondern meinem Pfusch. Das Netzwerk ist in den letzten Monaten und Jahren einfach zu stark angewachsen für SoHo Hardware. Infolge dessen scheint (selbst verschuldet) der Wurm drin zu sein. Es wird Zeit für eine Entschlackungskur des Netzwerkes.
Mit Ruhm habe ich mich bei diesem Projekt wirklich nicht bekleckert...
Zuletzt bearbeitet:
Dalai
Grand Admiral Special
Kann vielleicht der Router nicht (ordentlich) mit Jumbo Frames umgehen? Könnte sein, dass SMB2/SMB3 verstärkt darauf setzt (keine Ahnung), so dass es früher nie auffiel.
MfG Dalai
MfG Dalai
Da bin ich überfragt. Sind Jumbo Frames eigentlich irgendwo per default aktiviert? Manuell habe ich sie nicht erlaubt.
