NetBSD 4.0 - neues Release, weiterhin problematisch
Diesen Beitrag schrieb ich 15 Jahre und 1 Monat zuvor; die nachfolgenden Ausführungen müssen heute nicht unbedingt noch genau so funktionieren. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Das neue NetBSD verspricht viel, und die Entwickler haben eine Menge Arbeit investiert, um von Version 3.0 auf 4.0 zu kommen; das 3.0-Release hatte ich nach mehreren Ansätzen auf i386, sparc und Xen laut fluchend in all seinen Ausprägungen gelöscht.
NetBSD-4.0 soll spielend mit Xen-3 zu betreiben sein; auf Xen-3.0.4 bootet es absolut nicht, hier war ein Upgrade auf Xen-3.1 nötig. Das Anbooten des INSTALL-Kernels funktioniert problemlos, die Installation verläuft so unkompliziert, wie man es nur von NetBSD kennt. Ich habe zwei Disk-Images angelegt: einmal 20GB für das System an sich, einmal 10GB für $DATEN (beim 3.0-Release hat das nicht funktioniert: der hat bei jedem Neustart der domU die Images verwürfelt…). Funktioniert, bootet extrem schnell; die Netzwerkkonfiguration via xennet0 ist tadellos, schon kurze Zeit nach der Installation pingt das virtuelle Maschinchen in die grosse weite Netzwelt und ist von aussen erreichbar.
Als erstes brauche ich pkgsrc, das ich mir via CVS vom NetBSD-Server ziehe. Grundlegende Dinge kommen als erstes ins System: screen, bash, wget, curl usw. Der Compiler flitzt, man kann eigentlich nur begeistert sein. Auf lange Sicht will ich diese und all die anderen von mir gehosteten Domains nämlich von Linux wegbewegen – reicht gerade, wenn man sich auf der Arbeit damit herumschlagen muss – und Opensolaris braucht zu viel Speicher auf der Hardware, die ja mehrere domUs bedient.
Also fix überlegt: was brauche ich, wenn ich die jetzige domU vollständig ersetzen will? mysql, ganz klar. apache, php und mailman, denn hier werden auch einige Mailinglisten betrieben. sendmail, spamassassin und cyrus-imapd für die grundlegende Mailversorgung, darüberhinaus fetchmail und procmail für das Fine-Tuning. Und das sind nur die Hauptanforderungen. /usr/pkgsrc/www/apache22 kompiliert überhaupt nicht und fällt nach einer Weile dank apr auf die Schnauze – mal wieder ein pthread-Problem, zuletzt ist mir das im SPARC-Port untergekommen (nerv!). Einen apache-1.3.7 kann ich installieren, einschließlich php-5.2.5, und auch /usr/pkgsrc/databases/mysql5-server kompiliert brav und lässt sich installieren.
Und hier fangen die Probleme nun an. Beim Beobachten der Konsole fiel mir häufig folgende Meldung auf:
/netbsd: pid 7160 (conftest), uid 0: exited on signal 12 (core dumped)
Vorsicht! signal 12 bedeutet hier etwas völlig anderes als unter Linux, wie man in /usr/include/sys/signal.h nach-grep-en kann:
#define SIGSYS 12 /* bad argument to system call */
Ähnliches passiert bei dem irrsinnigen Versuch, mysql_install_db auführen zu wollen:
Installing MySQL system tables...
[1] Done(141) (echo "use mysql... |
Bad system call (core dumped) ${mysqld_install...
Installation of system tables failed!
Das Starten des mysql-Daemons schlägt ebenfalls fehl, leider gibt /var/mysql/$HOSTNAME.err auch nicht wirklich mehr her:
084706 17:47:35 Starting mysqld daemon with databases from /var/mysql
084706 17:47:35 mysqld started
[1] Bad system call nohup /usr/pkg/l...
084706 17:47:35 STOPPING server from pid file /var/mysql/skurril.pid
084706 17:47:35 mysqld ended
Und genau das selbe bei dem Versuch, spamd anlaufen zu lassen:
/netbsd: pid 1511 (spamass-milter), uid 0: exited on signal 12 (core dumped)
Für letzteren gibt es in / sogar ein Dump-File, das man ein wenig mit dem gdb traktieren kann:
(gdb) core /spamass-milter.core
Core was generated by `spamass-milter'.
Program terminated with signal 12, Bad system call.
#0 0xbb6156f7 in ?? ()
(gdb) bt
#0 0xbb6156f7 in ?? ()
Klasse. Das nutzt mir nix. Zudem kann ich nicht mehr als zwei Virtual Block Devices in die Konfig hängen; andersherum formuliert: ich kann schon, aber jeder Eintrag nach dem zweiten wird stillschweigend ignoriert. Das hier ist die Konfiguration (im Original natürlich ohne die Umbrüche):
disk = [
'file:/vm/skurril/rootfs.img,0x03,w',
'file:/vm/skurril/filefs.img,0x04,w',
'file:/vm/skurril/opdata.img,0x01,w' ]
Und das hier ist der Output beim Booten:
$ dmesg | grep xbd
xbd0 at xenbus0 id 3: Xen Virtual Block Device Interface
xbd0: using event channel 5
xbd1 at xenbus0 id 4: Xen Virtual Block Device Interface
xbd1: using event channel 6
xbd0: 20480 MB, 512 bytes/sect x 41943040 sectors
xbd1: 10000 MB, 512 bytes/sect x 20480000 sectors
boot device: xbd0
root on xbd0a dumps on xbd0b
Alles Herumprobieren mit ID-Nummern schafft da keine Abhilfe. Tja, was ist da nun das Fazit? Ich liebe NetBSD – ich benutze es seit Version 1.6, und es ist toll. Leider ist es für meine Belange jedoch auch unbrauchbar – offenbar nach wie vor. Die einzige Hoffnung besteht derzeit darin, einen eigenen PAE_XEN3DOMU-Kernel zu bauen, der bzgl. dieses Syscalls Abhilfe schafft, denn der, den ich aktuell einsetze, kommt aus der HEAD-Revision und bizarrerweise vielleicht wirklich zu neu für das System? Obwohl es mich schon arg wundern würde, wenn sie für NetBSD-5.0 die Syscall-Struktur umwerfen wollen…? Ich hab den Maintainer mal angemailt, ggf. erhalte ich da ja eine Rückmeldung, die mir weiterhilft.