Netplan no se aplica al inicio


13

Instalé Ubuntu 17.10 con las últimas actualizaciones en una máquina virtual vmware. Netplan no configura mis 2 ethernet.

Aquí está mi /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

Volví a dispositivos predecibles como eth0, y después del arranque todos los dispositivos se nombran correctamente, pero no están 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

Después de iniciar sesión y activar systemctl, reinicie systemd-networkd dispositivos están configurados. netplan apply también hace el trabajo.

Jugué mucho con systemd-networkd.service y systemd-networkd.timer pero nada me ayudó.

Es bastante frustrante configurar la red manualmente después de cada reinicio. Alguien sabe cómo resolver esto?


2
En el momento del arranque, ¿cuáles son los contenidos de / run / systemd / network y / run / systemd / netif?
slangasek

Esto ahora debería repararse en Bionic con netplan 0.36.3. ¿Podrías probarlo y hacernos saber?
dja

2
Yo uso 18.04 y estoy enfrentando el mismo problema. Tienes alguna solución ?
gtzinos

Respuestas:


3

Creo que has accedido a LP: # 1770082 - "systemd-networkd no renombra dispositivos en el arranque".

Básicamente, cuando su sistema está arrancando, el dispositivo de red aparecerá como eth0/ eth1etc. El orden no es predecible, por lo que udev cambia el nombre de los dispositivos a cosas como ens3o enp2s0en la fase de inicio del arranque. (Debería poder ver esto haciendo clic en la salida de dmesg).

Tienes una set-nameestrofa en tu netplan YAML. Más adelante en el arranque, eso set-namegenera una regla de cambio de nombre en un archivo de enlace systemd , que es leído por udev. Sin embargo, un archivo de enlace no hará que se cambie el nombre de un dispositivo si ya se ha cambiado el nombre. En su caso, entonces, el dispositivo no se cambiará de nombre porque probablemente se renombró anteriormente en initrd.

Abrí un error contra systemd ( problema # 9006 - "udev: nombre de interfaz en el archivo de enlace no aplicado") sobre esto. También propuse un cambio a netplan ( PR # 31 - "Generar archivos de reglas udev para cambiar el nombre de los dispositivos") que hará que se cree un archivo de reglas systemd así como un archivo de enlace, ya que se respeta un archivo de reglas incluso si el dispositivo tiene Ya ha sido renombrado.

Como solución alternativa, intente arrancar con net.ifnames=0en la línea de comando del núcleo. Para una solución a largo plazo, espere que mi cambio a netplan se regrese a Bionic y se lance en el próximo mes más o menos.


Esto ahora está arreglado con netplan 0.36.3
dja

Esto lo resolvió para mí en Ubuntu 18.04.1 actualizado, incluidas las actualizaciones de backports propuestas y la seguridad en 2018-09-17. Inhabilité las set-namedirectivas por ahora, no probé el net.ifnames=0cmdline del núcleo. Con set-name, los dispositivos cambiaron de nombre, pero no se mencionaron.
TheJJ

2

Tengo exactamente el mismo problema en Ubuntu 18.04, pero la solución de R. Pietsch no lo resuelve :(

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

También intenté habilitar al usuario root, que está deshabilitado por defecto en Ubuntu, pero no tuve suerte.

La única forma en que tengo que ganar conectividad es:

  1. iniciar sesión en la máquina con su propio teclado;
  2. escriba "sudo netplan apply";
  3. entonces finalmente puedo SSH en la máquina.

Si no "sudo netplan apply", no tengo conexión en la máquina. ¿Cómo es posible poner en una versión LTS un software tan roto?

Me gustaría agregar más detalles sobre mi escenario, para ser útil a otras personas para reconocer los fenómenos de los que estamos hablando. Esto es lo que estaba sucediendo en mi caso:

  • Instalé Ubuntu 18.04 en mi Intel NUC usando el netinstall;
  • Configuré el archivo netplan YAML para obtener una dirección IP estática cuando está conectado de forma inalámbrica;
  • Lo apliqué con "sudo netplan apply";
  • Reinicié mi NUC;
  • Lancé un "ping -t" desde mi máquina Windows;
  • Una vez reiniciado, el NUC mostró la solicitud de inicio de sesión LXDE;
  • En ese punto, el NUC era inalcanzable según el ping;
  • Ingresé, escribí "sudo netplan apply" y después de unos segundos se volvió accesible.

Creo que netplan es una buena mejora en comparación con / etc / network / interfaces, pero este comportamiento debería repararse lo antes posible :)

ACTUALIZAR:

Depuré el problema usando los siguientes comandos:

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

Parece que fue el panel de Network Manager en LXDE lo que interfirió con él. Incluso si las conexiones se mostraban como "no administradas", desmarqué la casilla "Habilitar redes" y parece que solucionó el problema.

Podemos cerrar este :)


2

Ahora lo he probado con Ubuntu 18.04 y creo que este error se ha solucionado.
Funciona para mi ahora.


Debería arreglarse con netplan 0.36.3
dja

1
No, lo hice bien hoy
Dario Fumagalli

y ... a partir de hoy, tengo un servidor Ubuntu 18.04 nuevo y actualizado, ¡y esto todavía sucede!
Dario Fumagalli

0

Solucioné este problema insertando

@reboot /usr/sbin/netplan apply

en el crontab de root. No es la solución real para el problema, sino una solución que lo solucionó.


0

Con ubuntu 18.04, netplan también era bastante nuevo para mí, seguí una guía para crear el /etc/netplan/01-netcfg.yamlarchivo y ejecutarlo sudo netplan applyy, como tú, en cualquier momento reiniciar la conectividad se había ido.

La ejecución manual sudo netplan applyhizo que volviera a funcionar. Pero eso fue molesto.

En mi caso, la solución fue editar /etc/network/interfacesy comentar todas las estrofas enp0 ** (verifique cómo se llaman en su sistema).

Luego reiniciar.

Básicamente, la configuración anterior en / etc / nwtwork / interfaces estaba en conflicto con netplan.


Esto no responde la pregunta que se hace.
Thomas Ward

0

Tuve un problema en el que necesitaba volver a activar los eventos. Esencialmente, netplan hizo toda la configuración correctamente pero networkd lo ignoró. Volver a conectar los dispositivos como "netplan apply" lo arreglaría.

Entonces, para algunos, la solución podría ser hacer 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)

Quizás esto ayude a algunos a buscar este problema.

Como creo que esto es realmente un error, presenté este error al respecto.


0

Ok, mejor respuesta. Lo arreglé. Vuelve a ifupdown hasta que se arregle netplan. sudo apt install ifupdown luego configure la interfaz sudo nano / etc / network / interfaces

auto enp3s0 iface enp3s0 dirección estática inet 192.168.1.100 máscara de red 255.255.255.0 red 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8

y quien implementó esto en una versión del servidor LTS obviamente no lo probó


0

Como este es un problema continuo, tengo otro enfoque para resolver este problema:

Cree un temporizador systemd y aplique stettings de red después del arranque.

Aquí está el script: check_network. Debe reemplazar la interfaz ens32 con la suya.

#!/bin/bash
#
CMD="$(ip address | egrep -c "^[\s\t]*inet .* ens32$")"
if [ ${CMD} -eq "0" ]
then
   echo "check network not configured, configuring now..." | systemd-cat -p info
   netplan apply
else
   echo "check network ok" | systemd-cat -p info
fi

Esta es la unidad de servicio check_network.service

[Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

Y este es el temporizador systemd check_network.timer llamado 30 segundos después del arranque y luego cada hora

[Unit]
Description=check_network timer

[Timer]
OnBootSec=30s
OnUnitActiveSec=3600s
Persistent=true
Unit=check_network.service

[Install]
WantedBy=timers.target

Copie check_network en / root / jobs

Copie check_network.service en / etc / systemd / system

Copie check_network.timer en / etc / systemd / system

Y luego habilite el servicio y el temporizador

systemctl enable check_network.service
systemctl enable check_network.timer

0

usuario de netplan en 18.04.1 Suponiendo que la configuración de netplan se lee al reiniciar networkd: esto en sí mismo fue un poco problemático porque hay como 10 servicios de red diferentes que systemctl conoce. Ninguno de ellos trajo el resultado deseado, así que recurrí a reiniciar toda la máquina. En vano. Eventualmente descubrí que 'netplan apply' ayuda aquí no solo en la aplicación sino que también indica fallas de sintaxis. Entonces, después del cambio, parece que debe aplicar netplan y luego listo. Esto no se describe en el manual a menos que me lo haya perdido, así que lo incluyo aquí para otros pequeños gusanos pobres como yo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.