fedora: update cloud_kernel_options

[croissanne]

fedora: turn off systemd.firstboot for cloud images

Systemd 256 added a new feature which interactively queries on the
console for a user name and password if no regular user exists [1]. For
obvious reasons this is not ideal in cloud or server environments.

Fedora updated its kiwi descriptions for this reason, let's do the same
here [2].

[1]: https://github.com/systemd/systemd/commit/3ccadbce3358ba1db7ce5fa3f8dd17c627ffd93b
[2]: https://pagure.io/fedora-kiwi-descriptions/c/47dd0aa7615d847c06627007873b3d7e09bcd441

---

fedora: copy cloud_kernel_options from fedora

Let's just use the same kernel arguments as the official images [1].

[1]: https://pagure.io/fedora-kiwi-descriptions/blob/a6a0df3b3ac4a40bc434591467c30b4e42d254ce/f/teams/cloud/cloud.xml

[supakeen]

fedora: turn off systemd.firstboot for cloud images

Systemd 256 added a new feature which interactively queries on the
console for a user name and password if no regular user exists [1]. For
obvious reasons this is not ideal in cloud or server environments.

Fedora updated its kiwi descriptions for this reason, let's do the same
here [2].

[1]: https://github.com/systemd/systemd/commit/3ccadbce3358ba1db7ce5fa3f8dd17c627ffd93b
[2]: https://pagure.io/fedora-kiwi-descriptions/c/47dd0aa7615d847c06627007873b3d7e09bcd441

fedora: copy cloud_kernel_options from fedora

Let's just use the same kernel arguments as the official images [1].

[1]: https://pagure.io/fedora-kiwi-descriptions/blob/a6a0df3b3ac4a40bc434591467c30b4e42d254ce/f/teams/cloud/cloud.xml

This is fine; though we already block systemd-firstboot in other ways (just like kiwi) and our images currently don't trigger it.

Note also that in theory our images are actually Fedora Server images (hence the server- prefix) being created with the Cloud Package set. This should be aligned sometime (I have a local branch somewhere).

---

Overall, OK since it doesn't affect any actual deliverables to Fedora but I should really spend some time cleaning up and checking these definitions for parity fully.

[achilleas-k]

This is fine; though we already block systemd-firstboot in other ways (just like kiwi) and our images currently don't trigger it.

How do we block it currently? Because we (Sanne and I) both saw this happen in the AWS image when setting up the runners for Fedora 43 and I reproduced it with a local build.

[achilleas-k]

Thanks!! LGTM

[supakeen]

This is fine; though we already block systemd-firstboot in other ways (just like kiwi) and our images currently don't trigger it.

How do we block it currently? Because we (Sanne and I) both saw this happen in the AWS image when setting up the runners for Fedora 43 and I reproduced it with a local build.

We write an empty /etc/machine-id which means ConditionFirstboot isn't met; systemd-firstboot has this in its service file.

[supakeen]

This is fine; though we already block systemd-firstboot in other ways (just like kiwi) and our images currently don't trigger it.

How do we block it currently? Because we (Sanne and I) both saw this happen in the AWS image when setting up the runners for Fedora 43 and I reproduced it with a local build.

We write an empty /etc/machine-id which means ConditionFirstboot isn't met; systemd-firstboot has this in its service file.

Got the wires in my head crossed; we actually write uninitialized which does meet ConditionFirstboot; we then override it to write an empty file in the IoT and Minimal images.