Meeting started at 2026-07-08 15:30:18 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

spresti: Steven Presti (spresti)

!hi

Hristo Marinov: Hristo Marinov (hricky) - he / him / his

!hi

Timothée Ravier: Timothée Ravier (siosm) - he / him / his

!hi ravanelli

!hi

Cade: Cade Jacobson (cadejacobson)

!hi

jbtrystram: Jean-Baptiste Trystram (jbtrystram) - he / him / his

!hi

!hi

No Fedora Accounts users have the @ydesouza:matrix.org Matrix Account defined

!hi

rapneset: Rolv Apneseth (rapneset)

!hi

No Fedora Accounts users have the @ydesouza:matrix.org Matrix Account defined

!hi

No Fedora Accounts users have the @peytonrobertson:matrix.org Matrix Account defined

!hi

dustymabe: Dusty Mabe (dustymabe) - he / him / his

!hi

Angel Cervera Roldan: Angel Cervera Roldan (acervera)

We're coming up to the Mass Rebuild (2026-07-15) and proposal submission deadline for changes (2026-07-21)

Regarding the submissions, I have two comments on that. Firstly, unless anyone has any issues with this https://fedoraproject.org/wiki/Changes/IgnitionNativeButaneSupport I am going to move to submit it

marmijo gave a cookie to spresti. They now have 9 cookies, 3 of which were obtained in the Fedora 44 release cycle

Secondly, what is the threashold for needing to submit a change request? ie. bipins work for creating submodules https://src.fedoraproject.org/rpms/ignition/pull-request/147

https://github.com/coreos/ignition/pull/2239

jbtrystram gave a cookie to spresti. They now have 10 cookies, 4 of which were obtained in the Fedora 44 release cycle

rapneset gave a cookie to spresti. They now have 11 cookies, 5 of which were obtained in the Fedora 44 release cycle

acervera gave a cookie to spresti. They now have 12 cookies, 6 of which were obtained in the Fedora 44 release cycle

That's a good question. I'm also curious if this work would require a change request.

siosm gave a cookie to spresti. They now have 13 cookies, 7 of which were obtained in the Fedora 44 release cycle

ravanelli gave a cookie to spresti. They now have 14 cookies, 8 of which were obtained in the Fedora 44 release cycle

The only thresholds are for systems wide changes vs self contained changes

It's a bit "up to you" what you want to submit as a change request

If it impacts other developers or users of Fedora then making a change request is a good way to make it more visible

So I would not say that the Ignition spit needs a change request but that if we want to bring attention to it we should do one

> We need to know about disrupting changes coming to the next release to set the scope of release, but it also helps as marketing tool even for leaf changes

from https://docs.fedoraproject.org/en-US/operations/pgm_guide/changes/

or https://docs.fedoraproject.org/en-US/operations/changes_policy/

right. if a change is self contained, but has no user impact, then we can really choose to submit a change request or not

but...

if you potentially want users to know about it and start using it, then a change request is a good idea

i.e. non-CoreOS users to use Ignition (cloud working group has expressed interest in the past, or people building their own derived containers from bootc)

Ah, okay thats good to know. I feel like we would want visibility on it as well no? while its not the same type of UX as the butane to ignition change it would be nice to share?

I think it would be nice, but don't want to compel anyone to do the work (since change requests aren't zero work).

Okay, I will share that with bipin and see if he wants to make one or not.

It's been a while since we brought this one up, but the last status was to determine if we could support TPM (requires UEFI) on AWS AMIs while still supporting legacy instance types.

I spent some time validating that and posted my results here: https://github.com/coreos/fedora-coreos-tracker/issues/1193#issuecomment-4908089461

hmm

i'm inclined to just say we move forward with the change.

Essentially, TPM is only supported on certain instance types and we have to use `--boot-mode uefi`, so we wont be able to support legacy instance types with only one AMI

i'm inclined to just say we move forward with the change and make it the default (i.e. don't create a separate AMI)

I'm not against this, but it would mean we would stop supporting instance types that users may currently be using. We'd have to make sure that is well documented and announced clearly.

I think the one thing that would give me pause, is if there are no comparable "inexpensive" instance types.

only for new deployments?

> stop supporting instance types that users may currently be using

only for new deployments, right?

> stop supporting instance types that users may currently be using

yeah, if users can workaround this by booting and updating an older release that's not too bad I think

Something I did not realize: Can we do UEFI only (and not TPM) by default?

Is that more widely supported?

I think that was the `uefi-preferred` option

ah ok

which i take to mean: "use UEFI if you can, fallback to non-UEFI if you can't"

there's no `tpm-preferred` option is there :)

hum

We are already creating our AMIs with `uefi-preferred` for x86_64

ok, makes sense

then I don't think we should change things here. hopefully we make the new "UKI" image force the use of the TPM

we would switch the default later, once we are ready to unify the images again

Timothée Ravier: was does the tpm option give us?

it just guarantees that you can only launch the AMI on instances where a TPM is supported? or does setting the option actually cause a TPM to get attached to an instance where otherwise it would not get attached?

as far as I understand, if you set the TPM v2 flag on your AMI then you can only launch it on instance types where you can attach such a tpm

most fcos users on AWS won't use that until we have this integrated in the "UKI image"

so we would restrict the supported instance types for no gain

right, so it doesn't prevent launching on TPM instances, it just guarantees that you are on an instance that has a TPM (else it fails)

It guarentee that if you launch an instance from this AMI, you get a TPM 2.0

(I think that's what you said but I'm not sure)

That's my understanding, that the TPM flag restricts launches to instance types that support NitroTPM: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enable-nitrotpm-prerequisites.html#nitrotpm-instancetypes.

so my proposed is: we don't it now. We'll do it for the sealed/UKI images only

(and thanks a lot [marmijo](https://matrix.to/#/@marmijo:fedora.im) for the investigation work)

PROPOSED: "We won't enable TPM support on FCOS for the current AMIs, instead we'll apply it only to the sealed/UKI images when they are are ready"

(I have to drop, sorry)

Thanks for the input Timothée Ravier !

marmijo: might be worth mentioning in the comment in the ticket, that we already set uefi-preferred and for aarch64 uefi is the only option already

FYI i learned this week that meetbot understand !idea

and also updating the issue title to drop mention of UEFI (since that should already be the case)

marmijo: might be worth mentioning in the comment in the ticket, that we already set uefi-preferred for x86_64 and for aarch64 uefi is the only option already

Makes sense, I can update those two things

+1 to proposed (maybe linked to UKI ticket when you mention UKI)

+1 to proposed (maybe link to UKI ticket when you mention UKI)

Is that https://github.com/coreos/fedora-coreos-tracker/issues/1719?

I'm +1 to the proposed

+1

+1

marmijo: looks like the right ticket

Just noting here that Timothée Ravier voted +1 :)

!agreed: "We won't enable TPM support on FCOS for the current AMIs, instead we'll apply it only to the sealed/UKI images when they are are ready"

Thanks, all, for joining! Have a great day!