Passage de FreeBSD-8.2-STABLE a FreeBSD-9.0-BETA1

De Memento
Révision datée du 13 août 2011 à 13:31 par Hlh (discussion | contributions)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Sauter à la navigation Sauter à la recherche

Adaptation de la configuration du noyau

Après avoir effectué la procédure classique:

[root@morzine ~]# cd /usr/src
[root@morzine src]# rm -r .svn *
[root@morzine src]# svn co http://svn.freebsd.org/base/head /usr/src
A    /tmp/src/usr.bin
A    /tmp/src/usr.bin/lastcomm
A    /tmp/src/usr.bin/lastcomm/lastcomm.c
A    /tmp/src/usr.bin/lastcomm/pathnames.h
A    /tmp/src/usr.bin/lastcomm/readrec.c
A    /tmp/src/usr.bin/lastcomm/Makefile
A    /tmp/src/usr.bin/lastcomm/lastcomm.1
A    /tmp/src/usr.bin/kdump
...
[root@morzine src]# mergemaster -p
...
[root@morzine src]# make -s buildworld
...
[root@morzine src]# make -s kernel
...
[root@morzine src]# make -s installworld
...
[root@morzine src]# mergemaster -Fi
...
[root@morzine src]# shutdown -r now

Le système redémarre avec le nouveau noyau, mais s'arrête avec l'erreur Fatal trap 12: page fault while in kernel mode. En redémarrant avec le nouveau zfsloader le noyau 8.2-STABLE, le système s'arrête avec la même erreur! :-O

Après quelques recherches, je constate qu'en version 9.0 le module acpi n'existe plus et que donc le nouveau zfsloader ne le charge plus. Il s'agit là de la cause qui entraîne, aussi bien en 8.2-STABLE qu'en 9.0-BETA1, le Fatal trap 12 si l'acpi n'est pas activé pour la configuration particulière de mon système.

En ajoutant device acpi à la configuration de mon noyau, tout rentre dans l'ordre.

Hélas, la carte WiFi Atheros 5424/2424 n'est plus reconnue. Ce problème est provoqué par l'introduction en FreeBSD 9.0 du nouveau module ath_pci. En ajoutant device ath_pci à la configuration du noyau, la carte est à nouveau correctement détectée.

Démarrage avec zfsboot

Sur un de mes systèmes, le disque est partagé entre Windows 7 et FreeBSD. FreeBSD est sur un pool ZFS:

[root@meribel ~]# gpart show     
=>       63  312581745  ada0  MBR  (149G)
         63  167782797     1  ntfs  (80G)
  167782860  144798948     2  freebsd  [active]  (69G)
 
=>        0  144798948  ada0s2  BSD  (69G)
          0  144798948       1  freebsd-zfs  (69G)

Il faut donc, pour pouvoir mettre à niveau la version du pool ZFS, préalablement mettre à niveau le zfsboot de la partition FreeBSD (/dev/ada0s2a):

/bin/dd if=/boot/zfsboot of=/dev/ada0s2a bs=512 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.016262 secs (31484 bytes/sec)
/bin/dd if=/boot/zfsboot of=/dev/ada0s2a bs=512 skip=1 seek=1024 
128+0 records in
128+0 records out
65536 bytes transferred in 0.012285 secs (5334638 bytes/sec)

Cette mise à jour se fait en démarrant le système à l'aide d'une clé USB (par exemple mfsBSD) pour que l'accès à la partition ne soit pas protégé.

Mais comme j'avais déjà recompilé tous le système à l'aide du nouveau compilateur clang, j'ai constaté que le démarrage du système se bloque lors de l'affichage de la barre tournante par zfsboot. Après avoir compilé zfsboot avec le compilateur classique gcc, tout rentre dans l'ordre.

Adaptation des ports

Sous FreeBSD-9 utmp(5) a été remplacé par l'interface standardisée POSIX utmpx [1]. Le port sysutils/libutempter doit être supprimé car cette API est maintenant intégrée au système.

Si x11/gdm est utilisé, il faut le réinstaller après la suppression de sysutils/libutempter.

Préférence IPv6 / IPv4

J'ai constaté que FreeBSD-9.0 utilise par défaut IPv4 tandis que la version précédente (FreeBSD-8.2) utilisait par défaut IPv6 si le protocole est disponible entre le client et le serveur. Ce comportement est contrôlé par la commande ip6addrctl(8). Pour rétablir la priorité du protocole IPv6, il suffit d'ajouter un parapètre dans /etc/rc.conf ou /etc/rc.conf.local :

 ip6addrctl_policy="ipv6_prefer"

Référence