Closed qmonnet closed 2 years ago
/build
/build
/build
/build-4.19
/build-4.9
/build-net-next
/build-net-next
That wasn't enough to fix it. Still seeing:
07:55:15 k8s1-1.23: Warning: apt-key output should not be parsed (stdout is not a terminal)
07:55:16 k8s1-1.23: OK
07:55:16 k8s1-1.23: E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 8859 (apt-get)
07:55:16 k8s1-1.23: E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
For example at https://jenkins.cilium.io/job/Cilium-PR-K8s-1.23-kernel-net-next/527/consoleFull for a pull request that did include the new VM images.
There must be some dark magic at play!
I'm not sure what re-installs or re-enables it, I didn't manage to find last time. One thing we could try is to disable them through the related config file, although I have no idea if we will have any more success (given that something seems to reinstall it, it might as well overwrite the config file, but I don't know).
Maybe worth checking that apt is indeed smart enough?
Yeah, that's another thing we can check/try.
Looking into this again, I can't find any unattended-upgrades
running locally.
@pchaigno Looking at the commit log for vagrant_box_defaults.rb
in Cilium, I see no commit between the 14th of January and the 10th of February. The current PR was merged on 24th January... So I guess we just forgot to switch to the new box in Cilium?
EDIT - Scratch this I'm wrong, the new report comes after we updated the defaults.
In the past, we added to the ubuntu/install.sh script some commands to disable the unattended-upgrades service when provisioning the VM. However, it seems that something is still re-enabling the unattended-upgrades, which sometimes hinders the launch of the VM because the apt lock is held by that process.
As an additional step to prevent the launch of unattended-upgrades, let's remove the package from the system.