Posso limpar com segurança kernels assinados com EFI? (alternativamente, posso me livrar de kernels não assinados?)

Question

Posso desinstalar e remover com segurança os pacotes linux-signed* da minha instalação do Ubuntu 16.10 (yakkety)?

O motivo pelo qual estou considerando isso é que meu BIOS UEFI não usa inicialização segura e minha partição de inicialização é de apenas 200 MiB (~ 210 MB). Eu tenho criptografia no restante das partições e realmente não quero redimensioná-las para expandir a partição de inicialização.

Infelizmente, 200 MiB é um pouco pequeno demais para conter 3 kernels. Os kernels atuais chegam a cerca de 61 MiB cada (incluindo o abi, config, initrd, map, além de binários do kernel assinados e não assinados). Adicionando o grub, memtest e a tabela de partições empurra-o para cerca de 198, o que aparentemente não é suficiente espaço livre para atualizar o kernel. Eu normalmente mantenho apenas 2 kernels (current + last), mas obviamente eu preciso de espaço para um terceiro durante o processo de atualização. Se eu não tivesse os kernels assinados (7,2 MiB cada), eu estaria bem.

A partir de hoje, eu construí as versões 41, 45 e 46 do kernel 4.8.0 instaladas.

O seguinte quebrará meu sistema?

apt-get purge linux-signed*
grub-mkconfig -o /boot/grub/grub.cfg

(segunda linha adicionada após o comentário de ubfan1, veja abaixo)

Acredito que ele deve remover os seguintes pacotes do kernel e impedir que novos kernels assinados sejam instalados:

linux-signed-generic
linux-signed-image-4.8.0-41-generic
linux-signed-image-4.8.0-45-generic
linux-signed-image-4.8.0-46-generic
linux-signed-image-generic

Eu tenho todas as versões regulares (não assinadas) desses pacotes instaladas.

Como pergunta secundária, alguém sabe por que o arquivo unicode.pf2 (2.3 MiB) aparece em /boot/grub e /boot/grub/fonts ? Eu divisei os arquivos e eles são exatamente os mesmos. Eu suponho que esta é a fonte usada no menu do grub, mas por que ela aparece duas vezes na mesma partição? Eu me sinto bobo brigando por 2,3 MiB, mas isso também pode fazer uma enorme diferença no meu caso particular.

Obrigado!

informações adicionadas para o comentário de ubfan1

Os kernels .efi.signed aparecem em todas as entradas do menu em /boot/grub/grub.cfg . Eu sei que o meu firmware uefi (eu acho que bios não é o termo certo mais) não usa boot seguro, mas os arquivos de configuração do grub parecem pensar que ele faz. Obviamente, meu sistema inicializa bem os kernels assinados, então talvez eu possa limpar os kernels unsigned ?

Eu procurei /etc/grub.d/10_linux para descobrir de onde essas linhas vêm e encontrei o seguinte código:

if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then
    sed "s/^/$submenu_indentation/" << EOF
    linux   ${rel_dirname}/${basename}.efi.signed
      root=${linux_root_device_thisversion} ro ${args}
EOF
  else
    sed "s/^/$submenu_indentation/" << EOF
    linux   ${rel_dirname}/${basename}
      root=${linux_root_device_thisversion} ro ${args}
EOF
  fi

Eu não sou especialista em bash, mas acho que eu sigo isso no pseudo código

if /sys/firmware/efi AND /boot/vmlinuz-x.x.x-xx.efi.signed exist
  echo linux vmlinuz-x.x-xx-generic.efi.signed to /boot/grub/grub.cfg
else
  echo linux vmlinuz-x.x.x-xx-generic to /boot/grub/grub.cfg

então, se eu limpar os pacotes do kernel assinados, então execute novamente o grub-mkconfig , ele deve colocar os kernels regulares não assinados em grub.cfg , certo?

    

Answer 1

Obrigado por toda a ajuda e links. Passei algumas horas neste fim de semana e verifiquei o seguinte

Respostas curtas

1. Sim, você pode limpar todos os pacotes linux-signed* , mas você precisa instalar linux-generic se quiser que as atualizações automáticas do kernel continuem funcionando adequadamente. Todas as reconfigurações do grub, kernel e initramfs são tratadas automaticamente. Os scripts de instalação do kernel realmente lidam com tudo sem problemas.

   apt-get purge linux-signed* linux-generic+

2. Sim, você pode se livrar dos kernels não assinados sem nenhum efeito negativo, mas eles continuarão retornando após as atualizações do kernel. Isso não pode ser resolvido com o gerenciamento de pacotes, mas é fácil de corrigir com um script curto.

    

   #!/bin/sh
   #
   # user script: 
   /etc/kernel/postinst.d/zzz-remove-unsigned-kernel
   #
   # after a new signed kernel image is installed, this script removes
   # the unsigned image
   #
   if [ -e ".efi.signed" ]; then
       echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing "
       rm "";
   fi
   

Respostas mais longas

No primeiro caso, a solução é muito simples. Funciona da mesma forma que você imaginaria à primeira vista. Ainda aprendi algumas coisas úteis sobre a estrutura de pacotes do Ubuntu para os kernels. Eu queria ter certeza de que entendi os efeitos colaterais ou consequências, mas também gosto de ver como as coisas são construídas. Apenas como uma nota lateral, eu uso o kernel genérico, mas basta trocar generic por lowlatency ou virtual se isso for sua coisa. Além disso, tudo aqui é baseado em 16.10 (yakkety). Aqui está a hierarquia do pacote do kernel:

• linux-signed-generic é um pacote , o que significa que não inclui nenhum código. Apenas tem uma lista de dependências, que sempre contém a instalação completa da mais nova atualização do kernel. "Completo" significa todos os cabeçalhos do kernel, a imagem do kernel, a assinatura da imagem (separada) e módulos extras do kernel para praticamente todos os dispositivos que o Ubuntu pode suportar.

• linux-generic é outro pacote meta contendo todos os mesmos pacotes reais, exceto pela assinatura da imagem. A imagem real do kernel é somente contida no pacote linux-image-x.x.x-yy . O pacote linux-signed-image-x.x.x-yy contém apenas uma assinatura separada e o script de construção anexa esse sig a /boot/vmlinuz-x.x.x.yy-generic e cria /boot/vmlinuz-x.x.x.yy-generic.efi.signed . O script não limpa a imagem não assinada.

• Os pacotes de kernel têm scripts especiais em /etc/kernel que modificam o comportamento padrão do autoremove do apt. Normalmente, remover linux-signed-generic sinalizaria todos os pacotes downstream para autoremoval, mas isso não acontece para os pacotes do kernel até que haja duas versões mais recentes da mesma versão.

No segundo caso (tentando manter apenas a imagem do kernel assinada), parece não haver consequências para a exclusão de /boot/vmlinuz-x.x.x.yy-generic após a conclusão da instalação. As duas imagens do kernel são exatamente as mesmas, exceto pela assinatura, e compartilham todos os mesmos módulos e arquivos de configuração. No entanto, assim que um kernel atualizado for instalado, ele deixará a imagem não assinada. Felizmente, houve ganchos fáceis para executar um script toda vez que um novo kernel é instalado. Todos os scripts em /etc/kernel/postinst.d são executados por run-parts com dois argumentos é a versão do kernel e é o caminho completo da imagem (por exemplo, /boot/vmlinuz-x.x.x-yy-generic )

A única ressalva secundária é que a remoção da imagem não assinada deve ser feita depois que o grub terminar de atualizar grub.cfg . Se /boot/vmlinuz-x.x.x-yy-generic.efi.signed existir, o grub adicionará essa imagem a grub.cfg e ignorará a imagem não assinada. No entanto, deve haver algum lugar no processo que ainda espere a imagem não assinada porque o grub não consegue configurar corretamente sem ela. O script que inicia a configuração do grub é /etc/kernel/postinst.d/zz-update-grub . Eu nomeei meu script zzz-remove-unsigned-kernel para que run-parts o execute depois que tudo estiver concluído.

EDIT: Eu usei este script agora com algumas atualizações de compilação do kernel, e tudo parece funcionar bem. Eu estou usando a opção 2 acima (excluindo kernels não assinados). Vou marcar isso como a resposta correta.

    

Answer 2

AFAIK, os kernels .efi.signed são iguais aos kernels normais, exceto pelo fato de estarem assinados com a chave EFI Secure Boot da Canonical. Assim, se você não estiver inicializando com o Secure Boot ativo, poderá excluir com segurança os .efi.signed kernels. Se eu estiver analisando as informações do pacote corretamente, você poderá excluir os pacotes linux-signed-image-generic e linux-signed-generic para evitar que atualizações futuras dos kernels assinados também sejam instaladas.

Dito isso, uma solução melhor a longo prazo é aumentar o tamanho da sua partição /boot . Isso pode ser uma dor e até mesmo arriscado para os seus dados, especialmente se você usar o LVM ou software RAID; no entanto, os detalhes dependem muito do layout atual do disco e dos planos para alterar esse layout por outros motivos. Observe que, dependendo do layout, talvez seja preferível reduzir uma partição de dados a partir do final e criar uma partição /boot maior depois dessa partição de dados encolhida do que tentar encolher uma partição de dados desde o início, a fim de torná-la espaço para a partição /boot crescer.

Por fim, se você estiver desesperado o suficiente para liberar alguns megabytes para ver arquivos duplicados na árvore de diretórios /boot/grub , talvez considere abandonar o GRUB completamente. A maioria dos outros carregadores de boot não exige tanto em termos de arquivos em /boot como o GRUB faz. Se você está inicializando no modo EFI, meu próprio gerenciador de inicialização do rEFInd provavelmente será o mais fácil de instalar, e Você pode experimentá-lo em uma unidade USB ou CD-R para ver como é antes de usar o disco rígido. Se você está inicializando no modo BIOS, o LILO, o SYSLINUX e até mesmo o GRUB Legacy são todas opções, mas eu não tenho instruções sobre como instalar qualquer um deles, de improviso.

    

Answer 3

Os kernels ..signed são um pouco maiores, portanto, se você não estiver executando com inicialização segura ativada e estiver tentando economizar espaço, use o unsigned e purgar o assinado. Eu também acho que sua abordagem com a reconstrução do grub funcionará. Se você perder energia antes da reconstrução do grub.cfg, sempre poderá editar o menu antigo do grub e excluir a parte assinada. É claro, você pode deixar uma versão assinada (a mais recente) e se livrar das outras para ver se as coisas funcionam como esperado, e então fazer novamente para a última, nunca deixando você sem uma configuração inicializável conhecida.   Quanto aos arquivos unicode.pf2 - eles também existem no meu sistema. Você poderia tentar substituir um com um link para o outro (com a mídia de inicialização à mão caso você precise colocar o arquivo de volta onde está o link).