ungelesen.net - Blog

Vor ein paar Tagen hat einer meiner Notebook-Akkus das Zeitliche gesegnet und mein Ubuntu-Notebook ist einfach ausgegangen. Kein Problem – Ladekabel ran und wieder hochfahren. Doch das Notebook wollte nicht mehr booten. Der Startbildschirm wurde angezeigt, doch mehr passierte nicht.

Die Notfallkonsole war noch erreichbar, und dort waren im Syslog viele Einträge der folgenden Art zu sehen:

[702.030145] ata3.00: exception Emask 0x0 SAct 0x1220000 SErr 0x0 action 0x0
[702.030153] ata3.00: irq_stat 0x40000008
[702.030159] ata3.00: failed command: READ FPDMA QUEUED
[702.030169] ata3.00: cmd 60/08:c0:40:29:2d/00:00:15:00:00/40 tag 24 ncq 4096 in
[702.030169]          res 41/40:00:40:29:2d/00:00:15:00:00/40 Emask 0x409 (media error)
[702.030174] ata3.00: status: { DRDY ERR }[702.030178] ata3.00: error: { UNC }
[702.042744] ata3.00: configured for UDMA/133
[702.042772] sd 2:0:0:0: [sda] tag#24 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[702.042779] sd 2:0:0:0: [sda] tag#24 Sense Key : Medium Error [current] [descriptor] 
[702.042785] sd 2:0:0:0: [sda] tag#24 Add. Sense: Unrecovered read error - auto reallocate failed
[702.042797] sd 2:0:0:0: [sda] tag#24 CDB: Read(10) 28 00 15 2d 29 40 00 00 08 00
[702.042800] blk_update_request: I/O error, dev sda, sector 355281216
[702.042812] BTRFS error (device dm-2): bdev /dev/mapper/xubuntu1604-root errs: wr 0, rd 68, flush 0, corrupt 0, gen 0
[702.042825] ata3: EH complete

Offenbar hatte die Festplatte einen Schaden davongetragen. Bei genauerem Betrachten der Meldungen fiel mir aber auf, dass es immer der gleiche Sektor war, der in den Fehlermeldungen auftauchte. So ein einzelner Sektor sollte sich doch reparieren lassen.

Als nächstes habe ich das Notebook von einer Live-DVD gebootet, um mir das Ganze genauer anzusehen. Ein Blick in den S.M.A.R.T.-Status der Festplatte mittels

sudo smartctl -H /dev/sda

lieferte PASSED. Ein Ausfall der Festplatte war also in nächster Zeit nicht unbedingt zu erwarten. Allerdings war ich damit der Fehlerursache noch nicht näher gekommen.

Also habe ich die Festplatte einfach mal gemountet und versucht, auf die Daten zuzugreifen. Das hat auch problemlos funktioniert. Falls es sich tatsächlich nur um einen Sektor der Festplatte handeln sollte, würde man das ja auch so erwarten.

Mein nächster Versuch war: Unmount und dann

btrfs check --repair /dev/mapper/xubuntu1604-root

(Diesmal nicht /dev/sda, weil es eine verschlüsselte LVM-Partition ist). Ich hatte vermutet, dass dieser Befehl mit Hilfe des Dateisystem-Journals das Problem beseitigen würde. Doch die Prüfung dauerte nicht lange und es wurde auch keine Reparatur ausgeführt. Sicherheitshalber doch noch ein Bootversuch – das Problem bestand weiterhin.

Weiter ging es mit folgendem Befehl (diesmal mit gemounteter Partition):

find /media/xubuntu/xubuntu1604-root -type f -exec cat '{}' > /dev/null \;

Dieser Befehl liest nacheinander alle Dateien der Festplatte. Falls es da irgendwo einen Fehler geben sollte, müsste nun eine Fehlermeldung erscheinen. Und tatsächlich:

$> find /media/xubuntu/xubuntu1604-root -type f -exec cat '{}' > /dev/null \;
cat: /media/xubuntu/xubuntu1604-root/@/bin/loadkeys: Eingabe-/Ausgabefehler
$>

Nur eine defektet Datei, ohne die aber ein normaler Bootvorgang offenbar nicht möglich ist. Nun war die Reparatur recht simpel: Ich habe das entsprechende deb-Paket runtergeladen (kbd_1.15.5-1ubuntu5_amd64.deb), die Datei entpackt, Größe und Datum von alter und neuer Datei verglichen (stimmten überein), die alte Datei gelöscht und die neue Datei nach /bin kopiert. Anschließend hab ich es noch mal mit einem Neustart probiert und siehe da – das Notebook bootete wieder ganz normal.

Neulich habe ich ja schon ein wenig über unsere Photovoltaikanlage geschrieben. Heute kommt nun gewissermaßen Photovoltaik Teil 2.

Seit Mitte 2012 befindet sich auf unserem Hausdach eine Photovoltaikanlage. Die Vergütungen für Stromerzeugung und Einspeisung ins öffentliche Netz sind dabei preislich so gestaltet, dass ein sofortiger Verbrauch des produzierten Stromes im eigenen Haushalt besonders lohnenswert ist. Energiehungrige Geräte sollten also bevorzugt an sonnigen Tagen zur Mittagszeit laufen. Bei einigen Geräten wie einem Kühlschrank ist das nur schlecht machbar, bei anderen wie der Waschmaschine funktioniert es mit einem Blick auf die Wettervorhersage und ein bisschen Planung sehr gut.

Irgendwann kam die Idee auf, das Schalten der Geräte zu automatisieren, um auf Lastschwankungen der elektrischen Geräte und auf über den Himmel ziehende Wolken reagieren zu können. Als Kandidat für diese Steuerung bot sich der Nachtspeicherofen im ausgebauten Obergeschoss des Schuppens an. So ein Ofen kann kurzfristig je nach Bedarf geschalten werden, bei viel Sonne mehrere kWh Energie aufnehmen und kommt bei Regenwetter auch mal einen Tag ohne Strom aus. Da er drei getrennte Heizkreise für den Betrieb am Drehstromnetz hat, kann er zudem mit reduzierter Leistung betrieben werden.

››› weiter lesen

Heute habe ich mich aus meiner Gnublin-Bastelplatine ausgesperrt. Ich hatte die Wlan-Konfiguration kaputtgemacht, so dass ich mich nicht mehr per SSH einloggen konnte. Also Notfallvariante – USB-Kabel anstecken und den Fehler per serieller Konsole beheben. Nun stand ich aber vor dem Problem, dass ich das root-Passwort vergessen hatte. Normalerweise brauch ich das nicht, denn für SSH nutze ich public keys.

Ich musste also irgendwie das root-Passwort zurücksetzen. Zunächst habe ich Google befragt, wie das am schnellsten zu erledigen wäre. In den Google-Ergebnissen tauchten immer wieder die folgenden zwei Vorschläge auf:

• single oder init=/bin/bash als zusätzliche Bootparameter im Bootloader angeben um die Passwortabfrage zu umgehen und anschließend mit passwd ein neues Passwort setzen
• das Dateisystem mittels einer Live-CD oder auf einem anderen Rechner mounten, mit chroot dieses Dateisystem als Rootverzeichnis festlegen und dann mit passwd ein neues Passwort setzen

Allerdings war für mich beides nicht möglich. Der Apex-Bootloader bietet während des Bootvorgangs keine Möglichkeit, die Bootparameter zu ändern und chroot funktionierte auch nicht, da das Gnublin-Board einen ARM-Prozessor hat und mein x64-Rechner folglich mit den Programmen auf der Gnublin-Partition nichts anfangen kann.

Also hieß es etwas tiefer ins Linux-System eintauchen und selber Hand anlegen:

Abspeichern, fertig. Das root-Konto hatte nun kein Passwort mehr und ich konnte mich ohne Passwortabfrage per serieller Konsole als root einloggen, die Wlan-Einstellungen korrigieren – und schließlich noch mit passwd ein neues root-Passwort setzten.

Auf der Speicherkarte des Fotoapparates befinden sich einige kaputte JPEG-Dateien:

Wenn der Fehler gleich am Anfang der Datei befindet, dann ist mit dem Bild nicht mehr viel anzufangen (Es sei denn man würde den Fehler beheben. Mit dem Thumbnail aus den Exif-Daten zum Vergleich und ein wenig intelligentem Bruteforce sollte das eigentlich möglich sein, aber ich kenne keine Software, die so etwas leistet). Tritt der Fehler jedoch erst am Ende auf, könnte man ja einfach den beschädigten Teil abschneiden und hätte wieder ein ordentliches Bild.

Das Problem besteht nur darin, die Datei erst ein mal zu öffnen. Die meisten Bildbetrachter zeigen das Bild bis zur fehlerhaften Stelle an, doch die Bildbearbeitungsprogramme verweigern sich komplett. Egal ob GIMP, MyPaint oder Inkscape: Alle liefern sie eine Fehlermeldung wie „Das Plugin JPEG-Bild konnte das Bild nicht öffnen“ oder „Unsupported marker type“.

Abhilfe schaffen hier Kommandozeilenprogramme wie jpegtopnm oder die verschiedenen Werkzeuge von ImageMagick. Die einfachste Reparaturmöglichkeit ist:

mogrify bild.jpg

Damit wird das Bild nur geöffnet und wieder abgespeichert. Zwar gibt es auch hier eine Fehlermeldung, aber man erhält eine gültige JPEG-Datei. Die Exif-Daten bleiben dabei erhalten.

Sinnvoller ist es natürlich, das Bild zunächst erst einmal in ein verlustfreies Format umzuwandeln, um anschließend mit einem Bildbearbeitungsprogramm den fehlerhaften Teil zu entfernen und das Bild wieder als JPEG abzuspeichern. Das geht mit

jpegtopnm bild.jpg > bild.pnm

oder

convert bild.jpg bild.pnm

Auch hier wieder Fehlermeldungen, aber die neue Datei wird angelegt. Fall man convert benutzt, muss man natürlich nicht unbedingt pnm als Format nehmen.

Im Anschluss bietet sich das Programm exiftool an, denn es kann Exif-Daten von einer Datei in eine andere kopieren:

exiftool -TagsFromFile bild.jpg bild_bearbeitet.jpg

Mit kann dabei sogar die Änderungszeit der Bilddatei auf die Aufnahmezeit setzen:

exiftool -TagsFromFile bild.jpg "-DateTimeOriginal>FileModifyDate" bild_bearbeitet.jpg

Ob das allerdings eine gute Idee ist muss jeder selbst entscheiden.

Auf der Weboberfläche der FritzBox gibt es eine Liste mit den angschlossenen Netzwerkgeräten. Bei allen Windows-Rechnern, die DHCP verwenden, steht auch der Rechnername dabei. Bei den Linux-Rechnern hingegen wird nur ein - angezeigt.

Dieses Problem ist leicht zu lösen. Es müssen auf den Linux-Rechnern nur zwei Zeilen in die Datei /etc/dhcp/dhclient.conf eingetragen werden:

send host-name "<hostname>";
send dhcp-client-identifier 00:00:00:00:00:00;

Die erste Zeile war bei meinem Ubuntu-Rechner sogar schon vorhanden, die zweite fehlte jedoch.

Von nun an kann man auf der Weboberfläche der FritzBox auch die Linux-Rechner mit Namen sehen. Die FritzBox ist außerdem in der Lage, DNS-Anfragen für diese Rechnernamen aufzulösen, sodass man jetzt den Rechnernamen anstatt der IP verwenden kann, um zwischen den Rechner zu kommunizieren.