"Uma nova versão do /boot/grub/menu.lst está disponível" ao atualizar o Ubuntu em um servidor da AWS
Eu apenas tentei fazer um sudo do_release_upgradeem um servidor AWS EC2 Ubuntu 13.10 para atualizar para 14.04. Tudo estava indo bem até eu receber a seguinte mensagem:
Eu certamente não tem modificações menu.lst, então eu assumir as modificações locais são Amazon está fazendo. Vou clicar na opção "manter a versão local atualmente instalada" e esperar o melhor.
Mas por que estou recebendo essa mensagem e essa é a maneira correta de lidar com isso?
verifique isso unix.stackexchange.com/questions/113732/…
— Federico Sierra
Esse problema pode ser causado por vários problemas diferentes, portanto não há uma solução única. Essas etapas devem funcionar no EC2.
O problema é causado por um conflito de alterações local e remoto na configuração herdada do Grub . O Grub legado e o Grub2 usam diferentes locais de configuração:
Legado do Grub: /boot/grub/menu.lst
Você provavelmente está usando uma AMI suportada pelo Amazon EBS. As instâncias constroem seu sistema de arquivos raiz a partir de uma imagem base pré-criada (instantâneo). A configuração do grub é gravada no instantâneo, mas o registro UCF não é removido corretamente. Isso significa que você tem um instantâneo que acha que a menu.lstconfiguração foi modificada localmente. Mais informações podem ser encontradas aqui: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1485685
Por que o ubuntu usa UCF para grub é explicado aqui: https://askubuntu.com/a/147079
Solução (s):
Uma solução geral que funciona é remover o menu.list e reconfigurá-lo. Isso garante que a entrada do registro ucf e o arquivo de configuração sejam resolvidos com o mesmo hash.
Uma segunda solução é modificar a configuração do UCF para aceitar automaticamente as alterações do mantenedor
Esse problema é muito amplo e os casos de uso afetarão a solução necessária. Se possível, é altamente recomendável atualizar para o grub2. O Grub2 pode ser configurado sem modificar os arquivos do sistema.
Há também uma tonelada de soluções diferentes oferecidas e relatórios de problemas abertos no rastreador do ubuntu. Eu adoraria vincular a todos eles, mas não tenho o representante.
— Menzo Wijmenga
ubuntu 18.04 vendo W: --force-yes está obsoleto, use uma das opções iniciadas por --allow.
É 2019 e esta solução não funciona (mais). Parece que o bug regrediu mais uma vez, veja: bugs.launchpad.net/cloud-images/+bug/1747464
Minha versão desta pergunta é: "Eu tenho atualizações automáticas do kernel no ec2, e fiz recentemente apt-get autoremove -y. Mesmo depois de sudo update-grubver apenas a 3.13.0-48lista, /boot/grub/menu.lstmas não entre os kernels instalados. Como estou ferrado?"
Minha resposta: "Provavelmente não está ferrado. Em outros sistemas Ubuntu. menu.lstNem existe e update-grubparece estar colocando a configuração /boot/grub/grub.cfg. Meu palpite é que esse menu.lsté um artefato estranho da Ubuntu AMI do EC2, ou alguma interação com o empacotamento ou o gerenciamento de configuração local. "
Pessoalmente, em seu lugar, eu "mostraria a diferença entre versões", anotaria cuidadosamente quais são as alterações e depois experimentaria as novas diferenças em uma instância da AWS de "desenvolvimento". Se eu estivesse sendo extremamente cauteloso, simplesmente leria a página de manual para as alterações em questão (elas podem não ser para menu.lst, mas algum outro software como o kernel, ou heck, qualquer coisa realmente) para descobrir exatamente o que está mudando .
Como alternativa, você pode clonar esta máquina virtual, fazer a atualização, ver o que acontece e, se isso falhar, você arma a nova VM e inicia o processo novamente com uma opção diferente. Máquinas virtuais são ótimas apenas por esse motivo.
Acabei de encontrar o mesmo "problema" com um VPS da OVH.
No meu caso (e muitos outros que encontrei no Google), as únicas alterações foram os espaços em branco.
De onde eles vêm, eu não sei, mas se você selecionar show the differences between the versionse a resposta é No non whitespace changes detectedapenas pegar a versão dos mantenedores.
— SleepProgger
mostra as diferenças entre as versões
instale a versão do mantenedor do pacote
mantenha a versão local atualmente instalada
De qualquer forma, agora você pode correr
— Imya
-1; isso não responde à pergunta (na verdade, na maioria das vezes, apenas repete partes da mensagem que eu já citei), nem explica por que eu gostaria de executar o código fornecido ou o que ele fará.
A incompatibilidade de hash dos arquivos causa mensagem com opções. Você deve encontrar diferenças entre eles para escolher a opção correta. "whatis ls diff" imprime a descrição dos comandos.
— 21717 Imya
"Incompatibilidade de hash de arquivos causa mensagem com opções" - Sim, eu posso ler. Minha pergunta é por que essas diferenças existem nas instâncias do EC2 e quais serão as consequências de mantê-las ou descartá-las. Sua resposta não resolve isso, apenas repete o que está impresso na mensagem. Sua resposta nem menciona Amazon ou EC2; não é relevante para a pergunta que foi feita.
Oh, boi, ainda não forneceu conteúdo dos arquivos e espera que os outros descubram o que está acontecendo em seu sistema.
Não é "meu sistema". Estou perguntando sobre o comportamento padrão da instalação do EC2 em uma pergunta sobre o EC2 e marcada com a tag EC2. Claro, decidi não despejar o conteúdo completo do arquivo na pergunta, porque não é necessário que a pergunta seja entendida e respondida; quem usa o Ubuntu no EC2 é capaz de verificar seu conteúdo, se quiser investigar o problema. Não vejo por que seria esperado que eu fornecesse a fonte do arquivo aqui mais do que despejaria o código-fonte de uma biblioteca popular em uma pergunta do Stack Overflow antes de perguntar sobre isso.