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.

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.

Eine Anmerkung vorweg:
Dies ist keine Anleitung, wie man einen kompletten Mailserver mit Postfix einrichtet. Zu diesem Thema finden sich viele Anleitungen im Internet. Ich schreibe hier nur, was ich anders gemacht habe als alle Anleitungen, die ich zu diesem Thema gelesen habe.
Die Pfade und Benuternamen beziehen sich auf eine Installation unter Ubuntu 10.04. Auf anderen Systemen können sie abweichen.

(I) Postfix und Mailman – die „normale“ Methode

Die übliche Konfiguration von Postfix mit virtuellen Domains und Mailman sieht etwa so aus:

/etc/postfix/main.cf:

alias_maps = hash:/etc/aliases,
             hash:/var/lib/mailman/data/aliases
virtual_mailbox_domains = meinedomain.de
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
virtual_alias_maps = hash:/etc/postfix/virtual_alias,
                     hash:/var/lib/mailman/data/virtual-mailman

Einen Computer neu einzurichten ist wirklich keine leichte Aufgabe ;-)

Nachdem nun auf dem Windows 7-Rechner alle Programme liefen und auch die Treiberprobleme umschifft waren, gab es ein neues Problem: Ich konnte von meinem Ubuntu-Rechner nicht auf die Freigaben des Windows-Rechners zugreifen.

Mit dem zuvor installierten Windows XP hatte es noch problemlos funktioniert, also war meine erste Vermutung, dass Ubuntu mit Windows 7 vielleicht nicht klar kommt. Doch Google hatte nichts passendes zum Thema Verbindungsprobleme zwischen Ubuntu und Windows 7. Auch das Durchprobieren sämtlicher Einstellungen der Windows-Firewall brachte nichts.

Schließlich hab ich doch noch des Rätsels Lösung gefunden: Der Windows 7-Rechner war zunächst auf DHCP eingestellt, also hat die FritzBox ihm eine IP-Adresse zugeteilt und sich auch gleich den NetBIOS-Namen gemerkt. Später hatte ich dann auf eine feste IP umgestellt (und für die NetBIOS-Namen von festen IPs interessiert sich die FritzBox nicht).

Der Samba unter Ubuntu ist standardmäßig so konfiguriert, dass er Hostnamen zunächst per DNS auflöst, und der zuständige DNS-Server ist nun mal die Fritzbox. Die FritzBox (die offenbar ein gutes Gedächtnis hat) lieferte also auf die DNS-Anfrage hin die IP-Adresse, die sie dem Windows-Rechner ein paar Tage zuvor zugeteilt hatte. Nur war unter dieser IP-Adresse schon lange kein Rechner mehr zu erreichen.

Das Problem ließ sich also ohne großen Aufwand beheben: Einfach in /etc/samba/smb.conf die Reihenfolge für die Namensauflösung so ändern, dass host ganz zum Schluss kommt:

name resolve order = lmhosts wins bcast host

Von nun an sucht der Ubuntu-Rechner selbst nach dem Windows-Computer, bevor er es per DNS versucht.