Ever since I’ve been using the cloudimage version for easier automation (for a couple of months), I’ve noticed that there’s a very long booting delay. I’ve been using the ova version of Ubuntu 22.04 (https://cloud-images.ubuntu.com/jammy/current/). I’m not sure where this is coming from, initially I thought it might be related to it identifying a component as fd0 (as this is what is shown when the booting process is delay), but it’s really not clear.
A fragment from journalctl -b0 shows:
Jun 16 10:57:31 omni-kubernetes-template sudo[1268]: packer : TTY=tty1 ; PWD=/home/packer ; USER=root ; COMMAND=/usr/bin/su -
Jun 16 10:57:31 omni-kubernetes-template sudo[1268]: pam_unix(sudo:session): session opened for user root(uid=0) by packer(uid=1000)
Jun 16 10:57:31 omni-kubernetes-template su[1270]: (to root) root on pts/0
Jun 16 10:57:31 omni-kubernetes-template su[1270]: pam_unix(su-l:session): session opened for user root(uid=0) by packer(uid=0)
Jun 16 10:57:40 omni-kubernetes-template multipathd[474]: sda: not initialized after 3 udev retriggers
Jun 16 10:57:41 omni-kubernetes-template multipathd[474]: sda: add missing path
Jun 16 10:57:41 omni-kubernetes-template multipathd[474]: sda: failed to get sysfs uid: Invalid argument
Jun 16 10:57:41 omni-kubernetes-template multipathd[474]: sda: failed to get sgio uid: No such file or directory
Jun 16 10:57:41 omni-kubernetes-template multipathd[474]: sda: no WWID in state "undef
Jun 16 10:57:41 omni-kubernetes-template multipathd[474]: ", giving up
Jun 16 10:57:41 omni-kubernetes-template multipathd[474]: sda: check_path() failed, removing
Jun 16 10:58:17 omni-kubernetes-template systemd[1]: Starting Ubuntu Advantage Timer for running repeated jobs...
Jun 16 10:58:18 omni-kubernetes-template systemd[1]: ua-timer.service: Deactivated successfully.
**Jun 16 10:58:18 omni-kubernetes-template systemd[1]: Finished Ubuntu Advantage Timer for running repeated jobs.
**Jun 16 11:01:56 omni-kubernetes-template systemd[1]: Starting Download data for packages that failed at package install time...
Jun 16 11:01:57 omni-kubernetes-template systemd[1]: update-notifier-download.service: Deactivated successfully.
Jun 16 11:01:57 omni-kubernetes-template systemd[1]: Finished Download data for packages that failed at package install time.
Jun 16 11:02:31 omni-kubernetes-template systemd[1]: Reloading.
Jun 16 11:02:32 omni-kubernetes-template systemd[1]: Mounting Mount unit for snapd, revision 19361...
Jun 16 11:02:32 omni-kubernetes-template systemd[1]: Mounted Mount unit for snapd, revision 19361.
As you can see (marked with *) there’s a delay of more than 2 minutes and a half which I can’t explain. I’m not sure where it’s coming from.
systemd-analyze blame shows:
5min 30.152s snapd.seeded.service
13.925s systemd-networkd-wait-online.service
2.047s snap.lxd.activate.service
But I’m not sure that snapd.seeded is actually to blame for the boot delay. Any ideas how I can debug this further so that I can find what causes this?
I’m running this in vSphere 6.7.0.54000 and I’m provisioning the virtual machine with a simple cloud-init config which runs fine:
#cloud-config
users:
- default
- name: packer
groups: sudo
lock_passwd: false
ssh_authorized_keys:
- ssh-ed25519 ssh-key
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
passwd: $6$qhash/
Thank you!