blackboxsw
commented
1 month ago Thank you @areis422 for filing this bug and making cloud-init better.
I was able to reproduce a similar behavior using LXD and the following script and it looks like LXD w. ubuntu-minimal images was able to succeed, with either software-common-properties and just polkitd as you mentioned.
cat> issue-5608.yaml <<EOF
#cloud-config
bootcmd:
- [ cloud-init-per, instance, removeResolveConf, rm, /etc/resolv.conf ]
- [ cloud-init-per, instance, relinkResolveConf, ln, -s, /run/systemd/resolve/resolv.conf, /etc/resolv.conf ]
- [ cloud-init-per, instance, aptUpdate, apt-get, update, -qyy ]
- [ cloud-init-per, instance, aptPurgeNeedRestart, apt-get, autoremove, -qyy, --purge, needrestart ]
- [ cloud-init-per, instance, aptInstallAptUtils, bash, -c ,"export DEBIAN_FRONTEND=noninteractive; apt-get install --no-install-recommends -qyy apt-utils dialog git ca-certificates cargo landscape-common libssl-dev pkg-config **polkitd**;" ]`
EOF
lxc launch ubuntu-minimal:noble issue-5608 -c cloud-init.user-data="$(cat 5608.yaml)"
lxc exec issue-5608 -- cloud-init status --wait --format=yaml
lxc exec issue-5608 -- cloud-init analyze show
lxc exec issue-5608 -- grep bootcmd /var/log/cloud-init.logunable to capture logs since boot never finishes, but can be reproduced every time. The reason for including it in bootcmd, is otherwise the apt sources via ppas don't get ingested correctly.
Can you expand on this failure symptom you are seeing so I can better understand the use-case here. What apt sources config is being provided in user-data that breaks for you? The reason I ask as well is because generally we'd guide people to use the top-level packages: key for manipulating/installing removing packages on the system instead of trying to run apt operations directly in bootcmd or runcmd. I also confirmed that invoking these commands directly in runcmd: succeeds without blocking.
I'm guessing this issue is directly related to polkitd.postinst calling invoke-rc.d dbus reload || true which could be blocking due to dbus not being ready yet that early in boot because dbus.service doesn't start until After=sysinit.target which is After=cloud-init.service which is the systemd unit that runs the bootcmd module you are trying to use. So basically you have a systemd service deadlock in this case.
I also see the following blocked process in the process table confirming the suspicion that dbus isn't ready yet and your bootcmd is blocking on that.
/bin/sh /usr/sbin/invoke-rc.d dbus force-reload
So, let's see if we can get to the reasons behind why the typical packages: directives don't meet your needs with any apt sources that need to be configured via user-data to understand if there is an alternative to bootcmd that will meet your needs.
areis422
Bug report
When installing any packages that depend on packagekit during bootcmd, process hangs on bootcmd, even if DEBIAN_FRONTEND is set to noninteractive
Steps to reproduce the problem
Adding "echo \"FRONTEND=${DEBIAN_FRONTEND}\"" ends up printing noninteractive, so the environment variable is being exported correctly.
Example Hang
Environment details
cloud-init logs
unable to capture logs since boot never finishes, but can be reproduced every time. The reason for including it in bootcmd, is otherwise the apt sources via ppas don't get ingested correctly. I also use the Ubuntu minimal images from AWS. It DOES NOT hang when software-properties-common is defined in the package list, but at that point, it's too late. 24.04 minimal 22.04 minimal