Umstieg auf Linux

Will man eine Festplatte mit sensiblen Daten richtig entsorgen, so sollte man den Inhalt wenigstens einmal komplett überschreiben. Das Neuformatieren unter Windows ist beispielsweise nicht ausreichend. Entsprechende Programm können aus dem restlichen Inhalt die meisten Daten wieder herstellen.

Das Löschen einer Festplatte ist unter Ubuntu vergleichsweise einfach. Es gibt dort eine Datei, die unendlich viele Nullen enthält. Diese Datei (/dev/zero) liest man und schreibt sie auf Festplatte. Das ganze geht mit dem Befehl dd. Zunächst ermittelt man aber die richtige Zielfestplatte, nicht dass man plötzlich das System verliert. Die Festplattenbelegung ermittelt man mit fdisk.

fdisk -l | grep /dev

Die Ausgabe listet die Festplatten mit ihrer Größe. In den meisten Fällen reicht das aus, um eine Festplatte zu identifizieren. Im weiteren Beispiel verwende ich /dev/sdx als Festplatte. Dies muss natürlich durch den korrekten Pfad ersetzt werden. Das Löschen erfolgt dann mit

dd if=/dev/zero of=/dev/sdx

Alternativ kann die Platte auch mit Zufallszahlen (if=/dev/urandom) beschrieben werden. Ganz paranoide Gesellen versuchen vielleicht sogar beides hintereinander.

Das funktioniert ganz gut, solange die Festplatte in Ordnung ist und keine Fehler beim Schreiben auftreten. In manchen Fällen möchte man jedoch eine Festplatte gerade deshalb von sensiblen Daten befreien, weil sie defekt ist und Lese- oder Schreibfehler verursacht. Wie die Datenrettung durchgeführt wird, sei mal nicht Bestandteil dieses Artikels. Ich gehe von einem entsprechenden Backup aus, welches auf einer frischen Platte zum Einsatz kommt.

Der Befehl dd kennt noch eine Option namens conv.  Hier kann man noerror angeben. In der Hilfe steht jedoch, dass Lesefehler ignoriert werden. Ob das auch auf Schreibfehler angewandt wird, ist unklar.

Wer weiß Bescheid, wie man so viele Sektoren wie möglich einer defekten Festplatte beschreibt?

In meinem Fall hat conv=noerror geholfen. Möglicherweise hat aber beim ersten Versuch auch die Fehlerkorrektur der Festplatte eingesetzt und der defekte Block wurde durch einen fehlerfreien Ersatzblock ersetzt.

Ich hatte hier noch einen Rechner, der mit der Long-Term-Support Version 8.04 von Ubuntu ausgestattet war. Der Rechner wurde inzwischen durch einen Laptop ersetzt. Die Datenmigration hatte ich bereits vorgenommen. Der Rechner soll nun weitervermittelt werden. Dafür möchte ich Ubuntu 9.04 aufspielen.

Zuvor dachte ich mir: probier doch mal aus, wie sich ein Update von Ubuntu über zwei Versionen hinweg gestaltet.

Gedacht, getan: in den Optionen habe ich aktiviert, dass  die Versionsaktualisierungen angezeigt werden sollen, dann habe ich die Aktualisierungsverwaltung gestartet. Diese bot jedoch nur Version 8.10 als nächste Version an. Nach einem Download von ca. 2 Stunden (DSL 2000) ging die Installation los. Spät nachts (gegen 0:30 Uhr) hatte ich dann keine Lust mehr und habe den Rechner über Nacht weiterinstallieren lassen.

Dummerweise erschien zwischendurch eine Nachfrage zum Überschreiben einer Konfigurationsdatei, die die weitere Installation blockierte – ungeschickt. Hier wäre vielleicht ein Timeout angebracht, der nach einer gewissen Zeit, die Default-Antwort auswählt, eine Sicherungskopie der alten Datei anlegt und den Benutzer in einer Art Zusammenfassung informiert, was er noch tun muss.

Nach dieser Aktion war Ubuntu 8.10 dann jedoch auch komplett aktuell. Weitere Sicherheitsaktualisierungen mussten nicht mehr eingespielt werden.

Am Tag darauf wiederholte ich das Spiel für Ubuntu 9.04. Der Download dauerte diesmal 1 1/2 Stunden, die Installation zog sich dann aber wieder mehrere Stunden hin. Und wieder erschien eine Abfrage zum Ersetzen oder Beibehalten einer Datei. Also gab es noch keine Verbesserungen in dieser Hinsicht.

Jetzt wo der Rechner auf dem aktuellen Stand ist, werde ich ihn wohl komplett löschen und eine jungfräuliche Ubuntu 9.04 Installation aufsetzen. Schließlich will ich nicht riskieren, dass irgendwo persönliche Daten übrig geblieben sind. Der Upgrade-Marathon war ja auch nur ein Test, um zu wissen, wie ein solches mehrstufiges Upgrade abläuft.

Schön wäre sicherlich auch gewesen, direkt von 8.04 auf 9.04 zu aktualisieren. Na ja: Ubuntu hat auch noch seine Verbesserungsmöglichkeiten.

Während des Abrufens von Emails ist ein “MAC is in a deep sleep” Problem aufgetreten, wodurch ich den Rechner neustarten musste, während Evolution noch lief. Nach dem Neustart konnte Evolution zwar wieder gestartet werden, jedoch ist seither der Button “Verschicken/Abrufen” deaktiviert. Weiterhin konnte ich zwar Emails öffnen, aber der Inhalt war nicht vorhanden. Die Fehlermeldung hier “Inhalt der Nachricht konnte nicht abgerufen werden”. Und das obwohl ich eine Internetverbindung hatte.

Der Fehler war aber leicht gefunden: im Datei-Menü den Online-Modus aktivieren, schon klappte es wieder. Möglicherweise wurde in den Offline-Modus gewechselt, als ich die WLAN-Verbindung hardwareseitig abgeschaltet habe.

Heute hat Ubuntu die Festplatte geprüft, als ich Ubuntu startete. Die Zeit habe ich genutzt, um an einem anderen Rechner das Upgrade von Ubuntu 8.10 auf 9.04 vorzunehmen. Irgendwann war der Laptop dann auch so weit und ich begann Emails abzurufen, per WLAN versteht sich.

Doch dann passierte folgendes: der PC wurde immer träger, das Öffnen eines Links aus Evolution heraus wurde zur Geduldsprobe. Die CPU Auslastung, die bei mir in der oberen Leiste angezeigt wurde, blieb für beide Cores auf 800 MHz stehen. Die HDD LED (Lämpchen für die Festplatte) blieb auf Dauer-Ein.

Als irgendwann wirklich nichts mehr ging habe ich mit Strg+Alt+F1 ein Konsolenfenster geöffnet, was fast eine Minute in Anspruch nahm. Der erste Login schlug sogar fehl, weil die Aufforderung zur Eingabe des Passworts 60 Sekunden überschritt. Als ich es irgendwann schaffte, sah ich folgende Meldung auf dem Bildschirm:
iwlagn: MAC is in a deep sleep!
Was das genau heißen mag, musste ich nicht, aber dass der Rechner im Tiefschlaf war, habe ich auch so empfunden. Arbeiten war nicht möglich, lediglich ein beherztes sudo shutdown -r now ließ Hoffnung aufkommen. Die Aufforderung zur Eingabe des Passworts dauerte zwar wieder fast eine Minute, aber dann fuhr der Rechner tatsächlich runter.

In den Ubuntu Foren erfuhr ich, dass Lenovo T400 Nutzer dieses Problem wohl kennen. Eine Lösung wurde aber nicht angeboten. Ich bestätige den Fehler nun für ein Lenovo 3000 N200.

Nach dem Neustart meldete das Tracker Applet, dass während der Indizierung ein Fehler auftrat und der Index nun zerstört sei (“Index corrupted”). Gleichzeitig lag die Prozessorlast bei 100% auf beiden Kernen, die jetzt mit vollen 2,2 GHz getaktet waren. Immerhin reagierte der Rechner flüssig. Mit “Reindex all contents” versuchte ich zunächst, den Index zu retten. Das gelang nicht wirklich: die Frage tauchte mehrfach auf, gefolgt von genauso vielen Sicherheitsabfragen “Eine Indizierung kann sehr lange dauern. Wollen Sie das System neu indizieren?”. Das Festhalten der Esc-Taste für ca. 20 Sekunden löste das Problem und schloss geschätzte 200 Fenster dieser Art.

Die Prozessliste (ps -A) zeigte danach hohe CPU-Nutzung durch die Programme python, trackerd, dbus-daemon und tracker-indexer. Die CPU-Nutzung und Taktung verringerte sich nicht. Die Festplatten-Leuchte blinkte jedoch nicht, was bei einer aktiven Indizierung eigentlich zu erwarten gewesen wäre.

Dann tauchten die Abfragen wieder auf, so dass ich mittels ps -A | grep tracker alle Indizierungsprozesse ermittelte und mit kill tötete. Dadurch sank die CPU Last auf Null und die Taktung fiel auf 800 MHz.  Jetzt konnte ich mich endlich auf die Suche nach Meldungen im System machen.

Die Datei messages.0 lieferte erste Hinweise:
w3m[7831]: segfault at 0 ip 080a5f93 sp bfa873a0 error 4 in w3m[8048000+7f000]
iwlagn: TX Power requested while scanning!
iwlagn: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work

Segmentfehler sind vermutlich eine böse Sache. Dank den iwlagn Ausgaben kann ich nun vermuten, dass die Meldung “MAC is in a deep sleep” vom WLAN Treiber ausgegeben wurde. Näheres fand ich im Kernel Log (kern.log.0) zur Bootzeit (ca. 14 Sekunden nach Systemstart):
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
iwlagn: 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn: 0000:04:00.0: setting latency timer to 64
iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels
iwlagn: 0000:04:00.0: irq 2297 for MSI/MSI-X

Und dann später wieder (vermutlich nach dem Login, ca. 284 Sekunden nach dem Booten):
iwlagn: 0000:04:00.0: firmware: requesting iwlwifi-4965-2.ucode
ADDRCONF(NETDEV_UP): wlan0: link is not ready

Über 10 Minuten nach dem Bootvorgang (bei 612 Sekunden) wurde dann das WLAN erkannt und mit dem Access Point verbunden. Das erscheint mir nicht realistisch, denn zu diesem Zeitpunkt müsste ich bereits einige Emails abgerufen haben und mindestens eine Webseite besucht haben. Der erste segfault ist im Kernel Log bei 678 Sekunden, dann 938 Sekunden und nochmals bei 1012 Sekunden eingetragen.

Bei Sekunde 2452 haber ich dann den WLAN-Schalter betätigt, was auch im Kernel Log mit den Meldungen
iwlagn: TX Power requested while scanning!
iwlagn: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work
belegt ist. Der sogenannte “Kill switch” scheint also der hardwareseitige Schalter zum Ein- und Ausschalten des  WLANs zu sein.

Falls irgendjemand was damit anfangen kann, hier ist noch die Ausgabe von hwinfo –wlan:
06: PCI 400.0: 0282 WLAN controller
[Created at pci.314]
UDI: /org/freedesktop/Hal/devices/pci_8086_4230
Unique ID: y9sn.146MqY+fkf3
Parent ID: qTvu._Y5kuEY+GiC
SysFS ID: /devices/pci0000:00/0000:00:1c.1/0000:04:00.0
SysFS BusID: 0000:04:00.0
Hardware Class: network
Model: "Intel Lenovo ThinkPad T61"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x4230 "PRO/Wireless 4965 AG or AGN Network Connection"
SubVendor: pci 0x8086 "Intel Corporation"
SubDevice: pci 0x1111 "Lenovo ThinkPad T61"
Revision: 0x61
Driver: "iwlagn"
Driver Modules: "iwlagn"
Device File: wlan0
Features: WLAN
Memory Range: 0xf8000000-0xf8001fff (rw,non-prefetchable)
IRQ: 2297 (no events)
HW Address: 00:1d:e0:55:0c:bb
Link detected: yes
WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48
WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 5.18 5.2 5.22 5.24
WLAN encryption modes: WEP40 WEP104 TKIP CCMP
WLAN authentication modes: open sharedkey wpa-psk wpa-eap
Module Alias: "pci:v00008086d00004230sv00008086sd00001111bc02sc80i00"
Driver Info #0:
Driver Status: iwlagn is active
Driver Activation Cmd: "modprobe iwlagn"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #19 (PCI bridge)

Die Ausgabe von lsmod | grep iwl:
iwlagn 100228 0
iwlcore 93184 1 iwlagn
led_class 12036 1 iwlcore
mac80211 217208 2 iwlagn,iwlcore
cfg80211 38032 3 iwlagn,iwlcore,mac80211

Und die Ausgabe von dmesg | grep iwl:
[ 14.291685] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
[ 14.291688] iwlagn: Copyright(c) 2003-2008 Intel Corporation
[ 14.291758] iwlagn 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 14.291766] iwlagn 0000:04:00.0: setting latency timer to 64
[ 14.291841] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
[ 14.330567] iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels
[ 14.330636] iwlagn 0000:04:00.0: irq 2297 for MSI/MSI-X
[ 14.356955] phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 31.190050] iwlagn 0000:04:00.0: firmware: requesting iwlwifi-4965-2.ucode
[ 32.655080] Registered led device: iwl-phy0:radio
[ 32.655107] Registered led device: iwl-phy0:assoc
[ 32.655131] Registered led device: iwl-phy0:RX
[ 32.655162] Registered led device: iwl-phy0:TX

In einem Catch-All-Postfach, welches ich unter Ubuntu mit Evolution abrufe, haben sich mehrere Tausend Emails angesammelt. Da es sich um puren Spam handelt, lösche ich den Inhalt des Ordners in unregelmäßigen Abständen. Meist sind nur ein oder zwei Tausend Emails enthalten, heute hatten sich über 15000 angesammelt.
Das Löschen dauerte sehr lange, die CPU-Auslastung lag auf einer CPU bei 100% und Evolution war nicht mehr zu bedienen. Ich würde begrüßen, wenn wenigstens eine Art Fortschrittsbalken angezeigt würde. Insgeheim frage ich mich natürlich, warum man das Löschen nicht in einen zweiten Thread durchgeführt wird, so dass man in anderen Postfächern arbeiten kann.
Kann man das einstellen?

Das Upgrade von Ubuntu 8.10 auf 9.04 auf meinem Laptop schien problemlos zu funktionieren. Die Installation fragte sogar nach weniger Details als beim letzten Upgrade. Doch nach dem Neustart ist es dann passiert: Kernel Panic. Bisher habe ich das bei Ubuntu noch nie vorher gesehen, diesmal war es deutlich: die Taste für Num-Lock blinkte, nichts ging mehr.
Das Ausschalten des Rechners und Wiedereinschalten zeigte: größere Schäden sind zum Glück nicht geblieben. Ich wählte vorsichtshalber eine ältere Version des Kernels aus, da ein Kernel Panic wohl vom Kernel kommen muss… Damit bootete Ubuntu dann auch. Das Booten ging nicht so schnell voran, wie erwartet – schließlich waren bis zu 30% kürzere Bootzeiten angegeben. Da es sich um den ersten richtigen Start handelte, gehe ich mal davon aus, dass Ubuntu die Installation irgendwie noch vervollständigte.
Ich war sicher, dass Ubuntu irgendwo die Ursache des Kernel Panic abspeichern würde. Ein guter Ansatz sind die Logdateien unter /var/log. Darunter speziell das Kernel Log. Hier wurde ich dann auch fündig:

[...946] BUG: unable to handle kernel NULL pointer dereference at 00000000
[...949] IP: [<00000000>] 0x0
[...953] *pde = 00000000
[...956] Oops: 0000 [#1] SMP
[...958] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2e/ACPI0003:00/power_supply/ACAD/online
[...962] Dumping ftrace buffer:
[...964] (ftrace buffer empty)
[...966] Modules linked in: binfmt_misc ppdev bridge stp bnep vboxnetflt vboxdrv
input_polldev joydev sbp2 lp parport snd_hda_intel snd_pcm_oss snd_mixer_oss
snd_pcm arc4 ecb snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi
snd_seq_midi_event iwlagn iwlcore uvcvideo snd_seq snd_timer snd_seq_device
compat_ioctl32 psmouse led_class snd nvidia(P) videodev mac80211 sdhci_pci
soundcore usbhid video pcspkr intel_agp agpgart serio_raw btusb v4l1_compat
sdhci snd_page_alloc iTCO_wdt iTCO_vendor_support cfg80211 output ohci1394
ieee1394 tg3 fbcon tileblit font bitblit softcursor
[...004]
[...007] Pid: 1645, comm: iwlagn/0 Tainted: P (2.6.28-11-generic #42-Ubuntu) 0769BPG
[...010] EIP: 0060:[<00000000>] EFLAGS: 00010292 CPU: 0
[...013] EIP is at 0x0
[...015] EAX: 00000000 EBX: 00000000 ECX: f63b0e80 EDX: f63b0e80
[...017] ESI: f63b0e80 EDI: 00000000 EBP: 00000000 ESP: f5eff188
[...020] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[...022] Process iwlagn/0 (pid: 1645, ti=f5efe000 task=f62bb240 task.ti=f5c1c000)
[...024] Stack:
[...025] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[...030] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[...036] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[...042] Call Trace:
[...050] Code: Bad EIP value.
[...053] EIP: [<00000000>] 0x0 SS:ESP 0068:f5eff188
[...059] ---[ end trace bd792830be7f893d ]---

Leider sagt mir das gar nichts, außer dass die Werte nicht sonderlich gut aussehen. Alles sieht nach Null-Pointern aus… Wohin müsste ich den Bug berichten?