Tagged “mandriva”

Ehrenrettung für Mandriva: Intel-Treiber 2.7.0 macht Probleme

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Update 20.05.2009: Mit dem heute erschienenen Update auf kernel-desktop-2.6.29.3-1mnb-1-1mnb2 hat sich das Problem zumindest für mich erledigt. Der hier beschriebene Workaround sorgt nun im Gegenteil dafür, dass der X-Server nicht mehr startet. Deshalb vor dem Update die Zeile unbedingt auskommentieren!

Die Performance-Probleme gingen doch nicht auf Mandrivas Kappe. Statt dessen ist Intel schuld: Die Kombination aus Treiber-Version 2.7.0 und Kernel 2.6.29 macht laut diesem Foren-Beitrag zicken!

Die dort empfohlene Abhilfe hat auch bei mir funktioniert. In die /etc/X11/xorg.conf in der Section Device den folgenden Eintrag hinzufügen:

Section "Device"
 Identifier "device1"
 VendorName "Intel Corporation"
 BoardName "Intel 810 and later"
 Driver "intel"
 Option "DPMS" **Option "AccelMethod" "UXA"** EndSection

Außerdem wurde dort noch empfohlen, in die /etc/modules die folgende Zeile einzutragen;

i915 modeset=1

Bei mir war das aber nicht nötig, das System rennt auch ohne diesen Eintrag wieder wie gewohnt. Hoffen wir, dass ich an diese Einträge denke, wenn irgendwann der Kernel 2.6.30 stabil wird und sie nicht mehr nötig sein sollten ;-)

Ein kritischer Blick auf Mandriva 2009.1

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Update: Inzwischen steht ich Mandriva nicht mehr ganz so kritisch gegenüber.

Nachdem mich der Network-Manager von KDE 4.2 neulich so geärgert habe, wollte ich mal einem System die Chance geben, welches KDE als nativen Desktop verwendet. Da ich eine total unlogische und subjektive Abwehrhaltung gegenüber SuSE verspüre fiel die Wahl auf Mandriva 2009.1. Übrigens, Mandriva, welches damals noch Mandrake hieß, war die erste Linux-Distribution, die ich damals längere Zeit einsetzte.

Aber ich fürchte, die Beziehung steht unter keinem guten Stern.

Installation

Ich betreibe ein System mit Vollverschlüsselung, d.h. die gesamte Festplatte ist verschlüsselt. Dies ist für den Ubuntu-Installer eine harte Nuss, aber Mandriva hat da gleich mal Pluspunkte gesammelt, da ich problemlos eine verschlüsselte Root-Partition anlegen und sogar mein verschlüsseltes Homeverzeichnis einbinden konnte. Diesen Vorsprung konnte es aber nicht lange halten, denn zunächst vergaß das Programm mich darauf hinzuweisen, dass ein vollverschlüsseltes System nicht funktionieren kann, wenn es nicht wenigstens eine unverschlüsselte /boot-Partition gibt. Die Installation lief zwar durch, funktionierte am Ende aber natürlich nicht.

Gut, dass war recht schnell gelöst. Aber dann zeigte sich, wie lieblos die Vollverschlüsselung bei Mandriva implementiert ist. Es ging damit los, dass der USB-Treiber für die Tastatur nicht im 'initrd.img' eingebunden ist. Dadurch konnte ich das Passwort nur an der Laptop-Tastatur eingeben, was an meinem Schreibtisch etwas ungünstig ist, da das Laptop hier auf einem Ständer steht und die Tastatur damit einen unkomfortablen Winkel von ~30° hat - und mein Passwort ist nicht das kürzeste.

Dieses Problem lässt sich aber nach dem Start recht schnell lösen:

$ su
$ mkinitrd -f --with-usb --with=usbhid /boot/initrd-$(uname -r).img $(uname -r)

Nun werden die USB-Treiber eingebunden und vor der Passwortabfrage geladen. Übrigens, bei diesem Schritt muss ich mal anmerken, dass ich die Verwendung eines echten 'root'-Account mit eigenem Passwort im Vergleich zu 'sudo' ziemlich rückständig finde. So Web-1.0-mäßig ;-). Naja jedenfalls wird man recht schnell die nächste Einschränkung bemerken: Das initrd-Script prüft nicht, ob die Passworteingabe erfolgreich war, so dass sich das System mit einer "kernel panic" verabschiedet, wenn man sich mal vertippt hat. Dann hilft nur noch ein harter Reset. Der Grund dürfte darin liegen, dass die vom initrd-Script verwendete Shell 'nash' keine Schleifen und kein 'if' beherscht. Also erstmal die dash-Quelltexte runtergeladen, das Meta-Paket 'task-c++-devel' installiert (übrigens zweimal, da beim ersten mal mit einer angeblich fehlenden Abhängigkeit abgebrochen wurde), und versucht, das ganze mit './configure --enable-static && make' zu kompilieren. Fehlanzeige, es gibt einen Konflikt mit einer der mitgelieferten C-Header-Dateien, die das statische kompilieren verhindert. Nun gut, also 'dash' auf einem Ubuntu-System statisch kompiliert und rüberkopiert.

Update: Mandriva liefert bereits ein statisch gelinktes dash mit, es liegt unter /bin/dash.static. Ich habe den Patch für "mkinitrd" entsprechend angepasst.

Das fertige 'dash'-Programm wird nun unter /usr/libexec/dash abgelegt und das Script /sbin/mkinitrd ein wenig modifiziert ('dash' und der Patch für mkinitrd im Anhang). Nun ist das initrd-Image zwar etwas größer, dafür aber auch komfortabler. Ach übrigens, damit das Root-Dateisystem überhaupt erkannt wurde, musste ich die Kerneloption 'root=LABEL=mandriva-root' in 'root=/dev/mapper/crypt_sda7' ändern (siehe /boot/grub/menu.lst).

Netzwerk

Die Netzwerkverwaltung überzeugte. Im Gegensatz zu Ubuntu steht hier das Netzwerk auch ohne besondere Kunstgriffe bereits vor dem Login zur Verfügung. Dafür muss man zum Wechseln der WLAN-Verbindung allerdings auch etwas tiefer in die Einstellungen gehen. WPA-EAP konnte ich noch nicht testen, aber ich gehe davon aus, dass es funktioniert.

Paketverwaltung

Naja was gibt's dazu zu sagen. Wenn man Tools wie 'apt-get' oder 'emerge' gewöhnt ist, dann ist 'urpmi' eine echte Krücke.

Grafische Oberfläche

Merkwürdigerweise legte Mandriva in der Konfiguration eine Auflösung von "1024x768" fest, obwohl das Konfigurationswerkzeug ("Computer konfigurieren > X-Server") durchaus aus meine native Auflösung von 1400x1050 erkannte und akzeptierte.

KDE

Ubuntu legt die KDE-Konfiguration in $HOME/.kde ab, Mandriva in $HOME/.kde4. Ein kleiner Symlink verschafft Abhilfe, wenn man unter beiden Systemen die selbe Konfiguration verwenden möchte.

Außerdem muss man sich erstmal darüber klar werden, dass Mandriva über das gesamte Panel ein zweites gelegt hat. Um das Originalpanel zu erreichen ist es notwendig, rechts drauf zu klicken und "Kontrolleister entfernen" zu sagen - was das System mit einer bedrohlichen Warnung quitiert. Ignoriert man diese, ist aber wieder alles OK.

Nicht OK dagegen sind die Icons im Instant-Messanger "Kopete", welche nun wirklich riesig sind. Die Ursache dafür habe ich noch nicht gefunden. (Nachtrag: "Einrichten > Kontaktliste > Kontaktlistensil > Statissymbole linksbündig". Trotzdem merkwürdig, dass Mandriva diese Einstellung verändert hat.)

Performance

Das wundert mich echt. Im Gegensatz zu Ubuntu fühlt sich Mandriva sehr schwergängig an. Das liegt aber nicht an den Anwendungen, sondern an den CPU-Performance-Einstellungen. Obwohl beide Systeme den "ondemand"-Govenor verwenden, der die Leistung der CPU bei Bedarf erhöht, scheint die Reaktionszeit oder der Schwellwert bei Mandriva höher zu sein, so dass das System einen oftmals bei minimaler Taktfrequenz warten lässt. Update: Mandriva ist unschuldig.

Vorläufiges Fazit

Ich werde Mandriva noch ein paar Tage verwenden, aber es sieht wirklich nicht so aus, als ob wir Freunde werden. Alles, was abseits von der Vorgabe liegt, funktioniert nur halbherzig oder garnicht. Darüber hinaus habe ich innerhalb von nichtmal 24h gefühlt bereits mehr Probleme erlebt als in meiner gesamten bisherigen Ubuntu-Zeit (z.B. die Abhängigkeiten, die erst beim zweiten Durchlauf aufgelöst wurden, obwohl ich nichts verändert hatte). Außerdem vermisse ich 'apt' und 'sudo'. Letzteres kann man natürlich nachinstallieren, dennoch gehen die Systemprogramme davon aus, dass 'root' über ein eigenes Passwort verfügt.

Anhänge

Mandriva und eduroam

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Neben den klassischen WLANs "Uni Osnabrueck" und "FH Osnabrueck" sind beide Hochschulen seit längerem auch Teil des WLAN-Netzwerkes eduroeam. Für die Studenten hat dieses Netzwerk den Vorteil, dass sie auch den Zugang der jeweils anderen Hochschule mitnutzen können. Mit Kubuntu und seiner komischen NetworkManager-Lösung konnte ich mich dort nie erfolgreich anmelden, aber mit Mandriva geht es relativ problemlos.

Zunächst benötigt man die Zertifikatskette des Netzwerkes im PEM-Format. Das Rechenzentrum stellt hierfür eine kleine Anleitung bereit.

Dann öffnet man die Netzwerk-Konfiguration "draknetcenter" und wählt das gefundene "eduroam"-Netzwerk (auf die Bilder klicken zum Vergrößern):

eduroam auswählen

Ein Mausklick auf den Button "Konfigurieren" bringt einen auf die Einstellungsseite. Als Verschlüsselungsmodus muss "WPA/WPA2 Enterprise" ausgewählt sein, der "EAP Login/Benutzername" entspricht dem Benutzernamen für die Universitätsdienste mit angehängtem "@uni-osnabrueck.de", also z.B. "username@uni-osnabrueck.de", und das "EAP Passwort" ist das selbe, mit dem man sich z.B. in den Webmaildienst oder dem Stud.IP einlogt:

eduroam konfigurieren

Für das eduroam-Netzwerk müssen noch einige "Fortgeschrittene Optionen" konfiguriert werden, indem der entsprechende Knopf am Ende der Seite angeklickt wird. Hier sind die folgenden Einstellungen zu treffen:

  • EAP-Modus: TTLS
  • EAP key_mgmt: WPA-EAP
  • EAP äussere Identität: anonymous@uni-osnabrueck.de
  • EAP Phase2: auth=PAP
  • EAP CA Zertifikat: Vollständiger Pfad zur heruntergeladenen Zertifikatskette

eduroam fortgeschritten

Fertig, im Normalfall sollte das Netzwerk nun verbinden. Falls es nicht klappt hat es bei geholfen, die Datei /etc/wpa_supplicant.conf nach dem network mit der Zeile ssid="eduroam" zu suchen und einige überflüssige Zeilen zu entfernen, so dass der Ausschnitt danach so aussieht (die Reihenfolge der Einträge ist egal):

network={
  ssid="eduroam"
  key_mgmt=WPA-EAP
  eap=TTLS
  ca_cert="/pfad/zur/eduroam.pem"
  password="PASSWORT"
  identity="USERNAME@uni-osnabrueck.de"
  anonymous_identity="anonymous@uni-osnabrueck.de"
  phase2="auth=PAP"
}

Nun noch mit dem Befehl /etc/init.d/network restart das Netzwerk neu starten und fertig. Natürlich kann man alternativ auch gleich die Datei /etc/wpa_supplicant.conf bearbeiten, wenn man keine Lust auf den grafischen Assistenten verspürt ;-)

Mandriva und ich

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Vor einigen Tagen schrieb ich einen ziemlichen Veriss über meine ersten Versuche mit Mandriva. Das ist nun vier Tage her, und ich hab seit dem nicht einmal mehr Ubuntu gebootet. Deshalb hier ein kurzes Update: Suspend to Ram

Der "Schlafzustand" funktionierte bei mir immer genau einmal, beim zweiten mal wachte das System nicht wieder auf. Es handelt sich laut Bug #47276 um ein Problem im Linux-Kernel, welches für viele wohl mit Kernel 2.6.29rc5 behoben wurde - für mich leider nicht. Die manuelle Installation von Kernel 2.6.30rc5 brachte schließlich die erhoffte Abhilfe. Auf http://www.howtoforge.com/kernel_compilation_mandriva ist dies ganz gut beschrieben. Das einzige Manko dieser Anleitung ist, dass Mandriva inzwischen auf 'grub' und nicht mehr auf 'lilo' setzt. Der letzte Punkt ist demnach so nicht mehr korrekt.

Performance

Wie ich bereits festgestellt hatte, lag dies am Intel-Treiber. Die im verlinkten Beitrag beschriebene Lösung hilft, alternativ tuts auch ein manuelles Update auf Kernel 2.6.30.

Vollverschlüsselung

Nix neues von der Front. Der im letzten Artikel beschriebene Patch an 'mkinitrd' tut seinen Dienst ganz hervoragend.

TuxOnIce

Mein nächstes Projekt. Wegen der Vollverschlüsselung wird dazu jedoch ein etwas umfangreicherer Patch an 'mkinitrd' notwendig werden.

Netzwerk

Auch eduroam funktioniert problemlos. Witzigerweise wurde direkt nach meinem Wechsel auch der Bug im Network-Manager von Kubuntu endlich gefixt. Muss ich denn immer gleich die Distribution wechseln, bevor Fehler behoben werden?

KDE

Das kritisierte dopppelte Kontrollpanel scheint auf meine von Ubuntu übernommene Konfiguration zurückzuführen zu sein. Mandriva ist also unschuldig.

Paketverwaltung

Durch Zufall bin ich auf den Smart Package Manager gestoßen, ein Distributionsübergreifendes Paketmanagement, welches in der Bedienung deutlich von Apt inspiriert ist. Bei MandrivaUser kann man sich über eine Weboberfläche Konfigurationsdateien mit den passenden Spiegelservern erstellen lassen.

Nicht mehr ganz so vorläufiges Fazit

Die französische Distribution und ich haben uns nach ersten Reibereien aneinander gewöhnt. Mein Ausflug in die Ubuntu-Welt währte damit gerade mal ein halbes Jahr. Mal schauen, wie lange ich mit Mandriva zufrieden bin. Die gröbsten Klippen sind umschifft und mit 'smartpm' existiert eine schöne Alternative zu 'urpmi'. Nur den echten 'root'-Account anstelle der konsequenten Verwendung von 'sudo' finde ich immer noch von vorgestern. Aber gut, Debian ist da nicht besser.

Mandriva 2009.1: Lock KDE 4 on Suspend

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

In my installation, KDE failes to lock the screen on suspend / hibernate, even if the checkbox "lock screen" in the "Energieverwaltung" (how is this labeled in english? Power configuration? Don't know...) is enabled. So I've adapted this patch to Mandriva.

Create the file /etc/pm/sleep.d/50-lock with the following content:

#!/bin/sh

lockX() {
    for x in /tmp/.X11-unix/*; do
        displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
        user=`w -hs | awk '{ if ($3 == ":'$displaynum'" || $2 == ":'$displaynum'" ) { print $1; exit; } }'`
        export DISPLAY=":$displaynum"
        su $user -c "dbus-send --session --dest=org.freedesktop.ScreenSaver --type=method_call --print-reply /ScreenSaver org.freedesktop.ScreenSaver.Lock"
    done
}

case "$1" in
    hibernate|suspend)
        lockX
        ;;
    thaw|resume)
        ;;
    *) exit $NA
        ;;
esac

Make this file executable (chmod 755 /etc/pm/sleep.d/50-lock). That's it. Pretty simple, isn't it?

Update 2009-05-30:

Here is another version of this script (from Ubuntu Bug #283315 ).

Mandriva 2010.0: I'm very impressed

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Ich installiere gerade das RC2 von Mandriva 2010.0 und der erste Eindruck ist: Reeeespekt! Ich hab's dem Installer besonders schwer gemacht, indem ich (neben einer kleinen ext2-Partition für /boot) den gesamten Rest in einr verschlüsselte dm-crypt-Partition gepackt habe, dort hinein ein LVM und dieses in swap, / und /home aufgeteilt habe:

+- sda1: /boot (ext2, 256 MB)
+- sda2: dm-crypt (LVM, 200 GB)
 +- vg0/1: swap (4 GB)
 +- vg0/2: / (ext4, 25 GB)
 +- vg0/3: /home (ext4, 212 GB)

Zur Erinnerung: Mandriva 2009.1 ist schon an wesentlich weniger gescheitert, an LVM habe ich mich damals nicht getraut weil schon für eine verschlüsselte root-Partition Handarbeit notwendig war. Aber 2010.0 hat's auf Anhieb hinbekommen, dieses Szenario erfolgreich zu booten!

Bin ja mal gespannt, wie meine weiteren Erfahrungen so sein werden.

Update

Mein Respekt steigert sich gerade ins unermessliche. An Suspend-To-Disk bei verschlüsselter Swap-Partition ist bis jetzt noch jede Distribution gescheitert, die ich getestet habe, Doch Mandriva hat sich gerade ohne zu murren schlafen gelegt und ist auch wieder aufgewacht!

Update 2

Aber definitiv noch RC und nicht Stable - nach einem Upgrade sind die LVM-Devices aus der /etc/fstab verschwunden und der neue Kernel panic'd rum. Wird Zeit für nen Bugreport :-)