You can always check https://images.linuxcontainers.org, only cloud variants have cloud-init, if there is no such variant (only default), then no cloud-init.
We usually try to have cloud-init images whenever official up to date packages for it are available in the distro, maybe things changed with Arch but the current state of things suggest it wasn’t last we checked.
Ah that does make sense. It seems cloud-init for arch is actually on 20.2-1 and has been out of date since it was flagged on 2020-09-24. It would also appear Gentoo has the same problem cloud-init-21.1.
Does cloud-init have to be the latest version? I’ll try to find out upstream why Arch Linux is lagging behind, then.
On a side note it’s nice to see cloud-init in Alpine Linux. Currently edge repo, so maybe next stable release 3.13 it will be in main repo.
* Is there any way to add a root account etc without cloud-init? I read somewhere default accounts are not shipped with any images. I suppose the only way is to boot an archiso media, chroot to the environment and add a user.
* I also thought about creating my own image with cloud-init. If the package is slightly out of date is this likely to cause issues? I’ll try to work with upstream to get this up to date. It’s nice to have a rolling release distribution with cloud-init.
I assume something like this can be used to boot an environment from a live-cd in order to add some users. For example the archlinux instance doesn’t have cloud-init, so I expect manually adding users is a way?
The environment will automatically boot from the primary disk. It seems hitting ESC isn’t enough to bring up the boot menu. Did I need to change some of the boot options?
That’s an issue with your Linux distribution, your build of qemu wasn’t built with spice support.
I believe I had the LXD maintainer on Arch mention that to us earlier so there may be an open bug report against qemu in Arch to have this fixed.
That’s an issue with your Linux distribution, your build of qemu wasn’t built with spice support.
I believe I had the LXD maintainer on Arch mention that to us earlier so there may be an open bug report against qemu in Arch to have this fixed.
This is upstream qemu 5.2.0 bug. I spent a few hours to isolate the first bad comit.
Does your kernel have appamor support? As we check for the existence of /sys/kernel/security/apparmor and the aa-exec command as indicating that AppArmor is supported.