Question Diskfilter écrit pas pris en charge> Qu'est-ce qui déclenche cette erreur?


Ce message se produit lorsque vous quittez le menu Grub et avant l'écran de démarrage Ubuntu.

Comment résoudre le problème pour effacer le message?

Et qu'est-ce que ça veut dire?

error:  Diskfilter writes are not supported

Le système démarre et semble fonctionner correctement.


86
2018-05-17 23:14


origine


Toujours pas corrigé dans Ubuntu Desktop 15.04 ... - ThePiercingPrince
Toujours pas corrigé dans 16.04. Ce rythme effréné de correction de bogues est difficile à suivre. - Paul Tomblin


Réponses:


C'est un BUG!

Ceci est un bogue qui se produit 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: Bogue n ° 1274320 "Erreur: les écritures diskfilter ne sont pas prises en charge".

Mettre à jour: Ce bogue est déjà corrigé dans Ubuntu Server 14.04 et dans certaines versions plus récentes d'Ubuntu. Probablement, vous avez seulement besoin de courir apt-get upgrade.

Pourquoi ce bug se produit-il?

Lors du démarrage du système, GRUB lit (load_env) données en /boot/grub/grubenv. Ce fichier s'appelle Bloc d'environnement GRUB.

Du manuel GRUB:

Il est souvent utile de pouvoir mémoriser 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 et la commande save_env (voir save_env) enregistre les variables d'environnement.

[...]

grub-mkconfig utilise cette facilité pour mettre en œuvre GRUB_SAVEDEFAULT

Ce comportement peut être fondé sur /etc/grub.d/00_header (update-grub utilise ce fichier pour générer le /boot/grub/grub.cfg fichier):

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

Le problème est que le save_env déclaration ne fonctionne que dans des installations simples (vous ne pouvez pas exécuter save_env à l'intérieur d'un disque RAID ou LVM). A partir du manuel GRUB:

Pour des raisons de sécurité, ce stockage n'est disponible que s'il est installé sur un disque ordinaire (pas de LVM ou RAID), utilisant un système de fichiers sans contrôle (sans ZFS) et utilisant des fonctions BIOS ou EFI (pas d'ATA, USB ou IEEE1275).

Le GRUB recordfail fonctionnalité utilise le save_env déclaration pour mettre à jour l'état d'enregistrement (voir Aide Ubuntu - Grub 2, Section "Dernier échec ou démarrage du mode de récupération"). Cependant, dans Ubuntu 14.04 (et dans les versions récentes de Debian), le save_env L'instruction (à 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 en /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 il ne saute pas LVM et 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 filtre de disque module (insmod diskfilter) dans les partitions RAID, et le lvm module dans les partitions LVM.

Voyons l'implémentation en lecture / écriture du filtre de disque module:

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

Je colle le code ici (lignes de 808 à 823). L'avertissement affiché 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");
}

le grub_diskfilter_read la fonction est implémentée (et GRUB peut lire les systèmes de fichiers RAID). Cependant, le grub_diskfilter_writela fonction soulève un GRUB_ERR_NOT_IMPLEMENTED_YET Erreur.

Pourquoi utiliser quick_boot=0 résoudre le problème? Et pourquoi est-ce la mauvaise solution?

Si vous regardez encore une fois dans le /etc/grub.d/00_header code, vous verrez que le recordfail présenté n'est utilisé que lorsque quick_boot=1. Donc, changer quick_boot de 1 à 0 désactive la fonction recordfail et désactive les écritures dans la partition RAID / LVM.

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

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

Quelle est la solution correcte?

La bonne solution devrait envisager de désactiver le save_env instructions lorsque GRUB se trouve dans des partitions LVM ou RAID.

Un patch a été proposé dans le système Debian Bug Tracker pour implémenter cette solution. On peut le trouver dans: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754921

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

  • Exécuter un grub-probe --target=abstraction "${grubdir}" commande pour obtenir quel type de modules d'abstraction GRUB utilise pour lire / écrire des fichiers dans le /boot/grub annuaire;
  • Si GRUB utilise le diskfilter ou lvm module, ignore le recordfail save_env déclaration et écrire un commentaire approprié dans le /boot/grub/grub.cfg fichier;
    • Par exemple, # GRUB lacks write support for /dev/md0, so recordfail support is disabled.

Comment appliquer la solution correcte?

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 patch 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

143
2017-07-15 22:42



Merci surtout pour la référence au bug. J'espère que vous comprendrez que j'ai trouvé solution nux ' plus convaincant, cependant. ;) - Run CMD
Salut @ClassStacker, j'ai résumé la réponse! C'était très grand et c'était très difficile à comprendre pour beaucoup de personnes: 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 fonctionnalité "réponse du mois", je voterais pour la vôtre. En outre, vous méritez un prix «sans BS». C'est le genre d'articles qui apportent une réelle valeur ajoutée et qui font la différence entre ce réseau de sites et les forums. - Run CMD
Malheureusement, j'ai été affecté par ce bogue et aucun des correctifs dans le rapport de bogue ou ici en éditant le 00_header fichier a fonctionné. Je ne vais pas désactiver le quick_boot pour le faire partir. - douggro
@douggro Je ne sais pas pourquoi la version modifiée 00_header fichier (comme recommandé ici) ne fonctionnerait pas. Je sais que le fait que cela fonctionne pour moi (et pour Rarylson Freitas) ne signifie pas nécessairement que cela fonctionnera pour tout le monde. Mais avez-vous veillé à donner les bonnes autorisations à l'ancien et au nouveau 00_headeret courir update-grub? (Si vous venez de modifier 00_header en place, non chmod est requis, mais update-grub reste nécessaire.) - Eliah Kagan


Je pense que cette erreur se produit à cause de raid ou LVM cloison .

Pour une solution temporaire à ce problème:

Modifier :/etc/grub.d/10_linux 

Remplacer 'quick_boot="1"' with 'quick_boot="0"'

Alors :

sudo update-grub

33
2018-05-18 00:14



Merci, cela a parfaitement fonctionné. Oui, j'utilise LVM pour tous les volumes. - RCF
Merci pour cette solution. Cela m'a sauvé beaucoup de travail. Avez-vous un peu d’information de base également? - Run CMD
@ClassStacker si vous demandez plus d'informations à partir de nux, vous devez modifier votre commentaire pour commencer (@nux). Si vous me demandez quel type de fonds recherchez-vous? - RCF
@ RCF-U14.04 1) Non, je n'ai pas à le faire. Cliquez simplement sur "ajouter un commentaire" -> "aide" pour apprendre que "l'auteur du message sera toujours informé de votre commentaire". 2) Je voulais savoir (de nux) pourquoi cela résout le problème, en particulier compte tenu de la réponse complète de Rarylson Freitas. Mais si vous pouvez y répondre, n'hésitez pas à le faire. - Run CMD