Bonjour,
il peut arriver suite à la migration de buster vers bullseye que nginx se retrouve en carafe avec l’erreur suivante: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)
Un sudo systemctl status dhcpcd
remonte aussi les erreurs suivantes:
ipv6_addaddr1: Operation not supported
ipv6nd_startrs1: Address family not supported by protocol
Le module chargé de l’IPV6 semble en vrac, et ça nginx n’apprécie pas . Comme je ne peux pas répondre dans les anciens sujets déjà fermés et que ceux ci n’apportent pas (forcément) la réponse, je poste ici ma solution en espérant qu’elle puisse vous aider.
Le contexte: raspberrypi3 avec boot sur disque dur USB SANS écriture dans l’OTP.
Sur un raspberry, il existe 2 manières de booter sur un disque dur. Celle qui utilise l’écriture dans un registre OTP (Raspberry Pi, comment booter sur une clé USB ou un disque dur externe.) et celle “à l’ancienne” où l’on spécifie dans le cmdline.txt
de la carte SD sur quelle partition du disque booter.
J’étais personnellement dans le dernier cas, et pour bien comprendre la suite vous pouvez allez lire cette bonne explication sur le processus de boot d’un pi: https://www.framboise314.fr/booter-le-raspberry-pi-sur-un-disque-dur-usb/
Normalement si vous utlisez la méthode de l’OTP vous n’êtes pas concernés par la suite de ce post.
Le setup:
- une carte SD avec une partition
boot
et accessoirement une partitionrootfs
inutilisée - un disque dur contenant yunohost avec une partition
boot
et une partitionrootfs
Dans la partition boot
de la carte SD, vous avez normalement par le passé du avoir à éditer le champ root
pour avoir quelque chose du genre root=/dev/sdaX
Si vous êtes dans ce cas, la suite devrait vous intéresser
Que se passe t-il? Au boot, le PI est programmé matériellement pour booter sur la 1ère partition de la carte SD. C’est donc le kernel.img
(le noyau linux) de la carte SD qui est chargé en mémoire avec le rootfs
du disque dur (que vous avez précisé dans cmdline.txt
).
Or, une fois le kernel chargé quand le système se lance, à la lecture de /etc/fstab
vous avez probablement quelque chose du genre
PARTUUID=92c1f194-01 /boot vfat defaults,flush 0 2
Voyons voir à quoi cela correspond avec blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5967-01E6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="963254d4-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="fa97ff8c-9f89-4964-aecd-4128312b0909" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="963254d4-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5967-01E6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="92c1f194-01"
/dev/sda2: LABEL="rootfs" UUID="fa97ff8c-9f89-4964-aecd-4128312b0909" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="92c1f194-02"
Donc là, je dis à mon fstab de monter le réprtoire /boot
sur la partidion /dev/sda1
de mon disque dur qui contient un kernel.img
qui ne sera JAMAIS exécuté par le pi, puisque le “vrai” kernel se trouve sur la carte SD.
OK c’est très bien tout ça mais comment je fais pour corriger l’erreur moi? Patience, patience, on y arrive
Lors de la migration de buster à bullseye, on change de noyau. Le kernel.img
dans /boot
est donc modifié durant la migration. Vous voyez les problèmes arriver? Oui, oui, vous êtes en train de mettre à jour un kernel qui ne sera jamais exécuté par le pi…
Vous vous retrouvez donc au final avec une désynchronisation entre vore kernel et votre système.
On le voit très bien en regardant les dates de modification des fichiers.
Sur la carte SD:
-rwxr-xr-x 1 root root 6366112 Mar 8 2022 kernel7.img
-rwxr-xr-x 1 root root 6790336 Mar 8 2022 kernel7l.img
-rwxr-xr-x 1 root root 7916371 Mar 8 2022 kernel8.img
-rwxr-xr-x 1 root root 6016088 Mar 8 2022 kernel.img
Sur le disque dur:
-rwxr-xr-x 1 root root 6635232 Dec 22 14:19 kernel7.img
-rwxr-xr-x 1 root root 7045464 Dec 22 14:19 kernel7l.img
-rwxr-xr-x 1 root root 8197595 Dec 22 14:19 kernel8.img
-rwxr-xr-x 1 root root 6272904 Dec 22 14:19 kernel.img
On voit bien que c’est le mauvais kernel qui a été upgradé.
J’imagine qu’il y a eu une différence de configuration avec IPV6 chargé dans le noyau pour bullseye et qui n’étais pas le cas pour buster ou une joyeuseté de ce genre, je n’ai pas cherché.
Bon MAIS COMMENT JE CORRIGE b****l? On y vient!
Pour ma part, j’ai simplement écrasé les fichiers de la partition boot du disque vers la carte SD.
# on monte la carte SD
cd /tmp; mkdir sd;
sudo mount /dev/mmcblk0p1 sd;
# on sauvegarde les anciens fichiers au cas où
cd sd; mkdir old; cd old;
mv ../* .
# on copie les nouveaux fichiers
cd /tmp;
cp /boot/* sd;
# bien remettre dans le cmdline le boot sur le disque dur
nano sd/cmdline.txt
#et remettez la même valeur pour root que votre ancien fichier présent dans old/
# on redémarre le pi
sudo reboot
Tout devrait désormais fonctionner
Si oui, ce n’est pas fini car il ne s’agit pas de se faire avoir à la prochaine mise à jour.
on refait un blkid
Puis, sudo nano /etc/fstab
À la ligne correspondant au montage de /boot
, remplacer PARTUUID
par la valeur de la partition boot
de la carte SD ou par l’adresse du device: /dev/mmcblk0p1
Puis sudo reboot
Voilà, normalement un ls /boot
devrait vous montrer le répertoire old
créé précédemment (que vous pouvez supprimer) et qui vous confirme que la partion boot est désormais mappée sur le bon device.
J’espère que ce post sera utile à quelques uns
PS: pour ceux qui bootent sur le disque dur via l’OTP, ce correctif n’est pas valide car normalement vous n’avez plus besoin de carte SD, le kernel étant directement chargé sur la seule et unique partition boot
qui existe: celle de votre disque dur.