OK, depois de um pouco de vasculhar, encontrei uma maneira de se livrar desse problema, pelo menos temporariamente, é bastante simples, no entanto, não tenho meu sistema configurado com btrfs, portanto não posso confirmar essa correção.
comente ou remova esta linha:
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
ou
if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env \
recordfail; fi; fi
neste arquivo
/etc/grub.d/00_header
então corra
update-grub
o motivo para não editar /boot/grub/grub.cfg
diretamente é que ele será sobrescrito toda vez que o grub for atualizado. Nesse caso, você só precisará "refazer" a correção se os pacotes comuns do grub forem atualizados.
Este é o bug na barra de ativação, se você deseja adicionar o bug # 736743
Citando Colin Watson no relatório de erros
Esta é realmente uma mensagem de erro enganosa: o que está acontecendo é que a implementação btrfs do GRUB não implementa a interface do gancho de leitura de arquivo para retornar as listas de bloqueio ao código de chamada. Publiquei no grub-devel sobre isso e o mantenedor do upstream apontou que, além de problemas com vários dispositivos, gravar btrfs no GRUB é fundamentalmente arriscado, porque:
o mesmo bloco pode ser usado por vários instantâneos, cada árvore que usa um determinado bloco conterá sua soma de verificação e assim por diante recursivamente
No entanto, o btrfs reserva espaço no início para o carregador de inicialização. Esse espaço é mais do que o GRUB precisa se incorporar e, portanto, poderíamos usar 1 KB dele para um bloco de ambiente.
De qualquer forma, esse não é um problema novo que surgiu do uso de subvolumes, nem impede a inicialização (você recebe um aviso espúrio de "Pressione qualquer tecla para continuar", mas se você ignorá-lo, será inicializado de qualquer maneira). Fazendo o downgrade para a lista de desejos.
Espero que isto ajude