FreeBSD 8.0-RELEASE ist da - jetzt aber wirklich!
Nachdem die Meldung verfrueht schon bei Heise und Golem zu lesen war, was zu diverser Kritik fuehrte, nun auch hier: Vor etwa 24 Stunden wurde FreeBSD 8.0-RELEASE offiziell veroeffentlicht.
Fuer die Ungeduldigen gibt es die Highlights, fuer die Interessierten mit etwas Zeit zum Lesen: Die kompletten Release Notes. Darin sind auch die Aenderungen gegenueber 7.1 und 7.2 zu finden.
FreeBSD 8.0 macht Spass. Ich habe die letzten Tage, seit dem 8.0-RELEASE im cvs tree getagt war, damit verbracht die Maschinen in meinem Umfeld auf 8.0-RELEASE zu bringen. Zuerst die, die zum Test in einer voellig unwichtigen VMWare irgendwo rumduempelten, teilweise mit einem ueppig installierten ports-tree, um auch das Verhalten von den anstehenden portupgrade -f Massenaufrufen beurteilen zu koennen. Aber da war nichts.
Der eben erst aufgesetzte Kundenserver mit 8.0-RC3 machte das Update erwartungsgemaess problemlos mit.
Fuer den speziellen Fall, dass jemand lagg(4) zusammen mit em(4) verwendet: Es funktioniert nicht. Ich musste die schoenen Intel-Karten echt gegen Realtek-Schrott austauschen und schon war wieder alles beim alten. Der FreeBSD-Intel-Treiber wird von Intel persoenlich entwickelt. So aendern sich die Zeiten. Dranbleiben. Das muss eigentlich sofort in die ERRATA.
Fuer AMD-Xen-User: Das noetige Tuneable fuer AMD-Xens heisst hw.clflush_disable=1.
Spannend finde ich die Tatsache, dass die Verteilung des Interesses von i386 (32bit) und amd64 (64bit) im FreeBSD Torrent Tracker gleich verteilt erscheint.
Die aelteren unter uns mag interessieren, dass COM1: jetzt /dev/cuau0 heisst. Die Zeiten von mgetty, uucico und pppd sind leider lange vorbei. Wir haben jetzt uart(4) statt sio(4). Ob man nun einen 16550 oder einen 16550A hat, interessiert lange keinen mehr. Ich verwende tatsaechlich noch den apcupsd ueber die Serielle.
FreeBSD 8.0 ist das erste FreeBSD in dem der ZFS-Support nicht mehr als experimental gekennzeichnet ist (quasi seit dem Import von zfsv13). Ich habe ZFS in v6 mit unterdimensionierter Hardware (i386, wenig RAM, bisschen Gefummel an den tuneables) getestet und habe nicht zuletzt durch nicht ganz gewolltes Fehlverhalten ein desastroeses Ergebnis produzieren koennen. Seit v13 habe ich zwei amd64-Maschinen mit ausreichend RAM (8 und 16 GByte) mit zfs im Einsatz und es macht seit Wochen im Produktivbetrieb keinerlei Aerger. Snapshots werden intensiv genutzt: zfs-snapshot-mgmt ist ein toller port, aber auch das gute alte freebsd-snapshot laesst sich problemlos parallel einsetzen. Ohne wenigstens eines der beiden moechte ich am liebsten kein Unix-System mehr betreuen, anstaendig konfigurierte Snapshots (mit mount via amd, ich sage nur cd /snap/home:daily.0) sind echt ein Segen.
Da ja nun fdisk und mbr bald (also in ein paar Jahren oder so) ausgedient haben werden, ist dies nun auch der richtige Zeitpunkt, um sich mit gpt auseinanderzusetzen. Vor dreieinhalb Jahren kam ich mit meinem 2.4TiB 3ware-RAID5 zum ersten mal in die Verlegenheit. Da hiess das FreeBSD-Kommando noch gpt(8). Nun ist es gpart(8). Es wird die Zeit kommen in der man regelmaessig Festplatten mit >2TiB in den Haenden hat.
Ganz aktuell gibt es eine schoene Anleitung um FreeBSD mit gpt, zfsroot und ganz ohne ufs-Partition zu installieren: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
Die ganze Aktion ist gewiss nichts fuer Leute mit einer Kommandozeilenaversion. Es bleibt abzuwarten wie lange es benoetigt, bis der aufgezeigte Pfad seinen Weg in sysinstall findet. Ich habe die Schritte nachvollzogen und habe nun in einer weiteren VMWare-Instanz ein GPT-ZFS-only-FreeBSD-8.0-RELEASE. Diese Installationsmethode koennte ich problemlos auf einem Hetzner-Server mit Hilfe des FreeBSD-Rescue-Systems durchfuehren. Bei 1&1 bleibt immer noch nur die Holzhammermethode: VMWare-Minimal-Disk-Image via ssh | dd auf die Platte schreiben und hoffen, dass es von der hoffentlich korrekt konfigurierten Seriell-Console bootet. Das mbrlabel kann man unter FreeBSD problemlos mit fdisk(8) auf die tatsaechliche Groesse aendern. Dass das auch mit gpart(8) geht, ist anzunehmen, aber mir liegen hierzu keine Erfahrungen vor...