On Thu, Nov 21, 2019 at 5:21 PM Cole Robinson <crobinso@xxxxxxxxxx> wrote:
On 11/21/19 10:49 AM, Ryan Harper wrote:
> * Cole Robinson <crobinso@xxxxxxxxxx> [2019-11-20 17:48]:
>> Hi all. The purpose of this mail is to get some feedback on pending
> For some time now, cloud-init uses a systemd-generator to detect[4] on
> which platform it is running and determine if user-data or config
> has been provided and if so, enabling the cloud-init service, other
> wise it stays disabled. Your experience above is the primary reason
> for this feature as now booting a cloud image without any user-data
> should not mean the image hangs during boot.
>
> The feature has been around since 2017, cloud-init 17.1 and newer
> support this feature.
>
Interesting. I tested with this ubuntu image:
https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-amd64.img
And indeed, seems like it drops quite quickly to a login prompt when no
cloudinit data is passed in. And --cloud-init seems to work as expected.
So I wonder, why does Fedora 31 images still seem to hang, waiting for
network timeout? Is this something that needs to be explicitly enabled
in the disk image cloud.cfg?
It's likely a package build/install issue. There was a recent fix for
ensuring the path to ds-identify was correct on RedHat installs
Ryan
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
