Nachdem ich meinen Hauptrechner aufgerüstet hatte, fiel die alte Hardware für meinen VDR ab und da ich damit nun in der Lage war endlich mehr als nur 10 Farben im OSD ausgeben zu können ohne daß alles crasht (ich hatte meinen VDR vorher mit einer DXR3-Dekoderkarte zu laufen), beschloss ich einen Versuch mit X-Server und Softdevice zu wagen. Da der VDR optisch nicht ganz so hübsch ansprechend ist wie MythTV entschloss ich mich letzteres einfach mal auszuprobieren, traf dann aber auf Probleme die mich wieder zum VDR zurückgeführt haben. Und der sieht gar nicht mehr so schlecht aus auf der neuen Hardware.

Alle Angaben im Beitrag beziehen sich auf Gentoo. (more…)

Da seit gestern eine Festplatte Probleme hat beim Systemstart hochzukommen (warum auch immer, die letzten 3 Wochen lief sie einwandfrei) und mir so sämtliche Mountpoints durcheinander gekommen sind, bin ich nun dazu übergegangen, UUIDs anstelle der Partitionsnummern zu verwenden. Dazu muss in der /etc/fstab lediglich anstelle von z.B. /dev/sd.. ein UUID= gefolgt von der jeweiligen, über ls -al /dev/disk/by-uuid ermittelten ID gesetzt werden.

Die IDs erscheinen möglicherweise in 2 verschiedenen Längen:

NTFS: 6220109320107071
Linux: 707fec45-b39b-4905-88b0-da454e9bf91d

In der /etc/fstab u.a.:
UUID=6220109320107071   /mnt/winf       ntfs-3g         auto,noatime    0 0

Über Google finden sich auch einige Vorschläge diese als Kernel-Option in der Form root=UUID=... anzugeben, allerdings ist dies kein Standard-Feature des Kernels und erfordert eine Ergänzung per initrd. Letztlich ist das aber eh in den meisten Fällen Schwachsinn, denn wenn eine Festplatte ihre Nummer wechselt, kann zumindest GRUB eh seine Stages nicht mehr finden und kommt gar nicht erst bis zum Kernel.

Für Linux-Soft-RAIDs kann die Angabe der UUIDs bei den Mountpoints entfallen – im Superblock des RAIDs ist bereits eine “Preferred Minor”-Angabe enthalten, welche für die korrekte /dev/md-Nummer sorgen soll. Wenn ich mich nicht irre, werden die Linux-Soft-RAID-Devices übrigens auch standardmäßig über ihre UUID identifiziert.

Bei Verwendung von 3D-Desktops unter Linux, wie z.B. Compiz(-Fusion), kommt es zu einem Bug der mir bisher noch gar nicht aufgefallen war. Mit Swing entwickelte Anwendungen zeigen (teilweise reproduzierbar) ein leeres Fenster:

Abhilfe schafft das Installieren von libXP und Wechsel des Toolkits via export AWT_TOOLKIT=MToolkit. Laut Kommentar im Fedorablog ist das aber nur ein grober Workaround, da anschließend wohl einige Maße nicht mehr stimmen.

Sun hat dafür auch einen Bugreport. Das Problem ist allerdings schon ziemlich alt. Scheinbar wird oder wurde daran zwar gearbeitet aber angesichts des Alters und der bisher nur sporadisch greifenden Fixes ist fraglich, wann das Problem endgültig behoben wird. Hilft wohl erstmal nur, bei Swing-Entwicklung Compiz abzuschalten.

Nachdem nun schon seit einer Weile vesafb nicht mehr aktiv war, wollte ich letztens die Auflösung des Konsolen-Framebuffers wieder erhöhen. Dabei stellte sich heraus, daß vesafb durch uvesafb abgelöst wurde, welches einige Funktionen in den Userspace verlagert. Außer der Aktivierung der Kerneloption werden noch (unter Gentoo) eine Neukompilierung von klibc und als Userspace-Teil v86d benötigt. Eine genaue Anleitung gibts auf der Projektseite beim Autor.

Gegenüber vesafb ändert sich im besten Fall nicht viel in den Kernelparametern. In meinem Fall lautete der neue Eintrag:

video=uvesafb:ywrap,1280x1024-32@85

Nur auf 85Hz kam ich nach einem Reboot leider nicht, stattdessen flimmerte der Monitor mit 60Hz vor sich hin. Scheinbar können von vielen Nvidia-Karten die Werte des Monitors nicht ausgelesen werden. Allerdings lassen sich ersatzweise 3 Parameter übergeben, mit denen der Wechsel in die höhere Bildwiederholrate gelingt:

1. maxhf – maximale horizontale Frequenz
2. maxvf – maximale vertikale Frequenz
3. maxclk – Takt des Grafikchips

Die ersten beiden Werte hat man schonmal in /etc/X11/xorg.conf eingetragen, Section Monitor, in meinem Fall HorizSync 30.0 - 96.0 und VertRefresh 50.0 - 160.0. Den Takt verrät Xorg beim Start und lässt sich im Logfile wiederfinden. cat /var/log/Xorg.0.log | grep -i hz liefert bei mir: (--) NVIDIA(0): STN SAMTRON (CRT-1): 350.0 MHz maximum pixel clock

So lassen sich dann folgende Parameter ergänzen:

video=uvesafb:ywrap,1280x1024-32@85,maxhf:96,maxvf:160,
maxclk:350

dmesg meldet dann:
uvesafb: NVIDIA Corporation, NV28 Board, Chip Rev A0, OEM: NVIDIA, VBE v3.0
uvesafb: protected mode interface info at c000:e740
uvesafb: pmi: set display start = c00ce785, set palette = c00ce80a
uvesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03
uvesafb: VBIOS/hardware doesn't support DDC transfers
uvesafb: monitor limits: vf = 160 Hz, hf = 96 kHz, clk = 350 MHz
uvesafb: scrolling: ywrap using protected mode interface, yres_virtual=4915
uvesafb: framebuffer at 0xd8000000, mapped to 0xf8880000, using 24576k, total 65536k

Beim wöchentlichen emerge –sync trat bei mir grad folgender Fehler auf:

timed out
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(276) [receiver=2.6.9]

Woran auch immer das gerade gelegen haben mag, folgende Zeilen für die make.conf, die ich in einem Thread im Gentoo-Forum gefunden habe, konnten mir weiterhelfen:

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" # Round Robin für europäische Server
PORTAGE_RSYNC_INITIAL_TIMEOUT=500 # setzt das Timeout für rsync auf 500 Sekunden

Wer zur Zeit ein Update auf den Linux-Kernel 2.6.23 durchführt und eine alte Nvidia-Grafikkarte benutzt, den könnte eine Überraschung erwarten. Die alten 1.0.96xx-Treiber von Nvidia kompilieren damit nämlich nicht mehr nachdem nun schon vor einiger Zeit die GeForce 4-Serie zu “legacy” erklärt und von neueren Treibern ausgenommen wurde. Allerdings gibt es dennoch einen funktionierenden Treiber, nämlich 96.xx. Nvidia hat – warum auch immer – die Versionsnummern nachträglich umbenannt und sorgt damit jetzt ganz gut für Verwirrung. Schön wenn man dann alle Treiber >= 1.0.9700 auf mask gesetzt hat.

Unter Linux war es aufgrund einer Inkompatibilität mit neueren GTK-Versionen schon seit einiger Zeit nicht mehr möglich, das Adobe Flash-Plugin mit Opera zu benutzen. Die aktuelle Beta-Version von 9.50 behebt dieses Problem nun endlich. Unter Last laufen Flash-Filme allerdings nur sehr langsam ab, im Gegensatz zum Firefox.

GRUB und LILO booten ja von sich aus leider keine CDs/DVDs. Über einen größeren Umweg kann man aber dennoch das gewünschte (Boot-)Ziel erreichen.

Im Linux-Club-Wiki ist mit dem Artikel “Von Grub direkt auf CD-Boot umschwenken” eine kurze Anleitung zu finden. Es werden noch die Tools memdisk (Bestandteil von syslinux) und SmartBootManager benötigt.

In der Anleitung wird SBM auf Floppy geschrieben, ein Durchbooten zu einem CD-Laufwerk eingerichtet und die Änderungen gespeichert (deshalb der Floppy-Umweg). Die Floppy wird dann wieder in ein Image zurückgeschrieben und von memdisk gebootet. Reicht das (umfangreiche) Menü von SBM kann man sich den Umweg über die Floppy auch sparen und direkt das Original-Image verwenden.

Für Selbstkompilierer ist SYSLINUX hier zu erhalten. Die meisten Distributionen sollten es allerdings auch als eBuild/Package oder dergleichen vorrätig haben. Der SmartBootManager hat seine Projektseite auf SourceForge, das fertige Image gibt es auf linux.simple.be.

Damit entfällt dann endlich das nervige BIOS-Umkonfigurieren nur um eine Live-CD zu booten.