Monthly Archives: January 2008

XOrg vs. Eclipse

1 Reply

Als ich am Montag nach einem System-Update (Debian sid) mein Eclipse starten wollte, erschien statt der erwarteten IDE ein Fensterchen mit der Meldung, es hätte einen Fehler in der JVM gegeben. Eclipse konnte nicht gestartet werden, dementsprechend konnte ich meine Arbeit auch nicht fortsetzen.

Da man den Fehler ja zuerst bei sich selbst sucht, habe ich erst einmal das Update des Java Development Kit rückgängig gemacht und die Version 1.5 installiert. Der Fehler blieb leider.

Ein Blick auf die Console hat folgendes ergeben:
The program 'Eclipse' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 1272 error_code 11 request_code 148 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Eine Suche nach den entsprechenden Schlagworten hat mich schnell in die überall präsenten Ubuntu-Foren geführt, wo sich herausstellte, dass der Schuldige das Paket xserver-xorg-core ist, das mit Einführung eines Sicherheitsupdates das Ausführen von SWT-Applikationen mit eben dieser Meldung quittiert.

Die spontane Lösung dafür ist, das Update rückgängig zu machen und eine ältere Version zu installieren. Die habe ich auf den Paketservern leider nicht mehr gefunden, da dort nur die jeweils aktuellen Versionen vorliegen. Fündig geworden bin ich dann im Paket-Cache auf meinem eigenen Rechner, wo ich zum Glück noch eine ältere Version dieses Paketes hatte; manchmal ist es doch praktisch, nicht immer sofort alle Caches zu leeren. :)

Sollte jemand mit dem gleichen Problem hier vorbeikommen, kann er das mit folgenden Befehlen beheben:

wget http://www.tuxathome.de/deb/xserver-xorg-core_2%253a1.4.1%7Egit20080105-2_i386.deb
dpkg -i xserver-xorg-core_2%3a1.4.1~git20080105-2_i386.deb

Das installiert die Version, die vor dem Update ausgeliefert wurde. Es empfiehlt sich, die Version vom 18.01. als Forbidden zu markieren, damit sie beim nächsten Upgrade nicht gleich wieder installiert wird.

Achtung: Ich übernehme keinerlei gewährt für die Korrektheit und Verfügbarkeit des Paketes auf meinem Server oder den ordnungsgemäßen Ablauf des Downgrades!

Ich werde noch einen Bugrepot anfertigen (den habe ich jedenfalls nicht gefunden) und bin gespannt, wie lange es dauert, bis das Problem behoben ist. Mein Eclipse läuft jedenfalls erstmal wieder.

Treiberdiskette vom Hersteller

3 Replies

Ein Freund hatte in letzter Zeit massive Problem mit seinem (stein)alten Rechner und hat sich heute neue Hardware besorgt und zur Installation hier vorbeigetragen. Dabei sind ein aktuelles Mainboard mit Sockel AM2 und Unterstützung für SATA II mit NCQ und AHCI sowie eine aktuelle Festplatte, die das auch kann. Bekanntlich mangelt es da seitens Windows XP an Unterstützung bei der Installation und man muss F6 drücken und den passenden Treiber nachladen. Der Hersteller war so freundlich eine CD beizulegen und im Handbuch gut zu beschreiben, wie man die passende Diskette erstellt. Ich hab dann auch brav F6 gedrückt und der Windows-Installer fordert mich auf:

Legen Sie die Diskette beschriftet mit

Treiberdiskette vom Hersteller

in Laufwerk A: ein.

* Drücken Sie anschließend die EINGABETASTE.

»Treiberdiskette vom Hersteller«? Also erstens hab ich die gerade selbst erstellt und werde die dafür, dass ich die einmal brauche, sicher nicht beschriften und schon gar nicht so. Zweitens: angenommen, der Hersteller hätte tatsächlich eine Diskette beigelegt, würde er dann »Treiberdiskette vom Hersteller« drauf schreiben? Und was, wenn das jeder Hersteller machen würde und man dann ein paar solcher Disketten zu Haus liegen hätte?

lol2

Nicht das gesamte System verschlüsseln

3 Replies

Nach etwas oberflächlicher Recherche bin ich der Meinung, das Internet quillt über von Anleitungen zur Verschlüsselung ganzer Partitionen, ja ganzer Rechner (bis auf den MBR), mit allen Auswüchsen, die man sich denken kann und auch noch Motivationen und Begründungen dazu. Verschlüsselung der root-Partition, LVM auf einem verschlüsselten physical volume, verschlüsselte logical volumes in ansonsten unverschlüsselten LVM Dingern, das ganze noch mit und ohne RAID oder mit /boot noch auf dem USB-Stick, wahlweise mit Keyfiles oder herkömmlichen Passwörtern usw. Die Ansätze zur Verschlüsselung sind ähnlich vielfältig: dm-crypt mit und ohne luks, das klassische loop-aes oder truecrypt, um nur einige zu nennen.

Ich will einfach nur unter Debian Lenny eine Datenpartition verschlüsseln, kein RAID, kein LVM, boot-, root- und swap-Partition dürfen auch unverschlüsselt bleiben und das ganze am besten ohne einen eigenen Kernel kompilieren zu müssen und ohne Installation mit Live-CD oder sonstigen Spielerchen.

Ich habe also HowTos, Tutorials und manpages gewälzt und die Wahl fiel auf dm-crypt mit luks. Das ist aktuell, es ist alles bei Debian schon dabei und der Kernel muss nich neu kompiliert werden. Kurz noch die Grundvorraussetzungen hier: /boot auf CF-Karte als hda1, root-Partition ist hdd1 und swap hdd2, die Daten sollen alle auf hdd3 landen. Die ganze Einrichtung spielt sich mit root-Rechten ab, da wir nicht bei Ubuntu sind, einfach als root einloggen dafür! Die ersten Schritte bestehen darin, die nötigen Kernel-Module zu laden und das Programm cryptsetup zu installieren:

modprobe aes
modprobe dm-crypt
modprobe dm-mod
aptitude install cryptsetup

Die Partition, die verschlüsselt werden soll, darf nicht gemountet sein, ein Mountpoint sollte für später vorhanden sein, einfach das gewünschte Verzeichnis anlegen. Bei mir wird das /mnt/data sein. Als nächstes wird die Partition für die Verschlüsselung vorbereitet und geöffnet, quasi dem Device-Mapper bekannt gemacht. An diesem Punkt bitte darauf achten, dass alle Daten, die sich noch auf /dev/hdd3 befinden, danach unwiederbringlich verloren sind.

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hdd3
cryptsetup luksOpen /dev/hdd3 data

Beim ersten Aufruf wird nach einem Kennwort gefragt, das später als Schlüssel dient. Der zweite Aufruf öffnet sozusagen die verschlüsselte Partition, daher ist das Kennwort nochmal einzugeben. Jetzt kann man über /dev/mapper/data auf die verschlüsselte Partition zugreifen. Der erste Schritt: formatieren. Ich habe das ganze mit einer etwa 227 GB großen Partition und einem Pentium 133 getan. In der Zeit kann man ganz entspannt Kaffee kochen, trinken, die Kaffeemaschine sauber machen, Pizza backen, Pizza essen, den Ofen sauber machen…

mkfs.ext3 -v -L DATA /dev/mapper/data

Mounten klappt von Hand dann schonmal. Jetzt soll es noch so eingerichtet werden, dass die Partition auch beim Boot gemountet wird. Dazu werden die nötigen Kernelmodule, die vorhin von Hand geladen wurden in /etc/initramfs-tools/modules/ eintragen. Das sind

aes
dm-crypt
dm-mod
sha256

Danach nochmal die initrd neu bauen lassen mit

update-initramfs -u -k all

Als nächstes wird die /etc/fstab angepasst. Dort einfach /dev/hdd3 durch /dev/mapper/data ersetzen oder die Zeile neu anlegen. Weiterhin ist es noch nötig, die Datei /etc/crypttab anzupassen:

data /dev/hdd3 none luks,retry=1,cipher=aes-cbc-essiv:sha256

Das war’s. Das ist alles, mehr ist nicht zu tun. Beim booten wird man nach dem Passwort gefragt, der Rest läuft wie gewohnt. Noch ein Wort zur Performance: da nur die Datenpartition verschlüsselt ist, machen sich natürlich nur Zugriffe darauf bemerkbar. Kopieren mit rsync+ssh lastet den Rechner voll aus, das war vorher auch schon so, da ssh hier den Prozessor bereits zu voller Auslastung treibt. Mit zusätzlicher Verschlüsselung der Datenpartition sieht das in top dann so aus, als würden ssh und kcryptd/0 zu ungefähr gleichen Teilen für die CPU-Last verantwortlich sein. Mehr Aussagen kann ich dann machen, wenn die Daten wieder zurückgeschrieben sind, morgen oder übermorgen…