Server 22.04.1 subiquity autoinstall - o comando system-install falha após alterar o nome da NIC usando netplan

Question 1

Eu gosto de configurar redes usando late-commands.

#cloud-config
autoinstall:
  late-commands:
    - |
      rm /target/etc/netplan/00-installer-config.yaml
      cat <<EOF > /target/etc/netplan/80-my.yaml
      network:
        ethernets:
          ens18:
            match:
              driver: e1000
            dhcp4: true
            set-name: eth0
        version: 2
      EOF

como funciona

Se não houver nenhum networkbloco de configuração em seu user-dataarquivo, o instalador (subiquidade) vaiuse uma configuração netplan genérica. Mais tarde,subiquidadeirá gerar uma configuração netplan para o sistema instalado e também irá utilizá-la para o ambiente do instalador. Em late-commandsvocê pode excluir osubiquidadeconfiguração gerada e substitua-a pelo que você quiser. Isso afetará apenas o sistema instalado.

links

Answer

Eu gosto de configurar redes usando late-commands.

#cloud-config
autoinstall:
  late-commands:
    - |
      rm /target/etc/netplan/00-installer-config.yaml
      cat <<EOF > /target/etc/netplan/80-my.yaml
      network:
        ethernets:
          ens18:
            match:
              driver: e1000
            dhcp4: true
            set-name: eth0
        version: 2
      EOF

como funciona

Se não houver nenhum networkbloco de configuração em seu user-dataarquivo, o instalador (subiquidade) vaiuse uma configuração netplan genérica. Mais tarde,subiquidadeirá gerar uma configuração netplan para o sistema instalado e também irá utilizá-la para o ambiente do instalador. Em late-commandsvocê pode excluir osubiquidadeconfiguração gerada e substitua-a pelo que você quiser. Isso afetará apenas o sistema instalado.

links

Question 2

Eu gostaria de adicionar mais algumas informações para qualquer pessoa que possa ter problemas semelhantes. Minha postagem principal está incorreta em algumas áreas, agora que resolvi meus problemas e sei o que estava errado.

Em primeiro lugar, a resposta de Andrew resolverá o problema questionado na postagem. Mas descobri por que meu cloud-init não estava começando com a ajuda de sua postagem.

Algo nos logs de inicialização da nuvem que eu estava olhando originalmente me levou a pensar que a NIC não poderia ser renomeada com a inicialização da nuvem e é por isso que eu estava tentando renomear a NIC e me deparei com todos esses problemas. Mas isso está errado.

Depois que inicializei o clone com a configuração de Andrew e a NIC foi renomeada, percebi que ele sempre puxava uma configuração de DHCP, mesmo após reinicializações sucessivas. Depois de me aprofundar um pouco mais, percebi que o cloud-init interage com o netplan (é por isso que ele difere de todos os outros sistemas operacionais que listei).

Descobri que isso estava acontecendo com o cloud-init, mostrando que ele interage com o netplan em alguns casos:

Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:08,634 - util.py[DEBUG]: Writing to /etc/netplan/50-cloud-init.yaml - wb: [644] 695 bytes
Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:08,636 - subp.py[DEBUG]: Running command ['netplan', 'generate'] with allowed return codes [0] (shell=False, capture=True)
Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:09,030 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth0'] with allowed return codes [0] (shell=False, capture=True)
Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:09,049 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/lo'] with allowed return codes [0] (shell=False, capture=True)

Portanto, para permitir que o cloud-init configure corretamente a configuração da rede, acabei precisando remover a configuração interna do netplan do instalador e reinstalar/limpar o cloud-init. Abaixo estão as etapas que utilizo com o ansible para isso:

    - name: Run cloud-init clean
      ansible.builtin.shell: cloud-init clean
      when: ansible_distribution == "Ubuntu"

    - name: Remove cloud-init
      ansible.builtin.apt:
        name: cloud-init
        state: absent
      when: ansible_distribution == "Ubuntu"

    - name: Remove /etc/cloud
      ansible.builtin.shell: rm -rf /etc/cloud
      when: ansible_distribution == "Ubuntu"

    - name: Remove /var/lib/cloud
      ansible.builtin.shell: rm -rf /var/lib/cloud
      when: ansible_distribution == "Ubuntu"

    - name: Reboot the Ubuntu VM
      ansible.builtin.reboot:
      when: ansible_distribution == "Ubuntu"

    - name: Install cloud-init
      ansible.builtin.apt:
        name: cloud-init
        state: latest
      when: ansible_distribution == "Ubuntu"

    - name: Remove netplan file
      ansible.builtin.shell: rm -f /etc/netplan/00-installer-config.yaml
      when: ansible_distribution == "Ubuntu"
      ignore_errors: yes

E o acima é acompanhado por uma configuração de instalação automática que exclui todo o network:bloco que pensei que precisava (e assim permitindo que a subiquidade o gerasse).

Answer

Eu gostaria de adicionar mais algumas informações para qualquer pessoa que possa ter problemas semelhantes. Minha postagem principal está incorreta em algumas áreas, agora que resolvi meus problemas e sei o que estava errado.

Em primeiro lugar, a resposta de Andrew resolverá o problema questionado na postagem. Mas descobri por que meu cloud-init não estava começando com a ajuda de sua postagem.

Algo nos logs de inicialização da nuvem que eu estava olhando originalmente me levou a pensar que a NIC não poderia ser renomeada com a inicialização da nuvem e é por isso que eu estava tentando renomear a NIC e me deparei com todos esses problemas. Mas isso está errado.

Depois que inicializei o clone com a configuração de Andrew e a NIC foi renomeada, percebi que ele sempre puxava uma configuração de DHCP, mesmo após reinicializações sucessivas. Depois de me aprofundar um pouco mais, percebi que o cloud-init interage com o netplan (é por isso que ele difere de todos os outros sistemas operacionais que listei).

Descobri que isso estava acontecendo com o cloud-init, mostrando que ele interage com o netplan em alguns casos:

Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:08,634 - util.py[DEBUG]: Writing to /etc/netplan/50-cloud-init.yaml - wb: [644] 695 bytes
Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:08,636 - subp.py[DEBUG]: Running command ['netplan', 'generate'] with allowed return codes [0] (shell=False, capture=True)
Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:09,030 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth0'] with allowed return codes [0] (shell=False, capture=True)
Sep  6 00:23:13 ubuntu22 cloud-init[773]: 2022-09-06 00:23:09,049 - subp.py[DEBUG]: Running command ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/lo'] with allowed return codes [0] (shell=False, capture=True)

Portanto, para permitir que o cloud-init configure corretamente a configuração da rede, acabei precisando remover a configuração interna do netplan do instalador e reinstalar/limpar o cloud-init. Abaixo estão as etapas que utilizo com o ansible para isso:

    - name: Run cloud-init clean
      ansible.builtin.shell: cloud-init clean
      when: ansible_distribution == "Ubuntu"

    - name: Remove cloud-init
      ansible.builtin.apt:
        name: cloud-init
        state: absent
      when: ansible_distribution == "Ubuntu"

    - name: Remove /etc/cloud
      ansible.builtin.shell: rm -rf /etc/cloud
      when: ansible_distribution == "Ubuntu"

    - name: Remove /var/lib/cloud
      ansible.builtin.shell: rm -rf /var/lib/cloud
      when: ansible_distribution == "Ubuntu"

    - name: Reboot the Ubuntu VM
      ansible.builtin.reboot:
      when: ansible_distribution == "Ubuntu"

    - name: Install cloud-init
      ansible.builtin.apt:
        name: cloud-init
        state: latest
      when: ansible_distribution == "Ubuntu"

    - name: Remove netplan file
      ansible.builtin.shell: rm -f /etc/netplan/00-installer-config.yaml
      when: ansible_distribution == "Ubuntu"
      ignore_errors: yes

E o acima é acompanhado por uma configuração de instalação automática que exclui todo o network:bloco que pensei que precisava (e assim permitindo que a subiquidade o gerasse).

Question 3

set timeout=10
if loadfont /boot/grub/fonts/font.pf2 ; then
        set gfxmode=auto
        insmod efi_gop
        insmod efi_uga
        insmod gfxterm
        terminal_output gfxterm
fi
# background_image /boot/grub/image/splash.png
set menu_color_normal=white/black
set menu_color_highlight=black/light-red

menuentry "Install Ubuntu" {
        set gfxpayload=keep
        linux   /casper/vmlinuz ip=dhcp cloud-config-url=/dev/null autoinstall ds="nocloud-net;s=http://xxx.xxx.xxx.xxx/autoinstall/" --- net.ifnames=0 biosdevname=0
        initrd  /casper/initrd
}
grub_platform
if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
        exit 1
}
menuentry 'UEFI Firmware Settings' {
        fwsetup
}
else
menuentry 'Test memory' {
        linux16 /boot/memtest86+.bin
}
fi

sua placa Ethernet será nomeada eth0 com "net.ifnames=0 biosdevname=0" no grub de instalação

Answer

set timeout=10
if loadfont /boot/grub/fonts/font.pf2 ; then
        set gfxmode=auto
        insmod efi_gop
        insmod efi_uga
        insmod gfxterm
        terminal_output gfxterm
fi
# background_image /boot/grub/image/splash.png
set menu_color_normal=white/black
set menu_color_highlight=black/light-red

menuentry "Install Ubuntu" {
        set gfxpayload=keep
        linux   /casper/vmlinuz ip=dhcp cloud-config-url=/dev/null autoinstall ds="nocloud-net;s=http://xxx.xxx.xxx.xxx/autoinstall/" --- net.ifnames=0 biosdevname=0
        initrd  /casper/initrd
}
grub_platform
if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
        exit 1
}
menuentry 'UEFI Firmware Settings' {
        fwsetup
}
else
menuentry 'Test memory' {
        linux16 /boot/memtest86+.bin
}
fi

sua placa Ethernet será nomeada eth0 com "net.ifnames=0 biosdevname=0" no grub de instalação

Server 22.04.1 subiquity autoinstall - o comando system-install falha após alterar o nome da NIC usando netplan

Responder1

Responder2

Responder3

informação relacionada