Problème de démarrage LXC sur device Btrfs

Analyse et résolution d'un problème curieux, arrivé après un reboot sur un serveur Rise1 OVH.

Contexte

Après installation LXD, et transfert d'images entre 2 machines, tout fonctionnait bien. Le storage par défaut a été créé lors de l'installation (par la commande lxd init) de type btrfs.

Au redémarrage, les containers ne veulent plus redémarrer :

lxc start openldap
Error: Common start logic: no such device
Try `lxc info --show-log openldap` for more info

On essaie donc la commande :

lxc info --show-log openldap
Name: openldap
Remote: unix://
Architecture: x86_64
Created: 2020/03/26 16:47 UTC
Status: Stopped
Type: persistent
Profiles: default

Log:

Rien de très parlant. Voyons le fichier /var/log/lxd/lxd.log :

tail /var/log/lxd/lxd.log

t=2020-03-30T16:09:30+0000 lvl=info msg="Done updating instance types" 
t=2020-03-30T16:09:30+0000 lvl=info msg="Expiring log files" 
t=2020-03-30T16:09:30+0000 lvl=info msg="Done expiring log files" 
t=2020-03-30T16:09:30+0000 lvl=info msg="Updating images" 
t=2020-03-30T16:09:30+0000 lvl=info msg="Done updating images" 
t=2020-03-30T16:24:48+0000 lvl=eror msg="Failed to mount BTRFS storage pool \"/dev/loop0\" onto \"/var/lib/lxd/storage-pools/default\" with mountoptions \"user_subvol_rm_allowed\": no such device" 

Analyse

Il semblerait que le point de montage n'existe pas :

df -h|grep lxd
tmpfs           100K     0  100K   0% /var/lib/lxd/shmounts
tmpfs           100K     0  100K   0% /var/lib/lxd/devlxd

Pas de trace du répertoire storage-pools.

Sur une machine qui fonctionne :

df -h |grep lxd
tmpfs           100K     0  100K   0% /var/lib/lxd/shmounts
tmpfs           100K     0  100K   0% /var/lib/lxd/devlxd
/dev/loop0      100G   19G   76G  20% /var/lib/lxd/storage-pools/default

Sur cette machine, si on regarde les file systems montés en BTRFS, on a bien quelque chose :

mount |grep btrfs
/var/lib/lxd/disks/default.img on /var/lib/lxd/storage-pools/default type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

Sur notre serveur à problème, on peut cependant explorer le répertoire /var/lib/lxd :

ls -l /var/lib/lxd/disks/
total 109061108
-rw------- 1 root root 150000000000 mars  28 17:37 default.img

On essaie de monter le volume

losetup /var/lib/lxd/disks/default.img /dev/loop0
mount -t btrfs -o subvol=/,rw,relatime,space_cache,subvolid=5,user_subvol_rm_allowed  /dev/loop0 /var/lib/lxd/storage-pools/default 

Mais ça plante :

mount: /var/lib/lxd/storage-pools/default: unknown filesystem type 'btrfs'.

En fait , le montage s'effectue lorsqu'on lance la commande _lxc start _

A priori, ce n'est donc pas un problème de container, mais de module dans le noyau. En recherchant sur le net, on trouve ces commandes qui permettent de vérifier si le support de btrfs est bien intégré au noyau :

lsmod |grep -i btrfs

Ne renvoie rien. Pas plus que

grep btrfs /proc/filesystems

Résolution

Après de longues heures de recherche, la solution est somme toute assez simple. Quand on connait la réponse, c'est toujours plus simple !

Il suffit de lancer la commande :

modprobe btrfs

Et soudain, tout se débloque :

lsmod |grep -i btrfs
btrfs                1138688  0
zstd_compress         163840  1 btrfs
xor                    24576  2 async_xor,btrfs
raid6_pq              114688  4 async_pq,btrfs,raid456,async_raid6_recov

On peut accéder au stockage :

lxc storage show default --resources
space:
  used: 97629040640
  total: 149999996928

et lancer une VM sans problème

lxc start openldap

La grande question est donc : pourquoi a-t-on perdu ce paramétrage après un redémarrage ?

Après un autre test de reboot, le problème est survenu à nouveau. Il semblerait bien que le module soit "blacklisté" au démarrage... Au moins j'ai le mode de résolution.

Tags
Catégorie
Permalien

Bonjour,

Je me suis retrouvé dans la même situation, et après 2 heures de recherches, je suis tombé par hasard sur le message de quelqu'un qui avait remarqué que son module (un autre) était blacklisté, en faisant « journalctl -b | grep btrfs ».

Ce qui est aussi mon cas :
```
Nov 13 19:40:54 costadelsol kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-amd64 root=UUID=7340b105-18f5-4511-9a16-2e3fb879e71b ro vga=normal nomodeset modprobe.blacklist=btrfs
Nov 13 19:40:54 costadelsol kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-amd64 root=UUID=7340b105-18f5-4511-9a16-2e3fb879e71b ro vga=normal nomodeset modprobe.blacklist=btrfs
Nov 13 19:40:54 costadelsol systemd-modules-load[339]: Module 'btrfs' is blacklisted
Nov 13 19:41:07 costadelsol kernel: request_module fs-btrfs succeeded, but still no fs?
```

Il a fallut le trouver ensuite, pour ma part ici « /etc/default/grub.d/50-cloudimg-settings.cfg »

Puis penser à mettre à jour grub :
`# update-grub`

Par contre je ne comprend pas du tout pourquoi btrfs est blacklisté sur les installations par défaut chez OVH.

Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et les adresses courriel se transforment en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.