I tried the following both on a Ubuntu 22.04 host as well as on a Ubuntu 24.04 host with the same result.
When installing a guest (container) based on Ubuntu 24.04 and then try to run any netplan command (such as netplan apply, or netplan try), I get the following error message:
Failed to send reload request: 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/cli/core.py", line 58, in main
self.run_command()
File "/usr/share/netplan/netplan_cli/cli/utils.py", line 298, in run_command
self.func()
File "/usr/share/netplan/netplan_cli/cli/commands/apply.py", line 63, in run
self.run_command()
File "/usr/share/netplan/netplan_cli/cli/utils.py", line 298, in run_command
self.func()
File "/usr/share/netplan/netplan_cli/cli/commands/apply.py", line 255, in command_apply
subprocess.check_call(['udevadm', 'control', '--reload'])
File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['udevadm', 'control', '--reload']' returned non-zero exit status 1.
This seems to be related to systemd-udevd not running due to /sys not being read-only.
systemctl status udev
○ systemd-udevd.service - Rule-based Manager for Device Events and Files
Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static)
Drop-In: /usr/lib/systemd/system/systemd-udevd.service.d
└─syscall-architecture.conf
Active: inactive (dead)
TriggeredBy: ○ systemd-udevd-control.socket
○ systemd-udevd-kernel.socket
Condition: start condition unmet at Sun 2024-09-01 20:42:52 UTC; 24min ago
Docs: man:systemd-udevd.service(8)
man:udev(7)
Sep 01 20:42:52 plesk2 systemd[1]: systemd-udevd.service - Rule-based Manager for Device Events and Files was skipped because of an unmet condition check (ConditionPathIsReadWrite=/sys).
I looked through the discussions available on this topic. Frankly, I didn’t find a definitive answer on what to do about this. But I read on multiple occasions that making the container privileged and setting security.nesting to True should solve this issue albeit not being a recommended approach. Unfortunately, these configuration settings didn’t do anything for me.
It seems it’s possible to work around the issue by just starting systemd-udevd manually,
/lib/systemd/systemd-udevd --daemon
I don’t seem to have this issue on a Ubuntu 22.04 guest, by the way. Only 24.04 is affected.
Your help is appreciated.