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=0resuelve 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