Résoudre [emerg] socket() [::]:80 failed (97: Address family not supported by protocol) sur raspberry

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 :confused: . 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/
:information_source: 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 partition rootfs inutilisée
  • un disque dur contenant yunohost avec une partition boot et une partition rootfs

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 :slight_smile:

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 :slight_smile:
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! :slight_smile:
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 :tada:

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 :slight_smile:

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.

4 Likes

Solution

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.