Las escrituras de Diskfilter no son compatibles> ¿Qué desencadena este error?

Es un error!

Este es un error que ocurre en la versión más reciente de Ubuntu Server LTS (Ubuntu Server 14.04 LTS), cuando crea la partición de arranque (o la partición raíz, cuando la partición de arranque no existe) dentro de una partición LVM o RAID .

Puede obtener más información sobre este error en Ubuntu Launchpad: Error # 1274320 "Error: no se admiten las escrituras del filtro de disco" .

Actualización: Este error ya está solucionado en Ubuntu Server 14.04 y algunas versiones más nuevas de Ubuntu. Probablemente, solo necesitas correr apt-get upgrade.

¿Por qué ocurre este error?

Cuando el sistema se inicia, GRUB lee los load_envdatos ( ) /boot/grub/grubenv. Este archivo se llama GRUB Environment Block .

Del manual de GRUB:

A menudo es útil poder recordar una pequeña cantidad de información de un arranque a otro.

[...]

En el momento del arranque, el comando load_env (ver load_env) carga las variables de entorno, y el comando save_env (ver save_env) guarda las variables de entorno.

[...]

grub-mkconfig usa esta facilidad para implementar GRUB_SAVEDEFAULT

Este comportamiento puede fundarse en /etc/grub.d/00_header( update-grubutiliza este archivo para generar el /boot/grub/grub.cfgarchivo):

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

El problema es que la save_envdeclaración solo funciona en instalaciones simples (no puede ejecutarse save_envdentro de un disco RAID o LVM). Del manual de GRUB:

Por razones de seguridad, este almacenamiento solo está disponible cuando se instala en un disco plano (sin LVM o RAID), utilizando un sistema de archivos sin suma de comprobación (sin ZFS) y utilizando las funciones BIOS o EFI (sin ATA, USB o IEEE1275).

La función GRUB recordfail utiliza la save_envinstrucción para actualizar el estado recordfail (consulte la Ayuda de Ubuntu - Grub 2 , sección "Último arranque fallido o arranque en modo de recuperación"). Sin embargo, en Ubuntu 14.04 (y en versiones recientes de Debian), la save_envdeclaración (dentro de la función recordfail) se usa incluso si GRUB está instalado en un LVM o un RAID.

Veamos las líneas de 104 a 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 omite correctamente la función recordfail cuando usa sistemas de archivos no compatibles (btrfs, zfs, etc.), pero no omite LVM y RAID en ningún momento .

¿Cómo se protege GRUB de escribir dentro de RAID y LVM?

Para leer / escribir correctamente en un sistema de archivos, GRUB carga un módulo apropiado.

GRUB usa el módulo diskfilter ( insmod diskfilter) en particiones RAID y el módulo lvm en particiones LVM.

Veamos la implementación de lectura / escritura del módulo diskfilter :

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

Estoy pegando el código aquí (líneas de 808 a 823). La advertencia mostrada en esta pregunta aparece en la línea 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_readfunción está implementada (y GRUB puede leer sistemas de archivos RAID). Sin embargo, la grub_diskfilter_writefunción genera un GRUB_ERR_NOT_IMPLEMENTED_YETerror.

¿Por qué el uso `quick_boot=0`resuelve el problema? ¿Y por qué es la solución incorrecta?

Si busca una vez más en el /etc/grub.d/00_headercódigo, verá que el error de registro presentado solo se usa cuando quick_boot=1. Por lo tanto, cambiar quick_bootde 1 a 0 deshabilita la función recordfail y deshabilita las escrituras en la partición RAID / LVM.

Sin embargo, también deshabilitará muchas otras funciones (ejecute grep \$quick_boot /etc/grub.d/*y verá). Más aún, si un día cambia su /boot/grubdirectorio a fuera de RAID / LVM, la función de falla de registro seguirá deshabilitada.

En resumen, esta solución deshabilita innecesariamente las características y no es genérica.

¿Cuál es la solución correcta?

La solución correcta debería considerar deshabilitar las save_envdeclaraciones cuando GRUB está dentro de particiones LVM o RAID.

Se propuso un parche en el sistema Debian Bug Tracker para implementar esta solución. Se puede encontrar en: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754921

La idea detrás de este parche es:

Ejecute un grub-probe --target=abstraction "${grubdir}"comando para obtener qué tipo de módulos de abstracción utiliza GRUB para leer / escribir archivos en el /boot/grubdirectorio;
Si GRUB usa el módulo diskfiltero lvm, omita la save_envinstrucción recordfail y escriba un comentario apropiado en el /boot/grub/grub.cfgarchivo;
- Por ejemplo, # GRUB lacks write support for /dev/md0, so recordfail support is disabled.

¿Cómo aplicar la solución correcta?

Si no desea esperar a que los chicos de Ubuntu / Debian apliquen este parche en el código oficial, puede usar mi parche 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
fuente

Gracias especialmente por la referencia del error. Sin embargo, espero que entiendan que la solución de Nux me pareció más convincente. ;)

Ejecute CMD

Hola @ClassStacker, resumí la respuesta. Era muy grande y era muy difícil de entender para muchas personas: p Todavía es grande, pero al menos lo organicé en secciones. Así que ahora solo puede mirar en las secciones de interés.

Rarylson Freitas

Guau. Gracias. Si hubiera una función de "respuesta del mes", votaría por la suya. Además, usted merece un premio "sin BS". Este es el tipo de artículos que realmente proporcionan valor y que marcan una gran diferencia entre la red de este sitio en comparación con los foros.

Ejecute CMD el

Lamentablemente, he sido afectado por este error y ninguna de las correcciones en el informe de errores o aquí al editar el 00_headerarchivo ha funcionado. No deshabilitaré quick_bootpara que desaparezca.

douggro

@douggro No estoy seguro de por qué el 00_headerarchivo editado (como se recomienda aquí) no funcionaría. Sé que solo porque funciona para mí (y para Rarylson Freitas) no significa que necesariamente funcione para todos. Pero, ¿se aseguró de otorgar los permisos correctos a lo viejo y lo nuevo 00_headery a ejecutar update-grub? (Si acaba de editar 00_headeren su lugar, no chmodse requiere, pero update-grubsigue siendo necesario).

Eliah Kagan