Puncte:0

Eroare Netplan la încercarea unei configurații

drapel cn

Rulez serverul Ubuntu 20.04.3 LTS pe un la distanta Raspberry Pi 4. Este conectat prin WiFi la un router la distanță (IP 192.168.1.1), iar eu aveam configurat rețea cu netplan. Cu toate acestea, după câteva luni, am decis să schimb configurația DNS, adică să elimin DNS-ul local al routerului și să-l înlocuiesc cu DNS-ul Cloudflare. Deci, știind că fișierul yaml este foarte sensibil cu spații, singura modificare pe care am făcut-o este să elimin „92” și „68”, așa că fișierul acum este după cum urmează:

$ cat /etc/netplan/50-cloud-init.yaml
# Acest fișier este generat din informațiile furnizate de sursa de date. Schimbări
# nu va persista la o repornire a instanței. Pentru a dezactiva cloud-init
# capabilități de configurare a rețelei, scrieți un fișier
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg cu următoarele:
# network: {config: disabled}
reţea:
    versiunea: 2
    redator: în rețea
    ethernet:
        eth0:
            dhcp4: adevărat
    wifi-uri:
        wlan0:
            dhcp4: nu
            adrese: [192.168.1.12/24]
            gateway4: 192.168.1.1
            servere de nume:
                adrese: [1.1.1.1, 8.8.8.8]
            puncte de acces:
                "numele punctului de acces":
                    parola: "accesspointpassword"
    versiunea: 2

Cu toate acestea, când rulez netplan try, primesc următoarele:

$ sudo netplan try
Job pentru netplan-wpa-wlan0.service a fost anulat.

A apărut o eroare: comanda „['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' a returnat starea de ieșire diferită de zero 1.

Revenire.
Avertisment: Oprirea systemd-networkd.service, dar poate fi activată de:
  systemd-networkd.socket

De asemenea, uneori primesc următoarea eroare:

$ sudo netplan try
Job pentru netplan-wpa-wlan0.service a fost anulat.

A apărut o eroare: comanda „['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' a returnat starea de ieșire diferită de zero 1.

Revenire.
Job pentru netplan-wpa-wlan0.service a fost anulat.
Traceback (cel mai recent apel ultimul):
  Fișierul „/usr/share/netplan/netplan/cli/commands/try_command.py”, linia 84, în command_try
    NetplanApply().command_apply(run_generate=True, sync=True, exit_on_error=False)
  Fișierul „/usr/share/netplan/netplan/cli/commands/apply.py”, linia 164, în command_apply
    utils.systemctl_networkd('stop', sync=sync, extra_services=wpa_services)
  Fișierul „/usr/share/netplan/netplan/cli/utils.py”, linia 131, în systemctl_networkd
    subprocess.check_call(comandă)
  Fișierul „/usr/lib/python3.8/subprocess.py”, linia 364, în check_call
    ridică CalledProcessError (recod, cmd)
subprocess.CalledProcessError: Comanda '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' a returnat starea de ieșire diferită de zero 1.

În timpul gestionării excepției de mai sus, a apărut o altă excepție:

Traceback (cel mai recent apel ultimul):
  Fișierul „/usr/sbin/netplan”, linia 23, în <modul>
    netplan.main()
  Fișierul „/usr/share/netplan/netplan/cli/core.py”, rândul 50, în principal
    self.run_command()
  Fișierul „/usr/share/netplan/netplan/cli/utils.py”, linia 264, în run_command
    self.func()
  Fișierul „/usr/share/netplan/netplan/cli/commands/try_command.py”, linia 66, în curs
    self.run_command()
  Fișierul „/usr/share/netplan/netplan/cli/utils.py”, linia 264, în run_command
    self.func()
  Fișierul „/usr/share/netplan/netplan/cli/commands/try_command.py”, linia 95, în command_try
    self.revert()
  Fișierul „/usr/share/netplan/netplan/cli/commands/try_command.py”, linia 118, invers
    NetplanApply().command_apply(run_generate=False, sync=True, exit_on_error=Fals)
  Fișierul „/usr/share/netplan/netplan/cli/commands/apply.py”, linia 164, în command_apply
    utils.systemctl_networkd('stop', sync=sync, extra_services=wpa_services)
  Fișierul „/usr/share/netplan/netplan/cli/utils.py”, linia 131, în systemctl_networkd
    subprocess.check_call(comandă)
  Fișierul „/usr/lib/python3.8/subprocess.py”, linia 364, în check_call
    ridică CalledProcessError (recod, cmd)
subprocess.CalledProcessError: Comanda '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' a returnat starea de ieșire diferită de zero 1.

Vreau să fiu foarte atent cu asta, deoarece nu vreau să fiu blocat permanent în cazul unei erori de configurare a rețelei, deoarece nu am acces local pentru a remedia lucrurile dacă este necesar (de aceea am rulat netplan try.. Nu sunt sigur dacă repornesc sistemul dacă voi fi blocat?) Orice sugestii?

Puncte:1
drapel ru

Vezi dacă asta face vreo diferență...

Notă: Confirmați că nu există file, doar spații

Notă: Indentarea normală este de două spații

reţea:
    versiunea: 2
    redator: în rețea
    ethernet:
        eth0:
            dhcp4: adevărat
            opțional: adevărat
    wifi-uri:
        wlan0:
            adrese: [192.168.1.12/24]
            gateway4: 192.168.1.1
            servere de nume:
                adrese: [1.1.1.1, 1.0.0.1]
            puncte de acces:
                "numele punctului de acces":
                    parola: "accesspointpassword"

Și creați /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg...

reţea: {config: dezactivat}

Atunci...

sudo netplan try

Și când ești gata...

sudo netplan generate

se aplică sudo netplan

reporniți

drapel cn
Nu cred că asta ajută. După cum puteți vedea, fișierul meu yaml este indentat și formatat corespunzător. La urma urmei, a funcționat înainte.
drapel cn
Cu toate acestea, am încercat să schimb de la 4 spații la 2 spații pe indentație, dar încă primesc aceeași eroare. Cu siguranță nu este o problemă de formatare yaml.
heynnema avatar
drapel ru
@Panos Ai folosit fișierul meu EXACT .yaml... sau pur și simplu l-ai editat pe al tău? Al meu are câteva modificări. Ai eliminat filele?
drapel cn
Se pare că am încurcat din păcate. Am copiat totul în fișierul yaml, dar fără a înlocui SSID-ul și parola cu cele reale. Chiar dacă am făcut `netplan try`, se pare că asta persistă. Am avut persoana mea de la fața locului să facă un ciclu de alimentare, dar sunt încă blocat. Am crezut că `netplan try` nu persistă după reporniri! Voi avea persoana mea de la fața locului să se conecteze cu cablul ethernet, sper să-l pot accesa de la distanță cumva.
heynnema avatar
drapel ru
@Panos Acesta este un „hopa”. Tine-ma la curent.
drapel cn
deci se întâmplă un lucru ciudat. `netplan try`` dă în continuare aceeași eroare chiar și cu fișierul dvs. yaml. Cu toate acestea, dacă repornesc (fără a rula generarea sau aplicarea), serverele DNS actualizate sunt acolo. Deși obiectivul meu este îndeplinit chiar și în acest fel, consider netplan extrem de impracticabil (mai ales pentru sistemele headless la distanță) și buggy. Voi căuta cum să scap de netplan când voi fi pe site.
heynnema avatar
drapel ru
@Panos Nu scăpa de netplan. Doar asigurați-vă că actualizările de software sunt actualizate, astfel încât să aveți cea mai recentă versiune. Netplan mai vechi poate avea această problemă cu try. Pe un RsP4, poate fi necesar să actualizați la 21.04. De asemenea, faceți `sudo netplan generate` și `sudo netplan apply` și `reboot`.
heynnema avatar
drapel ru
@Panos Făceai `netplan try` sau `sudo netplan try`?
drapel cn
Făceam totul la carte. Corectați indentările fără file, verificați validitatea fișierului yaml cu programul de validare, rulați toate actualizările. Cu toate acestea, prefer să nu actualizez la 21.04, vreau să rămân la versiunile LTS, dar oricum nu cred că aceasta este o problemă. Rula totul cu sudo. Mă consider un utilizator intermediar, iar din toată această experiență cred că netplan este foarte greoi, buggy și nu prea potrivit pentru sistemele headless la distanță. Voi încerca să văd cum face ifupdown.
heynnema avatar
drapel ru
@Panos Faceți niște cercetări. Știu că suportul RsP4 complet nu a venit decât foarte târziu în joc... și poate fi 20.10/21.04. Uită-te la notele de lansare.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.