Netplan non si applica all'avvio


13

Ho installato Ubuntu 17.10 con gli ultimi aggiornamenti su una macchina virtuale VMware. Netplan non configura i miei 2 Ethernet.

Ecco il mio /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

Sono tornato a dispositivi prevedibili come eth0, e dopo l'avvio tutti i dispositivi sono nominati correttamente, ma non configurati.

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

Dopo il login e l' attivazione del sistema, riavviare i dispositivi systemd-networkd sono configurati. netplan si applica anche al lavoro.

Ho giocato così tanto con systemd-networkd.service e systemd-networkd.timer ma niente mi ha aiutato.

È abbastanza frustrante impostare manualmente la rete dopo ogni riavvio. Qualcuno sa come risolvere questo?


2
Al momento dell'avvio, quali sono i contenuti di / run / systemd / network e / run / systemd / netif?
slangasek,

Questo dovrebbe ora essere risolto in Bionic con netplan 0.36.3. Potresti testarlo e farcelo sapere?
dja,

2
Uso 18.04 e sto affrontando lo stesso problema. Hai qualche soluzione?
gtzinos,

Risposte:


3

Penso che tu abbia colpito LP: # 1770082 - "systemd-networkd non rinominando i dispositivi all'avvio".

Fondamentalmente, quando il sistema si avvia, il dispositivo di rete apparirà come eth0/ eth1ecc. L'ordine non è prevedibile, quindi udev rinomina i dispositivi in ​​cose come ens3o enp2s0nella fase iniziale di avvio. (Dovresti essere in grado di vederlo grepping dell'output di dmesg.)

Hai una set-namestrofa nel tuo YAML netplan. Successivamente all'avvio, ciò set-namegenera una regola di ridenominazione in un file di collegamento systemd , che viene letto da udev. Tuttavia, un file di collegamento non farà rinominare un dispositivo se è già stato rinominato. Nel tuo caso, quindi, il dispositivo non verrà rinominato perché probabilmente è stato rinominato in precedenza in initrd.

Ho aperto un bug su systemd ( problema n. 9006 - "udev: nome dell'interfaccia nel file di collegamento non applicato") al riguardo. Ho anche proposto una modifica a netplan ( PR # 31 - "Genera file di regole udev per rinominare i dispositivi") che causerà la creazione di un file di regole di sistema e di un file di collegamento, poiché un file di regole viene rispettato anche se il dispositivo ha già rinominato.

Per ovviare al problema, provare a eseguire l'avvio net.ifnames=0dalla riga di comando del kernel. Per una soluzione a lungo termine, aspettati che il mio passaggio a netplan venga trasferito su Bionic e rilasciato entro il prossimo mese.


Questo problema è stato risolto con netplan 0.36.3
dja,

Ciò ha risolto il problema con Ubuntu 18.04.1 aggiornato, inclusi gli aggiornamenti dei backport proposti e la sicurezza del 17/09/2018. Ho disabilitato le set-namedirettive per ora, non ho provato il net.ifnames=0cmdline del kernel. Con set-name, i dispositivi sono stati rinominati, ma non visualizzati.
TheJJ,

2

Ho esattamente lo stesso problema su Ubuntu 18.04, ma la soluzione di R. Pietsch non lo risolve :(

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

Ho anche provato ad abilitare l'utente root, che è disabilitato di default su Ubuntu, ma senza fortuna.

L'unico modo in cui devo ottenere la connettività è:

  1. accedere alla macchina usando la propria tastiera;
  2. digitare "sudo netplan applicare";
  3. allora sono finalmente in grado di inserire SSH nella macchina.

Se non "sudo netplan si applica", non ho alcuna connessione sulla macchina. Come è possibile inserire in una versione LTS un software così rotto?

Vorrei aggiungere maggiori dettagli sul mio scenario, per essere utile ad altre persone per riconoscere i fenomeni di cui stiamo parlando. Questo è ciò che stava accadendo nel mio caso:

  • Ho installato Ubuntu 18.04 sul mio Intel NUC usando netinstall;
  • Ho configurato il file YAML netplan per ottenere un indirizzo IP statico quando si è connessi in modalità wireless;
  • L'ho applicato con "sudo netplan apply";
  • Ho riavviato il mio NUC;
  • Ho lanciato un "ping -t" dal mio computer Windows;
  • Una volta riavviato, NUC ha mostrato il prompt di login di LXDE;
  • A quel punto, il NUC era irraggiungibile secondo il ping;
  • Ho effettuato l'accesso, digitato "sudo netplan apply" e dopo pochi secondi è diventato raggiungibile.

Penso che netplan sia un buon miglioramento rispetto a / etc / network / interfaces, ma questo comportamento dovrebbe essere risolto al più presto :)

AGGIORNARE:

Ho eseguito il debug del problema utilizzando i seguenti comandi:

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

Sembra che fosse il pannello di Network Manager in LXDE a interferire con esso. Anche se le connessioni sono state visualizzate come "non gestite", ho deselezionato "Abilita rete" e sembra che abbia risolto il problema.

Possiamo chiudere questo :)


2

L'ho provato con Ubuntu 18.04 e penso che questo errore sia stato corretto.
Funziona per me adesso.


Dovrebbe essere risolto con netplan 0.36.3
dja

1
No, ho capito bene oggi
Dario Fumagalli,

e ... ad oggi, ho un server Ubuntu 18.04 nuovo e aggiornato e questo succede ancora!
Dario Fumagalli,

0

Ho risolto questo problema inserendo

@reboot /usr/sbin/netplan apply

nel crontab della radice. Non la vera soluzione al problema, ma una soluzione alternativa che lo ha risolto.


0

Con Ubuntu 18.04, netplan era anche abbastanza nuovo per me, ho seguito una guida per creare il /etc/netplan/01-netcfg.yamlfile ed eseguirlo sudo netplan applye, come te, a ogni riavvio la connettività era sparita.

L'esecuzione manuale sudo netplan applylo ha reso di nuovo funzionante. Ma è stato fastidioso.

Nel mio caso, la soluzione era quella di modificare /etc/network/interfacese commentare tutte le stanze enp0 ** (controlla come vengono chiamate nel tuo sistema).

Quindi riavviare.

Fondamentalmente la vecchia configurazione in / etc / nwtwork / interfaces era in conflitto con netplan.


Questo non risponde alla domanda che viene posta.
Thomas Ward

0

Ho avuto un problema in cui avevo bisogno di riattivare gli eventi. Fondamentalmente netplan ha fatto tutte le configurazioni giuste ma networkd l'ha ignorato. Sostituire i dispositivi come "applica netplan" avrebbe risolto il problema.

Quindi per alcuni la soluzione potrebbe essere fare come

$ 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)

Forse questo aiuta alcuni a cercare questo problema.

Dal momento che penso che questo sia in realtà un bug, ho archiviato questo bug al riguardo.


0

Ok, risposta migliore, ho risolto il problema. sudo apt installa ifupdown quindi configura l'interfaccia sudo nano / etc / network / interfaces

auto enp3s0 iface enp3s0 inet indirizzo statico 192.168.1.100 netmask 255.255.255.0 rete 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.0.8.8.8.8

e chiunque lo abbia implementato in una versione del server LTS ovviamente non l'ha provato


0

Poiché questo è un problema in corso, ho un altro approccio per risolvere questo problema:

Crea un timer di sistema e applica le impostazioni di rete dopo l'avvio.

Ecco lo script: check_network. Devi sostituire l'interfaccia ens32 con la tua.

#!/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

Questa è l'unità di servizio check_network.service

[Unit]
Description=check if netplan configured network

[Service]
ExecStart=/root/jobs/check_network

[Install]
WantedBy=multi-user.target

E questo è il timer di sistema check_network.timer chiamato 30 sec dopo l'avvio e quindi ogni ora

[Unit]
Description=check_network timer

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

[Install]
WantedBy=timers.target

Copia check_network in / root / jobs

Copia check_network.service in / etc / systemd / system

Copia check_network.timer in / etc / systemd / system

E quindi abilitare il servizio e il timer

systemctl enable check_network.service
systemctl enable check_network.timer

0

Utente netplan su 18.04.1 Supponiamo che la configurazione di netplan venga letta al riavvio di networkd - questo di per sé è stato un po 'un problema perché ci sono circa 10 diversi servizi di rete che systemctl conosce. Nessuno di loro ha portato il risultato desiderato, quindi ho fatto ricorso al riavvio dell'intera macchina. Inutilmente. Alla fine ho scoperto che "netplan apply" non aiuta qui solo nell'applicazione, ma indica anche errori di sintassi. Quindi dopo il cambiamento sembra che devi fare netplan e poi hai finito. Questo non è descritto nel manuale a meno che non mi sia perso, quindi lo includo qui per altri piccoli vermi poveri come me.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.