Archiv für Dezember, 2010

Absturz von OpenOffice beim Dateiauswahldialog

19. Dezember 2010 von edgar

Dieser Fehler trat bei mir immer mal wieder auf, und zwar völlig unregelmäßig. Die meiste Zeit ging alles ganz normal, aber an manchen Tagen tauchte folgendes Problem auf:

OpenOffice stürzt einfach ab, sobald der Dateiauswahldialog geöffnet wird (also beim Öffnen, Speichern unter, PDF-Export). Das Problem lässt sich problemlos reproduzieren. Nach einem Neustart des Computers ist es (manchmal) weg. Allerdings ist dieses Problem insgesamt sehr nervig, weil man nicht mehr vernünftig arbeiten kann.

Wenn ich OpenOffice in der Kommandozeile starte, dann erhalte ich folgende Fehlerausgabe:

QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/edgar/.config/ibus/bus
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
X-Error: BadAtom (invalid Atom parameter)
Major opcode: 17 (X_GetAtomName)
Resource ID: 0x13121313
Serial No: 15681 (15681)
These errors are reported asynchronously,
set environment variable SAL_SYNCHRONIZE to 1 to help debugging

Weder der Hinweis zu iBus noch SAL_SYNCHRONIZE brachten mich bei diesem Fehler weiter. Falls jemand einen Grund oder eine Lösung findet, bitte hier posten.

Ich habe lediglich ein Workaround gefunden: Wenn der Fehler auftritt kann man bei „Extras“ > „Optionen“ unter „OpenOffice.org“ > „Allgemein“ > „Öffnen/Speichern Dialoge“ das Häkchen vor „OpenOffice.org-Dialoge verwenden“ setzen.

luksOpen tut nichts bei (falsch) zusammengebautem RAID

6. Dezember 2010 von edgar

Hier kommt mal wieder ein sehr nerviges Problem. Mein Szenario ist folgendes:

Man hat ein RAID 1 (Festplattenspiegelung), darin liegt eine mit LUKS verschlüsselte Partition. Dabei ist mindestens eine der RAID-Partitionen die einzige Partition der Festplatte. Nachdem man zunächst das RAID von Hand angelegt und dann alles getestet hat, trägt man die Daten für das RAID (welche man über mdadm --detail --scan bekommt) in die Datei /etc/mdadm/mdadm.conf ein. Nach dem nächsten Reboot läuft auch alles (scheinbar) ganz normal. Allerdings passiert nichts, wenn man mit

sudo cryptsetup luksOpen /dev/md0 [label]

sein verschlüsseltest Laufwerk aktivieren möchte. Es kommt nicht einmal eine Meldung. Hier hilft der Parameter -v:

edgar@atlantis: ~ $ sudo cryptsetup -v luksOpen /dev/md0 backup
Command failed with code 22: /dev/md0 is not a LUKS device.

Natürlich ist hier weder das Cryptolaufwerk noch LUKS kaputt, sondern das RAID. Vermutlich würde auch alles andere (z.B. mount) einen Fehler melden. Was genau kaputt ist liefert ein Blick in /proc/mdstat:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[0] sdc[1]
488351744 blocks [2/2] [UU]
unused devices: none

Seht ihr den Unterschied? Ein Eintrag lautet „sdb1“, der andere nur „sdc“. mdadm hat aus versehen die gesamte Festplatte (/dev/sdc) als RAID-Device interpretiert und nicht die Partition (/dev/sdc1). Das ist sehr ärgerlich und lässt sich laut ubuntuusers dadurch vermeiden, dass man die Partition mindestens 128 KB kleiner macht als die Plattengröße.

Sicherer ist aber eine Definition in der /etc/mdadm/mdadm.conf. Der vordefinierte Eintrag „DEVICE partitions“ allein hilft allerdings nicht. Man sollte die Partitionen entweder komplett für jedes RAID in der Form „DEVICE /dev/[partition1] /dev/[partition2]“ angeben, oder aber einen Wildcard-Eintrag der Form „DEVICE /dev/hd*[0-9] /dev/sd*[0-9]“ benutzen.

Achtung: Bei einem RAID sollte man immer zuerst prüfen, ob es korrekt zusammengebaut ist! Sobald man irgendwelche Tools wie z.B. fsck auf ein falsch gebautes RAID loslässt, gehen die Daten mit hoher Wahrscheinlichkeit verloren!



css.php