As gravações do Diskfilter não são suportadas> O que aciona esse erro?

É um erro!

Este é um erro que ocorre na versão mais recente do Ubuntu Server LTS (Ubuntu Server 14.04 LTS), quando você cria a partição de inicialização (ou a partição raiz, quando a partição de inicialização não existe) dentro de uma partição LVM ou RAID .

Você pode obter mais informações sobre esse bug no Ubuntu Launchpad: Bug # 1274320 "Erro: gravações no diskfilter não são suportadas" .

Atualização: Este bug já foi corrigido no Ubuntu Server 14.04 e em algumas versões mais recentes do Ubuntu. Provavelmente, você só precisa executar apt-get upgrade.

Por que esse bug ocorre?

Quando o sistema está inicializando, o GRUB lê ( load_env) os dados /boot/grub/grubenv. Esse arquivo é chamado de bloco de ambiente do GRUB .

No manual do GRUB:

Muitas vezes, é útil poder lembrar uma pequena quantidade de informações de uma inicialização para a seguinte.

[...]

No momento da inicialização, o comando load_env (consulte load_env) carrega variáveis de ambiente e o comando save_env (consulte save_env) salva variáveis de ambiente nele.

[...]

grub-mkconfig usa esse recurso para implementar GRUB_SAVEDEFAULT

Esse comportamento pode ser encontrado em /etc/grub.d/00_header( update-grubusa esse arquivo para gerar o /boot/grub/grub.cfgarquivo):

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

O problema é que a save_envinstrução funciona apenas em instalações simples (você não pode executar save_envdentro de um disco RAID ou LVM). No manual do GRUB:

Por motivos de segurança, esse armazenamento está disponível apenas quando instalado em um disco simples (sem LVM ou RAID), usando um sistema de arquivos sem soma de verificação (sem ZFS) e usando funções BIOS ou EFI (sem ATA, USB ou IEEE1275).

O recurso de registro de falhas do GRUB usa a save_envinstrução para atualizar o estado de falha de registros (consulte a Ajuda do Ubuntu - Grub 2 , seção "Última inicialização falhada ou inicialização no modo de recuperação"). No entanto, no Ubuntu 14.04 (e nas versões recentes do Debian), a save_envinstrução (dentro do recurso recordfail) é usada mesmo se o GRUB estiver instalado em um LVM ou um RAID.

Vamos ver as linhas de 104 a 124 em /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

O GRUB ignora corretamente o recurso recordfail ao usar sistemas de arquivos não suportados (btrfs, zfs, etc), mas não ignora o LVM e o RAID a qualquer momento .

Como o GRUB se protege contra gravação dentro de RAID e LVM?

Para ler / gravar corretamente em um sistema de arquivos, o GRUB carrega um módulo apropriado.

O GRUB usa o módulo diskfilter ( insmod diskfilter) nas partições RAID e o módulo lvm nas partições LVM.

Vamos ver a implementação de leitura / gravação do módulo diskfilter :

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

Estou colando o código aqui (linhas de 808 a 823). O aviso mostrado nesta pergunta aparece na linha 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");
}

A grub_diskfilter_readfunção é implementada (e o GRUB pode ler sistemas de arquivos RAID). No entanto, a grub_diskfilter_writefunção gera um GRUB_ERR_NOT_IMPLEMENTED_YETerro.

Por que o uso `quick_boot=0`resolve o problema? E por que é a solução errada?

Se você olhar mais uma vez no /etc/grub.d/00_headercódigo, verá que o registro de falha em destaque é usado apenas quando quick_boot=1. Portanto, alterar quick_bootde 1 para 0 desativa o recurso de falha de registro e desativa gravações na partição RAID / LVM.

No entanto, também desabilitará muitos outros recursos (execute grep \$quick_boot /etc/grub.d/*e você verá). Mais ainda, se um dia você mudar seu /boot/grubdiretório para fora do RAID / LVM, o recurso recordfail continuará desativado.

Resumidamente, esta solução desativa desnecessariamente os recursos e não é genérica.

Qual é a solução correta?

A solução correta deve considerar desativar as save_envinstruções quando o GRUB estiver dentro de partições LVM ou RAID.

Um patch foi proposto no sistema Debian Bug Tracker para implementar esta solução. Pode ser encontrado em: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754921

A idéia por trás desse patch é:

Execute um grub-probe --target=abstraction "${grubdir}"comando para obter que tipo de módulos de abstração o GRUB usa para ler / gravar arquivos no /boot/grubdiretório;
Se o GRUB usar o módulo diskfilterou lvm, pule a save_envinstrução recordfail e escreva um comentário apropriado no /boot/grub/grub.cfgarquivo;
- Por exemplo, # GRUB lacks write support for /dev/md0, so recordfail support is disabled.

Como aplicar a solução correta?

Se você não quiser esperar que esse patch seja aplicado pelos caras do Ubuntu / Debian no código oficial, você pode usar o meu 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

Rarylson Freitas
fonte

Obrigado especialmente pela referência de bug. Espero que você entenda que eu achei a solução do nux mais atraente, no entanto. ;)

Execute o CMD

Olá @ClassStacker, resumi a resposta! Era muito grande e era muito difícil para muitas pessoas entenderem: p Ainda é grande, mas pelo menos eu organizei em seções. Então agora você pode procurar apenas nas seções de interesse.

Rarylson Freitas 31/07

Uau. Obrigado. Se houvesse um recurso "resposta do mês", eu votaria na sua. Além disso, você merece um prêmio "no BS". Esse é o tipo de artigo que realmente agrega valor e que faz uma enorme diferença entre a rede deste site em comparação com os fóruns.

Execute o CMD

Infelizmente, eu fui afetado por esse bug e nenhuma das correções no relatório de bug ou aqui editando o 00_headerarquivo funcionou. Não vou desativar o quick_bootpara fazê-lo desaparecer.

Douggro

@douggro Não sei por que o 00_headerarquivo editado (como recomendado aqui) não funcionaria. Eu sei que só porque funciona para mim (e para Rarylson Freitas) não significa que necessariamente funcionaria para todos. Mas você garantiu as permissões corretas para o antigo e o novo 00_headere para executar update-grub? (Se você acabou de editar 00_headerno lugar, não chmodé necessário, mas update-grubcontinua a ser necessário.)

Elias Kagan