sytemd-udev package upgrade breaks if udev is masked

Hi Simon,

Thanks for the detailed report!

For testing purposes, this can be reproduced this with standard LXD images by masking the systemd-udev.service unit, as you described.

Could you please confirm if from the Anbox perspective, for a workaround, is it OK to temporatily unmask/start the unit (due to restart), then upgrade the package, and stop/mask again?

For example:

lxc launch ubuntu:jammy jammy-udev-masked
lxc exec jammy-udev-masked -- su - ubuntu

$ dpkg -s udev | grep Version:
Version: 249.11-0ubuntu3.6

sudo systemctl mask systemd-udevd.service
sudo systemctl stop systemd-udevd.service

sudo apt update && sudo apt install -y udev

...
Setting up udev (249.11-0ubuntu3.7) ...
Failed to restart udev.service: Unit udev.service failed to load properly, please adjust/correct and reload service manager: File exists
See system logs and 'systemctl status udev.service' for details.
invoke-rc.d: initscript udev, action "restart" failed.
○ udev.service
     Loaded: error (Reason: Unit udev.service failed to load properly, please adjust/correct and reload service manager: File exists)
     Active: inactive (dead)
Warning: The unit file, source configuration file or drop-ins of udev.service changed on disk. Run 'systemctl daemon-reload' to reload units.
dpkg: error processing package udev (--configure):
 installed udev package post-installation script subprocess returned error exit status 1
dmesg: read kernel buffer failed: Operation not permitted
...

sudo systemctl unmask systemd-udevd.service
sudo apt install -f

sudo systemctl mask systemd-udevd.service
sudo systemctl stop systemd-udevd.service

Hey Mauricio,

> Could you please confirm if from the Anbox perspective, for a
> workaround, is it OK to temporatily unmask/start the unit
> (due to restart), then upgrade the package, and stop/mask again?

It's not that simple. We have prebuilt images we ship to users which run through an automated bootstrap process (see https://anbox-cloud.io/docs/exp/applications#bootstrap). As part of that process we apply pending security patches to ensure the images are up to date. This process fails with the latest udev update but it should have failed with older udev versions as well. It only became a problem now due to bad timing (us not having released a new image and the security patch being rolled out). We will ship a new patch release next Wednesday (Mar 15) which will then include the updated udev package and also a tweak to the automatic process to prevent this from happening again.

For our users we have a simple knob in our management service to turn off the process of applying pending updates to mitigate the situation till the we roll out new images next week.

Hey Simon. Understood, thanks for the clarification!