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.
Wenn du so viele Probleme mit dem Gefrickel hast, warum benutzt du dann nicht das gute Windows Vista vom Weltmarktführer? *duckundweg*
hehe falming spillerm. :-D
Speziell Fedora kannst mich ja fragen, irgendwie hab ich auch wieder alles ans laufen bekommen. Aber wenn man schon soeine Abneigung hat, dann *will* ich niemanden bekehren – hoffentlich will mich niemand zu mac-os überreden, das finde ich zum säufzen (warum gibts keine pos1 taste??).
Ja okay mit dem „Dreck“ kann ich als Antwort auch leben, nur dachte ich das es da noch spezifischere Infos gibt. Warum ich mit Vorliebe überall *BSD nutze weiß ich auch ;-)
Wesbezüglich genau? „Aller von mir gehosteten Domains“ oder „von Linux wegbewegen“?
Zu ersterem: als Mini-Hoster habe ich halt mehrere Domains unter meiner Fuchtel.
Zu letzterem: Linux ist Dreck, und daran wird sich so schnell auch nichts ändern; das einzige Linux, dass ich noch ansatzweise gelten lasse, ist Debian — gerade RH und Fedora kenne ich nur als massiv fehleranfällig und extrem nervig zu warten. Eine Migration zu NetBSD wäre mir, wie im Text erwähnt, die liebste Option, denn NetBSD ist einfach performant, klein und unglaublich stabil. Die Alternative wäre ein (speicherfressendes) Opensolaris.
Im Moment ringen wir aber noch mit dem NetBSD-Kernel; wenn die Vermutungen sich bestätigen und in der Tat Userland und Kernel nicht einwandfrei zusammenpassen, so müsste sich die Syscall-Problematik mit dem Bauen eines NetBSD aus current eigentlich erledigt haben…
„Auf lange Sicht will ich localwurst.de und all die anderen von mir gehosteten Domains nämlich von Linux wegbewegen“
Hast du auch Details diesbezüglich?
7 Comments
wie deutsch ?
manche Menus sind ausversehen auf deutsch, aber da drueck ich auch nur das „zweite“ weil das edit meint. Ansonsten *huestel* als noch a.out und nicht elf das executable format war, war die welt noch in Ordnung. Heute hab ich mir nur die Amerikanische Tastaturbelegung erhalten. btw: vom prinzip her, kann man sich mit debian Paketen viel einfacher in den Fuss schiessen, als mit rpms (rpm ist deutlich transaktioneller)
@Martin: Du+Fedora=ja, und auch noch auf deutsch — das war schon ziemlich igitt ;) Zu MacOS: kommt drauf an welche Version. 6.06 war durchaus liebenswert und die 7er auch zu ertragen. Ich muss zugeben, dass ich mit 8 und 9 nie so recht warm geworden bin (und stattdessen lieber A/UX vergewaltigt hab). OS X war unter 10.2 ein Krampf im Zusammenspiel mit dem Compiler (was musste ich auch mit aller Gewalt GTK 1&2 haben?), 10.3 war lahm, 10.4 ziemlich genial und 10.5 unterirdisch schlecht (zumindest bislang). Die fehlende Pos1-Taste hat mich nie gestört, die fehlende DEL schon viel eher (iBook).
Aber Du hast recht, im Vergleich zu einem hübschen NEXTSTEP oder OPENSTEP (worauf MacOS X ja basiert) ist auch MacOS ein Krampf… ;)
@DrAlzheimer: weil ich zuviele Alternativen kenne :D