netplan apply fails on 22.04 with clean yaml

Bug #1962095 reported by Xing Li
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netplan.io (Ubuntu)
Fix Released
Undecided
Lukas Märdian
Jammy
Fix Released
Undecided
Lukas Märdian
subiquity (Ubuntu)
Triaged
Medium
Unassigned
Jammy
Triaged
Medium
Unassigned

Bug Description

Ubuntu 22.04 clean server iso install with default yaml using dhcp

-------------
# This is the network config written by 'subiquity'
network:
  ethernets:
    eno1:
      dhcp4: true
    enp4s0:
      dhcp4: true
  version: 2
-------------

netplan --debug generate is green. yaml is perfect

--------------
root@cube1:/etc/netplan# netplan --debug generate
DEBUG:command generate: running ['/lib/netplan/generate']
** (generate:65883): DEBUG: 02:01:05.691: starting new processing pass
** (generate:65883): DEBUG: 02:01:05.691: We have some netdefs, pass them through a final round of validation
** (generate:65883): DEBUG: 02:01:05.691: eno1: setting default backend to 1
** (generate:65883): DEBUG: 02:01:05.691: Configuration is valid
** (generate:65883): DEBUG: 02:01:05.691: enp4s0: setting default backend to 1
** (generate:65883): DEBUG: 02:01:05.691: Configuration is valid
** (generate:65883): DEBUG: 02:01:05.691: Generating output files..
** (generate:65883): DEBUG: 02:01:05.691: openvswitch: definition eno1 is not for us (backend 1)
** (generate:65883): DEBUG: 02:01:05.691: NetworkManager: definition eno1 is not for us (backend 1)
** (generate:65883): DEBUG: 02:01:05.691: openvswitch: definition enp4s0 is not for us (backend 1)
** (generate:65883): DEBUG: 02:01:05.691: NetworkManager: definition enp4s0 is not for us (backend 1)
----------------

execute netplan apply/try will fail

----------------
Failed to reload network settings: No such file or directory
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 244, in run_command
    self.func()
  File "/usr/share/netplan/netplan/cli/commands/apply.py", line 61, in run
    self.run_command()
  File "/usr/share/netplan/netplan/cli/utils.py", line 244, in run_command
    self.func()
  File "/usr/share/netplan/netplan/cli/commands/apply.py", line 255, in command_apply
    utils.networkctl_reconfigure(utils.networkd_interfaces())
  File "/usr/share/netplan/netplan/cli/utils.py", line 103, in networkctl_reconfigure
    subprocess.check_call(['networkctl', 'reload'])
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['networkctl', 'reload']' returned non-zero exit status 1.
----------------

ubuntu forum thread:

https://ubuntuforums.org/showthread.php?t=2472318

Revision history for this message
Erich Eickmeyer  (eeickmeyer) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
apport-collect 1962095

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Changed in netplan.io (Ubuntu):
status: New → Incomplete
Revision history for this message
Xing Li (diegomontoya) wrote :

I am unable to authenticate the apport-collect generated url. The link brings me to the following error even after I am correctly logged in:

Not allowed here
Sorry, you don't have permission to access this page or the information in this page is not shared with you.

Revision history for this message
Valentin David (valentin.david) wrote :

We have a related issue in Ubuntu Core 22. It fails the same way. But in our case it fails because systemd-networkd is not running, because subiquity has stopped it before calling "netplan apply". And then "networkctl reload" of course fails.

Was systemd-networkd running when you called "netplan apply"?

The UC22 bug is at https://github.com/snapcore/core-base/issues/31

Lukas Märdian (slyon)
tags: added: rls-jj-incoming
Revision history for this message
Xing Li (diegomontoya) wrote :

systemd-networkd is running. Just tested netplan apply and still failed.

-------

# systemctl status systemd-networkd
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-02-22 04:33:06 UTC; 2 days ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 849 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 154245)
     Memory: 2.8M
     CGroup: /system.slice/systemd-networkd.service

------

However, after I restarted systemd-networkd via systemctl restart, subsequent netplan apply no longer fails. That's weird.

Revision history for this message
Lukas Märdian (slyon) wrote :

So it seems like this is really related to a stopped (or hanging/crashed?) systemd-networkd.

In subiquity this seems to be enforced via https://github.com/canonical/subiquity/commit/41014408143ece5df9ef000d65c23f9307098905 which is in conflict with newer versions of netplan that try to call `networkctl reload` instead of `systemctl restart systemd-networkd.service` (i.e. https://github.com/canonical/netplan/commit/3ec52c41d1a9b3c011c94f9644a02e99451f4330)

Lukas Märdian (slyon)
Changed in netplan.io (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
rawad (khawand) wrote :

Hello

i have encountered this as well on a physical server, on a vmware vm issue does not occur, i do not specify network settings in my autoinstall at all in general, but:

to bypass the crash (as a temporary workaround) i noticed you can make the network section interactive by adding to your user-data file:

interactive-sections:
    - network

this way you just press confirm of network settings in this step manually (without any configuration needed)
and the rest of the install continues automatically without crashing.
hope this helps you out for now.

Revision history for this message
Lukas Märdian (slyon) wrote :

I've prepared a fix/workaround for this issue in netplan: https://github.com/canonical/netplan/pull/260

Changed in netplan.io (Ubuntu):
assignee: nobody → Lukas Märdian (slyon)
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netplan.io - 0.104-0ubuntu2

---------------
netplan.io (0.104-0ubuntu2) jammy; urgency=medium

  * Pick upstream commit a4b70e7, to restart networkd if necessary (LP: #1962095)

 -- Lukas Märdian <email address hidden> Thu, 10 Mar 2022 09:45:00 +0100

Changed in netplan.io (Ubuntu):
status: In Progress → Fix Released
Changed in subiquity (Ubuntu):
importance: Undecided → Medium
Dan Bungert (dbungert)
tags: added: fr-2101
Revision history for this message
Xing Li (diegomontoya) wrote :

confirmed fix resolved issue on my system

------

netplan.io (0.104-0ubuntu2)

tags: removed: rls-jj-incoming
tags: added: foundations-todo
Changed in subiquity (Ubuntu):
status: New → Triaged
Changed in subiquity (Ubuntu Jammy):
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.