Les écritures sur disque ne sont pas supportées> Qu'est-ce qui déclenche cette erreur?

C'est un bogue!

Il s'agit d'un bogue qui survient dans la version la plus récente d'Ubuntu Server LTS (Ubuntu Server 14.04 LTS) lorsque vous créez la partition de démarrage (ou la partition racine, lorsque la partition de démarrage n'existe pas) dans une partition LVM ou RAID. .

Vous pouvez obtenir plus d'informations sur ce bogue dans Ubuntu Launchpad: Bug n ° 1274320 "Erreur: les écritures de filtre de disque ne sont pas prises en charge" .

Mise à jour: Ce bogue est déjà corrigé dans Ubuntu Server 14.04 et certaines versions plus récentes d’Ubuntu. Probablement, il suffit de courir apt-get upgrade.

Pourquoi ce bug se produit?

Lorsque le système démarre, GRUB lit les load_envdonnées ( ) dans /boot/grub/grubenv. Ce fichier s'appelle GRUB Environment Block .

Du manuel GRUB:

Il est souvent utile de pouvoir se souvenir d’une petite quantité d’informations d’un démarrage à l’autre.

[...]

Au démarrage, la commande load_env (voir load_env) charge les variables d'environnement à partir de celle-ci, et la commande save_env (voir save_env) lui enregistre les variables d'environnement.

[...]

grub-mkconfig utilise cette installation pour mettre en œuvre GRUB_SAVEDEFAULT

Ce comportement peut être trouvé dans /etc/grub.d/00_header( update-grubutilise ce fichier pour générer le /boot/grub/grub.cfgfichier):

if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi

Le problème est que l' save_envinstruction ne fonctionne que dans des installations simples (vous ne pouvez pas exécuter à l' save_envintérieur d'un disque RAID ou LVM). Du manuel GRUB:

Pour des raisons de sécurité, ce stockage est uniquement disponible lorsqu’il est installé sur un disque ordinaire (sans LVM ou RAID), avec un système de fichiers non soumis à un checksum (sans ZFS) et avec les fonctions BIOS ou EFI (sans ATA, USB ou IEEE1275).

La fonction recordfail de GRUB utilise l' save_envinstruction pour mettre à jour l'état recordfail (voir la section Aide Ubuntu - Grub 2 , section "Dernier échec du démarrage ou démarrage en mode de récupération"). Cependant, dans Ubuntu 14.04 (et dans les versions récentes de Debian), l’ save_envinstruction (à l’intérieur de la fonctionnalité recordfail) est utilisée même si GRUB est installé dans un LVM ou un RAID.

Voyons les lignes de 104 à 124 dans /etc/grub.d/00_header:

if [ "$quick_boot" = 1 ]; then
    [...]
    case "$FS" in
      btrfs | cpiofs | newc | odc | romfs | squash4 | tarfs | zfs)
    cat <<EOF
  # GRUB lacks write support for $FS, so recordfail support is disabled.
  [...]
  if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env recordfail; fi; fi

GRUB ignore correctement la fonction recordfail lors de l’utilisation de systèmes de fichiers non pris en charge (btrfs, zfs, etc.), mais ne saute pas le LVM et le RAID à tout moment .

Comment GRUB se protège-t-il contre l'écriture dans RAID et LVM?

Pour lire / écrire correctement dans un système de fichiers, GRUB charge un module approprié.

GRUB utilise le module diskfilter ( insmod diskfilter) dans les partitions RAID et le module lvm dans les partitions LVM.

Voyons l'implémentation en lecture / écriture du module diskfilter :

apt-get source grub2
vim grub2-2.02~beta2/grub-core/disk/diskfilter.c

Je colle le code ici (lignes 808 à 823). L'avertissement indiqué dans cette question apparaît à la ligne 821:

static grub_err_t
grub_diskfilter_read (grub_disk_t disk, grub_disk_addr_t sector,
                  grub_size_t size, char *buf)
{
  return read_lv (disk->data, sector, size, buf);
}

static grub_err_t
grub_diskfilter_write (grub_disk_t disk __attribute ((unused)),
             grub_disk_addr_t sector __attribute ((unused)),
             grub_size_t size __attribute ((unused)),
             const char *buf __attribute ((unused)))
{
  return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
                 "diskfilter writes are not supported");
}

La grub_diskfilter_readfonction est implémentée (et GRUB peut lire les systèmes de fichiers RAID). Cependant, la grub_diskfilter_writefonction génère une GRUB_ERR_NOT_IMPLEMENTED_YETerreur.

Pourquoi l'utilisation `quick_boot=0`résout-elle le problème? Et pourquoi est-ce la mauvaise solution?

Si vous regardez une fois de plus dans le /etc/grub.d/00_headercode, vous verrez que le recordfail présenté n'est utilisé que quand quick_boot=1. Ainsi, passer quick_bootde 1 à 0 désactive la fonctionnalité recordfail et désactive les écritures dans la partition RAID / LVM.

Cependant, il désactivera de nombreuses autres fonctionnalités (exécutez grep \$quick_boot /etc/grub.d/*et vous verrez). Plus encore, si un jour vous changez votre /boot/grubrépertoire en dehors du RAID / LVM, la fonction recordfail sera toujours désactivée.

En résumé, cette solution désactive inutilement les fonctionnalités, et ce n’est pas générique.

Quelle est la bonne solution?

La solution appropriée doit envisager de désactiver les save_envinstructions lorsque GRUB se trouve dans des partitions LVM ou RAID.

Un correctif a été proposé dans le système Debian Bug Tracker pour mettre en œuvre cette solution. Vous pouvez le trouver à l' adresse suivante : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754921.

L'idée derrière ce patch est:

Exécutez une grub-probe --target=abstraction "${grubdir}"commande pour obtenir le type de modules d'abstraction que GRUB utilise pour lire / écrire des fichiers dans le /boot/grubrépertoire.
Si GRUB utilise le module diskfilterou lvm, ignorez l' save_envinstruction recordfail et écrivez un commentaire approprié dans le /boot/grub/grub.cfgfichier;
- Par exemple, # GRUB lacks write support for /dev/md0, so recordfail support is disabled.

Comment appliquer la bonne solution?

Si vous ne voulez pas attendre que ce correctif soit appliqué par les gars d'Ubuntu / Debian dans le code officiel, vous pouvez utiliser mon correctif 00_header:

# Download
wget https://gist.githubusercontent.com/rarylson/da6b77ad6edde25529b2/raw/99f266a10e663e1829efc25eca6eddb9412c6fdc/00_header_patched
# Apply
mv /etc/grub.d/00_header /etc/grub.d/00_header.orig
mv 00_header_patched /etc/grub.d/00_header
# Disable the old script and enable the new one
chmod -x /etc/grub.d/00_header.orig
chmod +x /etc/grub.d/00_header
# Update Grub
update-grub

Rarylson Freitas
la source

Merci surtout pour la référence au bug. J'espère que vous comprendrez que j'ai trouvé la solution de Nux plus convaincante. ;)

Run CMD

Bonjour @ClassStacker, j'ai résumé la réponse! C'était très grand et il était très difficile à comprendre pour beaucoup de gens: p C'est encore grand, mais au moins je l'ai organisé en sections. Alors maintenant, vous ne pouvez regarder que dans les sections qui vous intéressent.

Rarylson Freitas

Sensationnel. Je vous remercie. S'il y avait une fonction "réponse du mois", je voterais pour le vôtre. En outre, vous méritez un prix "sans BS". C’est le genre d’articles qui apportent vraiment de la valeur et qui font une énorme différence entre ce réseau de sites et les forums.

Run CMD

Malheureusement, j'ai été affecté par ce bogue et aucune des corrections apportées dans le rapport de bogue ou ici en modifiant le 00_headerfichier n'a fonctionné. Je ne vais pas désactiver le quick_bootpour le faire partir.

Douggro

@douggro Je ne sais pas pourquoi le 00_headerfichier modifié (comme recommandé ici) ne fonctionne pas. Je sais que ce n'est pas parce que cela fonctionne pour moi (et pour Rarylson Freitas) que cela fonctionnerait nécessairement pour tout le monde. Mais avez-vous veillé à donner les autorisations appropriées à l'ancien et au nouveau 00_headeret à l'exécuter update-grub? (Si vous venez d'éditer 00_headersur place, rien chmodn'est requis, mais cela update-grubreste nécessaire.)

Eliah Kagan