Início / ubuntu / Perguntas / 1527552
Accepted
Youkko
Asked: 2024-09-21 09:20:51 +0800 CST

Executar apt dist-upgrade antes de do-release-upgrade (de 20.04.6 a 22.04.5) quebra a VM do Digital Ocean

  • 772

Estou tentando atualizar uma VM Ubuntu da Digital Ocean de 20.04.6 para 22.04.5 usando do-release-upgrade. Estou conectado via SSH.

Infelizmente, isso não é direto e está me pedindo para instalar todas as atualizações disponíveis antes de atualizar.

Antes de começar, criei um snapshot para recuperar rapidamente caso algo desse errado.

Ao seguir as instruções deste fórum , ele me sugere executar sudo apt full-upgrade. Após executá-lo e reinicializar, a máquina recusa a conexão (o que significa que entrou em um estado em que não está inicializando). Ele não conecta nem mesmo do console da Digital Ocean dentro do painel de controle, muito menos por SSH.

Após restaurar o snapshot, tentei seguir as instruções deste post . Após executar sudo apt-get dist-upgrade, tive o mesmo problema após reiniciar.

Tentar executar sudo do-release-upgradesem reinicializar faria com que a atualização fosse baixada e instalada, mas a máquina ficaria ininicializável no final de qualquer maneira.

Então, o que estou perdendo aqui? Alguma dica?

[ATUALIZAR]

Consegui instalar todas as atualizações necessárias executando sudo apt list --upgradablee instalando cada uma manualmente com o sudo apt-get install, enquanto aplicava autoremovequando necessário. Agora meu sistema está totalmente atualizado. Mas ao executar o sudo do-release-upgrade, após terminar um longo processo de atualização, o sistema foi tornado não inicializável. Até tentei desligar o droplet e ligá-lo novamente, mas não obtive sucesso em colocá-lo online. Restaurarei o snapshot e tentarei investigar mais a fundo.

upgrade

1 respostas

  1. Best Answer

    Depois de muitas horas de pesquisa, finalmente descobri o culpado e a solução. O problema na atualização é que o 22.04 usa netplan, mas os droplets do 20.04 não têm nenhum arquivo de configuração netplan (pelo menos o meu não tem). Então, depois de reiniciar, a máquina não pode ser acessada porque sua configuração de rede desapareceu.

    Para resolver esse problema, após executar sudo do-release-upgrade, quando terminar, responda NÃO quando for solicitado um reboot . Então obtenha suas informações de rede executando:

    • ip apara recuperar endereços
      • A saída esperada é algo como:
      1: lo: mtu 65536 qdisc noqueue estado DESCONHECIDO grupo padrão qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 escopo host lo
     valid_lft para sempre preferred_lft para sempre
  inet6 ::host de escopo 1/128
     valid_lft para sempre preferred_lft para sempre
2: eth0: mtu 1500 qdisc fq_codel estado UP grupo padrão qlen 1000
  link/éter aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
  inet xxx.xxx.xxx.xxx/xx brd ***.***.***.*** escopo global eth0
     valid_lft para sempre preferred_lft para sempre
  inet aaaa.aaaa.aaaa.aaaa/aaaa brd ***.***.***.*** escopo global eth0
     valid_lft para sempre preferred_lft para sempre
  inet6 zzzz:zzzz:zzzz:zzzz:zzzz:zzzz:zzzz/zz escopo global
     valid_lft para sempre preferred_lft para sempre
  inet6 aaaa:bbbb:cccc:dddd:eeee:ffff/af link de escopo
     valid_lft para sempre preferred_lft para sempre
    • ip rpara recuperar rotas
      • A saída esperada é algo como:
      padrão via ccc.ccc.ccc.ccc dev eth0 proto estático
ddd.ddd.ddd.ddd/dd dev eth0 proto kernel escopo link src aaaa.aaaa.aaaa.aaaa
eee.eee.eee.eee/ee dev eth0 proto kernel escopo link src xxx.xxx.xxx.xxx
    • cat /etc/resolv.confpara obter a configuração do servidor de nomes.
      servidor de nomes nnn.nnn.nnn.nnn
opções edns0 trust-ad
procurar .

    Anote essas saídas e crie um arquivo de configuração netplan executando sudo nano /etc/netplan/config.yamle escrevendo o seguinte conteúdo, substituindo as entradas correspondentes pelas que você anotou antes (e para facilitar as coisas, alterei os valores da saída com letras para que você possa ver onde cada entrada deve ir):

    rede:
  versão: 2
  ethernet:
    eth0:
      endereços:
      - xxx.xxx.xxx.xxx/xx
      -zzzz:zzzz:zzzz:zzzz:zzzz:zzzz:zzzz/zz
      - aaaa.aaaa.aaaa.aaaa/aaaa
      rotas:
      - para: padrão
        via: ccc.ccc.ccc.ccc
      - para: padrão
        via:zzzz:zzzz:zzzz:zzzz:zzzz:zzzz:zzzz
      corresponder:
        endereço de maca: aa:aa:aa:aa:aa:aa
      servidores de nomes:
        endereços:
        - nnn.nnn.nnn.nnn
        - 2001:4860:4860::8844
        - 2001:4860:4860::8888
        - 8.8.8.8
      nome do conjunto: eth0

    Observe também que o recuo do conteúdo yaml deve corresponder exatamente ao acima, ou você receberá um erro.

    Altere a permissão do arquivo recém-criado com sudo chmod 600 /etc/netplan/config.yaml.

    Agora, execute sudo netplan --debug generate. Se você receber uma mensagem com algo como WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running. , você pode resolver isso executando sudo apt-get install openvswitch-switch-dpdk, mas acho que você pode ignorar essa mensagem. Eu não ignorei, só por precaução.

    Por fim, execute sudo netplan applye reinicie. Note que se você tiver qualquer chave SSH definida, você precisará reconfigurá-la, já que a assinatura será alterada.

    Note que se você for para a pasta /etc/netplan/ , você notará que já há um arquivo lá, chamado 50-cloud-init.yaml . Não faça como eu fiz e edite esse arquivo com o conteúdo acima, porque o conteúdo desse arquivo não persiste após uma reinicialização e é gerado automaticamente, e eu descobri quando fui bloqueado do droplet e tive que acessá-lo através do console de recuperação do painel de controle do Digital Ocean para criar o config.yaml, etc.

    Espero realmente que isso ajude quem ficou preso nisso e que isso possa lhe poupar horas de pesquisa e dor de cabeça.

    • 1

relate perguntas