Netplan não se aplica na inicialização

Question

Eu instalei o Ubuntu 17.10 com as atualizações mais recentes em uma máquina virtual VMware. A Netplan não configura meus dois ethernets.

Aqui está meu /etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    lan:
      match:
        macaddress: 00:12:34:a8:29:e8
      set-name: lan
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 10.10.0.48/24
        - 1701:5740:5000:3301::48/64

    failover:
      match:
        macaddress: 00:45:57:89:27:e8
      set-name: failover
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 17.25.111.30/27
        - 1701:5740:5000:3300::30/64
      gateway4: 17.25.111.1
      gateway6: 1701:5740:5000:3300::1

      nameservers:
        search:
          - example.at
          - intern.example.at
        addresses:
          - 10.10.0.1
          - 1701:5740::66

Voltei para dispositivos previsíveis como eth0 e, após a inicialização, todos os dispositivos são nomeados corretamente, mas não configurados.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: lan: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:12:34:a8:29:e8 brd ff:ff:ff:ff:ff:ff
3: failover: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:45:57:89:27:e8 brd ff:ff:ff:ff:ff:ff

Após o login e o disparo, os dispositivos systemctl restart systemd-networkd são configurados. O netplan apply também faz o trabalho.

Joguei muito com o systemd-networkd.service e o systemd-networkd.timer, mas nada ajudou.

É muito frustrante configurar a rede manualmente após cada reinicialização. Alguém sabe como resolver isso?

    

Answer 1

Eu já tentei com o Ubuntu 18.04 e acho que esse bug foi corrigido.
Isso funciona para mim agora.

    

Answer 2

Eu tenho exatamente o mesmo problema no Ubuntu 18.04, mas a solução de R. Pietsch não resolve :(

sudo crontab -e
@reboot /usr/sbin/netplan apply

Eu também tentei ativar o usuário root, que está desativado por padrão no Ubuntu, mas sem sorte.

A única maneira de obter conectividade é:

1. faça o login na máquina usando seu próprio teclado;
2. digite "sudo netplan apply";
3. então, finalmente, posso usar o SSH na máquina.

Se eu não "sudo netplan apply", não tenho conexão na máquina. Como é possível colocar em uma versão LTS um software tão quebrado?

Eu gostaria de adicionar mais detalhes sobre o meu cenário, para ser útil a outras pessoas para reconhecer os fenômenos sobre os quais estamos falando. Isso é o que estava acontecendo no meu caso:

• Eu instalei o Ubuntu 18.04 no meu Intel NUC usando o netinstall;
• Eu configurei o arquivo YAML do netplan para obter um endereço IP estático quando conectado sem fio;
• eu apliquei com "sudo netplan apply";
• eu reiniciei meu NUC;
• eu iniciei um "ping -t" na minha máquina Windows;
• Uma vez reiniciado, o NUC mostrou o prompt de login do LXDE;
• Nesse ponto, o NUC estava inacessível de acordo com o ping;
• Eu entrei, digitei "sudo netplan apply" e depois de alguns segundos ele se tornou acessível.

Acho que o netplan é uma boa melhoria em comparação com o / etc / network / interfaces, mas esse comportamento deve ser corrigido assim que possível:)

ATUALIZAÇÃO:

Depurei o problema usando os seguintes comandos:

$ journalctl --no-pager -lu systemd-networkd
$ networkctl

Parece que o painel do Network Manager no LXDE está interferindo nele. Mesmo se as conexões fossem exibidas como "não gerenciadas", eu desmarcava a opção "Ativar rede" e parece que isso resolveu o problema.

Podemos fechar este aqui:)

    

Answer 3

Acho que você bateu LP: # 1770082 - "systemd-networkd não renomeia dispositivos na inicialização".

Basicamente, quando o seu sistema está inicializando, o dispositivo de rede aparecerá como eth0 / eth1 etc. O pedido não é previsível, então o udev renomeia os dispositivos para coisas como ens3 ou enp2s0 no fase initrd de inicialização. (Você deve ser capaz de ver isso, mostrando a saída de dmesg .)

Você tem uma estrofe set-name em seu YAML de rede. Posteriormente na inicialização, esse set-name gera uma regra de renomeação em um arquivo systemd link , que é lido pelo udev. No entanto, um arquivo de link não fará com que um dispositivo seja renomeado se já tiver sido renomeado. No seu caso, o dispositivo não será renomeado porque provavelmente foi renomeado anteriormente no initrd.

Eu abri um bug contra o systemd ( issue # 9006 - "udev: nome da interface no arquivo de link não aplicado ") sobre isso. Também propus uma alteração no netplan ( PR # 31 - "Gerar arquivos de regras do udev para renomear dispositivos") que faça com que um arquivo systemd rules seja criado, assim como um arquivo de link, já que um arquivo de regras é aceito mesmo que o dispositivo já tenha sido renomeado.

Como solução alternativa, tente inicializar com net.ifnames=0 na linha de comando do kernel. Para uma solução de longo prazo, espere que minha mudança para o netplan seja backportada para o Bionic e lançada no próximo mês.

    

Answer 4

Corrigi este problema inserindo

@reboot /usr/sbin/netplan apply

no crontab da raiz. Não é a solução real para o problema, mas sim uma solução que o corrigiu.

    

Answer 5

Eu tive um problema em que precisei reativar os eventos. Essencialmente, o netplan fez tudo certo, mas o networkd o ignorou. A substituição dos dispositivos como "netplan apply" resolveria isso.

Então, para alguns, a solução pode ser fazer como

$ echo virtio0 | sudo tee /sys/bus/virtio/drivers/virtio_net/virtio0/driver/unbind
$ echo virtio0 | sudo tee /sys/bus/virtio/drivers/virtio_net/bind
(or other devices / drivers in your case)

Talvez isso ajude alguns procurando por esse problema.

Desde que eu acho que isso é realmente um bug eu arquivei este bug sobre isso.

    

Answer 6

Com o ubuntu 18.04, o netplan também era novo para mim, eu segui um orientar para criar o arquivo /etc/netplan/01-netcfg.yaml e executar sudo netplan apply e, assim como você, na reinicialização, a conectividade foi eliminada.

A execução manual de sudo netplan apply fez com que funcionasse novamente. Mas isso foi chato.

No meu caso, a solução foi editar /etc/network/interfaces e comentar todas as estrofes enp0 ** (confira como elas são chamadas no seu sistema).

Em seguida, reinicie.

Basicamente, a configuração antiga em / etc / nwtwork / interfaces estava em conflito com o netplan.