Join Log in
Score:0
avatar Ubuntu

Netplan error when trying a configuration

cn flag
Panos

I am running Ubuntu server 20.04.3 LTS on a remote Raspberry Pi 4. It is connected through WiFi to a remote router (IP 192.168.1.1), and I had configured networking with netplan. However after some months I decided to change the DNS configuration, i.e. remove my router local DNS and replace it with Cloudflare's DNS. So knowing that the yaml file is very sensitive with spaces, the only change I made is to remove the "92" and "68", so the file now is as follows:

$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    renderer: networkd
    ethernets:
        eth0:
            dhcp4: true
    wifis:
        wlan0:
            dhcp4: no
            addresses: [192.168.1.12/24]
            gateway4: 192.168.1.1
            nameservers:
                addresses: [1.1.1.1, 8.8.8.8]
            access-points:
                "accesspointname":
                    password: "accesspointpassword"
    version: 2

However when I run netplan try, I get the following:

$ sudo netplan try
Job for netplan-wpa-wlan0.service canceled.

An error occurred: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.

Reverting.
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket

Also sometimes I get the following error instead:

$ sudo netplan try
Job for netplan-wpa-wlan0.service canceled.

An error occurred: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.

Reverting.
Job for netplan-wpa-wlan0.service canceled.
Traceback (most recent call last):
  File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 84, in command_try
    NetplanApply().command_apply(run_generate=True, sync=True, exit_on_error=False)
  File "/usr/share/netplan/netplan/cli/commands/apply.py", line 164, in command_apply
    utils.systemctl_networkd('stop', sync=sync, extra_services=wpa_services)
  File "/usr/share/netplan/netplan/cli/utils.py", line 131, in systemctl_networkd
    subprocess.check_call(command)
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/sbin/netplan", line 23, in <module>
    netplan.main()
  File "/usr/share/netplan/netplan/cli/core.py", line 50, in main
    self.run_command()
  File "/usr/share/netplan/netplan/cli/utils.py", line 264, in run_command
    self.func()
  File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 66, in run
    self.run_command()
  File "/usr/share/netplan/netplan/cli/utils.py", line 264, in run_command
    self.func()
  File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 95, in command_try
    self.revert()
  File "/usr/share/netplan/netplan/cli/commands/try_command.py", line 118, in revert
    NetplanApply().command_apply(run_generate=False, sync=True, exit_on_error=False)
  File "/usr/share/netplan/netplan/cli/commands/apply.py", line 164, in command_apply
    utils.systemctl_networkd('stop', sync=sync, extra_services=wpa_services)
  File "/usr/share/netplan/netplan/cli/utils.py", line 131, in systemctl_networkd
    subprocess.check_call(command)
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['systemctl', 'stop', 'systemd-networkd.service', 'netplan-wpa-*.service']' returned non-zero exit status 1.

I want to be very careful with this as I don't want to be permanently locked out in the case of a network configuration error, as I don't have local access to fix things if needed (that's why I ran netplan try.. I'm not sure if I reboot the system if I will be locked out?) Any suggestions?

184
0 + 0
Score:1
heynnema avatar Ubuntu
ru flag
heynnema

See if this makes any difference...

Note: Confirm no tabs, just spaces

Note: Normal indentation is two spaces

network:
    version: 2
    renderer: networkd
    ethernets:
        eth0:
            dhcp4: true
            optional: true
    wifis:
        wlan0:
            addresses: [192.168.1.12/24]
            gateway4: 192.168.1.1
            nameservers:
                addresses: [1.1.1.1, 1.0.0.1]
            access-points:
                "accesspointname":
                    password: "accesspointpassword"

And create /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg...

network: {config: disabled}

Then...

sudo netplan try

And when you're ready...

sudo netplan generate

sudo netplan apply

reboot

0 + 0
cn flag
Panos
I don't think this helps. As you can see, my yaml file is properly indented and formatted. After all, it was working before.
0
Reply
cn flag
Panos
Nevertheless, I tried changing from 4 spaces to 2 spaces per indentation, but I still get the same error. It's definitely not a yaml formatting issue.
0
Reply
heynnema avatar
ru flag
heynnema
@Panos Did you use my EXACT .yaml file... or just edit your own? Mine has a couple of changes. Did you remove tabs?
0
Reply
cn flag
Panos
Seems I messed up unfortunately. I copied the whole thing into the yaml file but without replacing the SSID and password with the actual ones. Even though I did `netplan try`, it seems that this persists. I had my on-site person to do a power cycle, but I am still locked out. I thought `netplan try` does not persist after reboots! Will have my on-site person to connect with ethernet cable, hopefully I can access it remotely somehow.
0
Reply
heynnema avatar
ru flag
heynnema
@Panos That's an "oops". Keep me posted.
0
Reply
cn flag
Panos
so a weird thing is happening. `netplan try`` still gives the same error even with your yaml file. However if I reboot (without running generate or apply), the updated DNS servers are there. Although my goal is satisfied even in this way, I find netplan highly impractical (especially for remote headless systems) and buggy. I will look how to get rid of netplan when I'm on site.
0
Reply
heynnema avatar
ru flag
heynnema
@Panos Don't get rid of netplan. Just make sure that your Software Updates are current, so that you'll have the latest version. Older netplan may have this problem with try. On a RsP4, you may need to update to 21.04. Also, do the `sudo netplan generate` and `sudo netplan apply` and `reboot`.
0
Reply
heynnema avatar
ru flag
heynnema
@Panos Were you doing `netplan try` or `sudo netplan try`?
0
Reply
cn flag
Panos
I was doing everything by the book. Correct indentations without tabs, check validity of yaml file with validator program, run all updates. However I'd rather not update to 21.04, I want to stay at LTS versions, but anyway I don't think thats an issue. Was running everything with sudo. I consider myself an indermediate user, and from all this experience I think netplan is very cumbersome, buggy and not very suitable for remote headless systems. Will try and see how ifupdown does.
0
Reply
heynnema avatar
ru flag
heynnema
@Panos Do some research. I know that full RsP4 support didn't come until very late in the game... and that may be 20.10/21.04. Look at the release notes.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.