I dug a bit deeper into this, and I think I found something after enabling `-d`  on `virt-install`:

I can see the ISO image (for cloud init) being created:

```
[Mon, 07 Nov 2022 15:49:59 virt-install 65103] DEBUG (cloudinit:67) Using user-data content from path=/home/jreimann/vms/user-data.yaml
[Mon, 07 Nov 2022 15:49:59 virt-install 65103] DEBUG (installerinject:90) Injecting src=/home/jreimann/.cache/virt-manager/boot/virtinst-7hda4pw9-meta-data dst=meta-data into media=/home/jreimann/.cache/virt-manager/boot/virtinst-wk2u3fnw-cloudinit.iso
[Mon, 07 Nov 2022 15:49:59 virt-install 65103] DEBUG (installerinject:90) Injecting src=/home/jreimann/.cache/virt-manager/boot/virtinst-8ebcvarl-user-data dst=user-data into media=/home/jreimann/.cache/virt-manager/boot/virtinst-wk2u3fnw-cloudinit.iso
[Mon, 07 Nov 2022 15:49:59 virt-install 65103] DEBUG (installerinject:71) Running iso build command: ['xorrisofs', '-o', '/home/jreimann/.cache/virt-manager/boot/virtinst-wk2u3fnw-cloudinit.iso', '-J', '-input-charset', 'utf8', '-rational-rock', '-V', 'cidata', '/home/jreimann/.cache/virt-manager/boot/tmpcyauj7n0']
[Mon, 07 Nov 2022 15:49:59 virt-install 65103] DEBUG (installerinject:73) cmd output: b"xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.\n\nxorriso : NOTE : Local character set is now assumed as: 'utf8'\nDrive current: -outdev 'stdio:/home/jreimann/.cache/virt-manager/boot/virtinst-wk2u3fnw-cloudinit.iso'\nMedia current: stdio file, overwriteable\nMedia status : is blank\nMedia summary: 0 sessions, 0 data blocks, 0 data,  402g free\nxorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules\nAdded to ISO image: directory '/'='/home/jreimann/.cache/virt-manager/boot/tmpcyauj7n0'\nxorriso : UPDATE :       2 files added in 1 seconds\nxorriso : UPDATE :       2 files added in 1 seconds\nISO image produced: 185 sectors\nWritten to medium : 185 sectors at LBA 0\nWriting to 'stdio:/home/jreimann/.cache/virt-manager/boot/virtinst-wk2u3fnw-cloudinit.iso' completed successfully.\n\n"
[Mon, 07 Nov 2022 15:49:59 virt-install 65103] DEBUG (installer:302) Have access to preferred scratchdir so nothing to upload
```

But then, once the installation is running, it will delete this:

```
Creating domain...                                                                                                                                                              |    0 B  00:00:00     
[Mon, 07 Nov 2022 15:57:13 virt-install 65785] DEBUG (installer:409) Removing /home/jreimann/.cache/virt-manager/boot/virtinst-t1lyv1_u-meta-data
[Mon, 07 Nov 2022 15:57:13 virt-install 65785] DEBUG (installer:409) Removing /home/jreimann/.cache/virt-manager/boot/virtinst-u6yoyjeg-user-data
[Mon, 07 Nov 2022 15:57:13 virt-install 65785] DEBUG (installer:409) Removing /home/jreimann/.cache/virt-manager/boot/virtinst-sincdevf-cloudinit.iso
[Mon, 07 Nov 2022 15:57:13 virt-install 65785] DEBUG (cli:265) Domain creation completed.
Domain creation completed.
```

Which to me, doesn't make any sense.

I guess the expectation is somehow that "upload"  (see above: DEBUG (installer:302) Have access to preferred scratchdir so nothing to upload) does not have access, and thus uploads something somewhere.

However, in a case where this isn't the case, this seems just broken. And I guess this make this a problem of virt-manager instead.

Thanks for the report. What's your full virt-install command?

Can you try adding `--tpm none`  and see if it makes a difference?
There's some weirdness with EFI firmware and --tpm lately that causes the boot to reset upfront, which screws up virt-install logic

I used a few commands, like this one here:

```
virt-install --name test --memory 4096 --os-variant detect=on,name=fedora-unknown --cloud-init user-data="$(pwd)/user-data.yaml" --disk=size=40,backing_store="$(pwd)/Fedora-Cloud-Base-36-1.5.aarch64.qcow2" --network bridge=virbr0 -d
```

Adding `--tpm none` doesn't seem to make a difference. I can see the ISO getting created in the logs, but then it is immediately gone.

I did notice a few odd things too. Like the fact that `--transient` doesn't seem to clean up the nvram data. Didn't dig into it, but as "transient" doesn't seem to work properly anyway, I didn't pursue that approach. I also noticed that it does an additional reset, despite adding `--noreboot`.

It's expected that the virt-install created cloud-init .iso is deleted. It's considered temporary media.

The VM is expected to boot with the cloud-init iso, while VM is running virt-install unlinks the ISO (which is fine, VM still has an open handle to the file), cloud-init process is run inside the VM, VM shutsdown, virt-install removes the ISO media from the VM XML config, subsequent VM runs don't attempt to use the iso.

So the iso media removal itself shouldn't be a problem.

However I know with other aarch64 cases at the moment, the VM does an initial reset upfront, triggered by UEFI and its 'Boot option restoration' message. This reset confuses virt-install, it thinks cloud-init already ran, and removes the ISO config from the VM XML. That could be why you are seeing unexpected results.

The `--tpm none` bit may prevent the initial reset. Did you confirm cloud-init isn't working as expected in that case, or did you just confirm logs show the iso is being deleted?

> The `--tpm none` bit may prevent the initial reset. Did you confirm cloud-init isn't working as expected in that case, or did you just confirm logs show the iso is being deleted?

I just checked the logs for the "deleted" message. But I also ran out of Pis (now that I have the actual setup I wanted to try working). So doing another test isn't that easy anymore.

I'm pretty sure this is the same root issue as 2133525

*** This bug has been marked as a duplicate of bug 2133525 ***