OK après un peu de fouille, j'ai trouvé un moyen de se débarrasser de ce problème au moins temporairement, c'est assez simple, mais je n'ai pas la configuration de mon système avec btrfs, donc je ne peux pas confirmer ce correctif.
commentez ou supprimez cette ligne:
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
ou
if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env \
recordfail; fi; fi
dans ce fichier
/etc/grub.d/00_header
puis exécutez
update-grub
la raison de ne pas modifier /boot/grub/grub.cfg
directement est qu'il sera écrasé à chaque mise à jour de grub dans ce cas, vous n'auriez à "refaire" le correctif que si les paquets communs de grub sont mis à jour.
C'est le bug sur le tableau de bord si vous voulez vous ajouter bug # 736743
Citant Colin Watson du rapport de bogue
Il s'agit en fait d'un message d'erreur trompeur: ce qui se passe, c'est que l'implémentation btrfs de GRUB n'implémente pas l'interface de hook de lecture de fichier pour retourner les listes de blocage au code appelant. J'ai posté sur grub-devel à ce sujet et le responsable en amont a souligné que, même en dehors des problèmes multi-périphériques, écrire sur btrfs depuis GRUB est fondamentalement risqué car:
le même bloc peut être utilisé par plusieurs instantanés chaque arbre qui utilise un bloc donné contiendra sa somme de contrôle, et ainsi de suite récursivement
Cependant, btrfs réserve de l'espace au démarrage pour le chargeur de démarrage. Cet espace est plus que GRUB a besoin de s'incorporer, et nous pourrions donc en utiliser 1 Ko pour un bloc d'environnement.
Dans tous les cas, ce n'est pas un nouveau problème qui est survenu en utilisant des sous-volumes, et cela n'empêche pas le démarrage (vous obtenez une fausse invite "Appuyez sur n'importe quelle touche pour continuer", mais si vous l'ignorez, il démarrera quand même). Revenir à la liste de souhaits.
J'espère que cela t'aides