server cloud image for ARM64 doesn't support nocloud target in cloud-init

Can you please include cloud-init logs? I don't have an Apple M1 to reproduce this on.

I can try to provide the console output for the emulated ARM environment on my Intel-based Mac. Would that be enough?

The emulated arm NoCloud boot succeeded to add the user on Intel, correct? Therefore I don't think that would be useful. I think that the failed ARM emulated or virtualized logs would be required.

The problem is that when it fails, I can’t access the log :(

/PA

> El 2 may 2023, a las 8:47, Brett Holman <email address hidden> escribió:
>
> The emulated arm NoCloud boot succeeded to add the user on Intel,
> correct? Therefore I don't think that would be useful. I think that the
> failed ARM emulated or virtualized logs would be required.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2018178
>
> Title:
> server cloud image for ARM64 doesn't support nocloud target in cloud-
> init
>
> Status in cloud-init:
> Incomplete
>
> Bug description:
> Use case:
>
> To provide students with a reliable way of creating a VM for the
> laboratory activities regardless of the platform they have, I use
> cloud-init to automate the VM creation process. This works nicely on
> Intel-based devices, but the number of students with ARM-based Macs is
> growing.
>
> HW:
>
> Macbook Pro with the UTM virtualisation app version 4.2.5
> Tested both on Intel and Apple M-1/M-2 HW
>
> Prerequisite:
>
> Simple cloud-init CDROM iso image that creates a user in the VM (in
> real life, it configures the VM installing packages, config files and
> scripts the students need for their activities.
>
> Procedure:
>
> 1.- Download the ubuntu-jammy-server QEMU image
> 2.- Expand the image to a 20G drive
> 3.- On UTM create a new VM (emulating when CPU != target of the image else virtualising)
> 4.- Attach cloud-init to CDROM unit
> 5.- Subtitute default drive created by UTM with expanded server image
> 6.- Boot the VM
>
> The different modes and experiment results:
> (OK meaning user set; KO meaning user not defined)
> Horizontal is same image different platform/mode
>
> Intel ARM
> Intel Virtualise/OK Emulate/OK
> ARM Emulate/KO Virtualise/KO
>
> When the process succeeds, the log shows that the cloud-init looked
> for a NoCloud source. When the process failed, the cloud-init process
> doesn't show any message realted to the NoCloud source
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/2018178/+subscriptions
>

> The problem is that when it fails, I can’t access the log :(

Understood, that's a frustrating.

I assume by this that you mean that you cannot log into the VM instance, since the user wasn't provisioned? If so, I think there may be a workaround. After the virtual machine boots, the log file on the booted ISO should be modified. If you can mount this ISO (after it has been booted), then the log files should be accessible. If you're not sure how to do this (or if MacOS isn't able to mount Linux images), I can give it a try if you're willing to share this ISO.

Hi,

The ISO is mounted as a read-only file system… So the trick may be to generate it as a FAT32 system cloud-init may write on… right. This will need a bit of thinking and time I don’t have right now. Give me some time and I’l report back when I have a solution…

Thanks for the support :-)
Best, /PA

> El 2 may 2023, a las 9:40, Brett Holman <email address hidden> escribió:
>
>> The problem is that when it fails, I can’t access the log :(
>
> Understood, that's a frustrating.
>
> I assume by this that you mean that you cannot log into the VM instance,
> since the user wasn't provisioned? If so, I think there may be a
> workaround. After the virtual machine boots, the log file on the booted
> ISO should be modified. If you can mount this ISO (after it has been
> booted), then the log files should be accessible. If you're not sure how
> to do this (or if MacOS isn't able to mount Linux images), I can give it
> a try if you're willing to share this ISO.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2018178
>
> Title:
> server cloud image for ARM64 doesn't support nocloud target in cloud-
> init
>
> Status in cloud-init:
> Incomplete
>
> Bug description:
> Use case:
>
> To provide students with a reliable way of creating a VM for the
> laboratory activities regardless of the platform they have, I use
> cloud-init to automate the VM creation process. This works nicely on
> Intel-based devices, but the number of students with ARM-based Macs is
> growing.
>
> HW:
>
> Macbook Pro with the UTM virtualisation app version 4.2.5
> Tested both on Intel and Apple M-1/M-2 HW
>
> Prerequisite:
>
> Simple cloud-init CDROM iso image that creates a user in the VM (in
> real life, it configures the VM installing packages, config files and
> scripts the students need for their activities.
>
> Procedure:
>
> 1.- Download the ubuntu-jammy-server QEMU image
> 2.- Expand the image to a 20G drive
> 3.- On UTM create a new VM (emulating when CPU != target of the image else virtualising)
> 4.- Attach cloud-init to CDROM unit
> 5.- Subtitute default drive created by UTM with expanded server image
> 6.- Boot the VM
>
> The different modes and experiment results:
> (OK meaning user set; KO meaning user not defined)
> Horizontal is same image different platform/mode
>
> Intel ARM
> Intel Virtualise/OK Emulate/OK
> ARM Emulate/KO Virtualise/KO
>
> When the process succeeds, the log shows that the cloud-init looked
> for a NoCloud source. When the process failed, the cloud-init process
> doesn't show any message realted to the NoCloud source
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/2018178/+subscriptions
>

> Give me some time and I’l report back when I have a solution…

Sounds good to me. Let me know if you get any logs that we can work with.

Hi there. I am also hitting this bug.
I have a few more information that can be of use.
I am getting this error:
cloud-init[654]: 2023-05-07 22:01:35,746 - url_helper.py[ERROR]: Timed out, no response from urls: ['http://[fe80::a9fe:a9fe]/openstack', 'http://169/254.169.254/openstack']

Seems that the datasource is wrong.

I can solve the problem by addding -smbios type=1,serial=ds=nocloud-net to my qemu command.

Thanks! The main issue for me is that I don't need that on Intel-based
images... Why should it be different on ARM?

/PA

On Mon, 8 May 2023 at 00:10, Julien Malka <email address hidden>
wrote:

> Hi there. I am also hitting this bug.
> I have a few more information that can be of use.
> I am getting this error:
> cloud-init[654]: 2023-05-07 22:01:35,746 - url_helper.py[ERROR]: Timed
> out, no response from urls: ['http://[fe80::a9fe:a9fe]/openstack', '
> http://169/254.169.254/openstack']
>
> Seems that the datasource is wrong.
>
> I can solve the problem by addding -smbios type=1,serial=ds=nocloud-net
> to my qemu command.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2018178
>
> Title:
> server cloud image for ARM64 doesn't support nocloud target in cloud-
> init
>
> Status in cloud-init:
> Incomplete
>
> Bug description:
> Use case:
>
> To provide students with a reliable way of creating a VM for the
> laboratory activities regardless of the platform they have, I use
> cloud-init to automate the VM creation process. This works nicely on
> Intel-based devices, but the number of students with ARM-based Macs is
> growing.
>
> HW:
>
> Macbook Pro with the UTM virtualisation app version 4.2.5
> Tested both on Intel and Apple M-1/M-2 HW
>
> Prerequisite:
>
> Simple cloud-init CDROM iso image that creates a user in the VM (in
> real life, it configures the VM installing packages, config files and
> scripts the students need for their activities.
>
> Procedure:
>
> 1.- Download the ubuntu-jammy-server QEMU image
> 2.- Expand the image to a 20G drive
> 3.- On UTM create a new VM (emulating when CPU != target of the image
> else virtualising)
> 4.- Attach cloud-init to CDROM unit
> 5.- Subtitute default drive created by UTM with expanded server image
> 6.- Boot the VM
>
> The different modes and experiment results:
> (OK meaning user set; KO meaning user not defined)
> Horizontal is same image different platform/mode
>
> Intel ARM
> Intel Virtualise/OK Emulate/OK
> ARM Emulate/KO Virtualise/KO
>
> When the process succeeds, the log shows that the cloud-init looked
> for a NoCloud source. When the process failed, the cloud-init process
> doesn't show any message realted to the NoCloud source
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/2018178/+subscriptions
>
>

--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Julien, do you have the ability to run "cloud-init collect-logs" (with a -u if you have no sensitive userdata)? The resulting tarball would be really helpful. The log line you posted is interesting, but may not actually be a problem as under non-x86, cloud-init will try to detect openstack but then move on to remaining datasources if it can't retrieve any openstack metadata.

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/4106