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.

Auch wenn dem deutschen Schüler schon lange klar ist, dass von der Institution Schule eine nicht zu unterschätzende Gefahr ausgeht, kommt das Thema in der breiten Öffentlichkeit dennoch kaum zur Sprache.

Unsere französischen Nachbarn sind da schon ein ganzes Stück weiter und stellen direkt an der Straße ein blinkendes Warnschild auf.

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

Nachdem die Medien im Vorfeld der Sonnenfinsternis große Panik geschürt hatten, aber der erwartete deutschlandweite Stromausfall dann doch ausgeblieben ist, habe ich mir mal die Logdaten der heimischen Solaranlage hergenommen und eine kleine Auswertung gemacht. Herausgekommen sind folgende Grafiken:

In den Grafiken ist jeweils die erzeugte Leitung vom Tag der Sonnenfinsternis (20. März 2015) und vom Tag davor zu sehen. An beiden Tagen war klarer Himmel, so dass man die Daten gut vergleichen kann. Im ersten Diagramm sieht man die Werte vom Hausdach. Dieses Dach hat eine Südwest-Ausrichtung (ca. 222°), da fällt die Sonnenfinsternis nicht so ins Gewicht. Anders siehts da schon beim Schuppendach (ostsüdost, ca. 118°) aus, hier fiel die Sonnenfinsternis in die Zeit mit dem höchsten Ertrag.

Vom Zusammenbruch des Stromnetzes waren wir scheinbar noch weit entfernt, denn von der Möglichkeit der Leistungsreduzierung per Funksignal hat der Netzbetreiber keinen Gebrauch gemacht.

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.