Meeting started at 2026-07-15 15:29:04 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

Nemric: Emeric Chassagne (nemric)

!hi

Tiago Bueno: Tiago Bueno (tlbueno) - he / him / his

!hi

!hi

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

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

Hey team! Good afternoon, let's wait a few minutes so more people can join us :)

!hi

Sorry, could not get info from FASJSON (code 500)

!hi

marmijo: Michael Armijo (marmijo)

!hi

!hi

Cade: Cade Jacobson (cadejacobson)

Sorry, could not get info from FASJSON (code 500)

I think we can start with the actions items from the last meeting

!hi

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

!hi

rapneset: Rolv Apneseth (rapneset)

!hi

So, we have two actions items from the last meeting.

First, is from marmijo: Update the AWS TPM tracker issue (#1193) with the decision to implement TPM support in the future sealed/UKI images and link to the relevant UKI ticket (#1719).

First is from marmijo: Update the AWS TPM tracker issue (#1193) with the decision to implement TPM support in the future sealed/UKI images and link to the relevant UKI ticket (#1719).

Do we have any updates on this one?

I added the decision from the previous meeting to the tracker, but I forgot to link the UKI ticket. I'll do that now

!hi

Angel Cervera Roldan: Angel Cervera Roldan (acervera)

Thank you marmijo to work on this!

Done!

Any news on this one?

The next one is from @spresti:

> Follow up with bipin to see if he wants to create a change proposal for the Ignition submodule work to increase its visibility.

Not sure if spresti is here today, so I think we can have updates with him about it on our channel after the meeting.

So we can go to our topics, first our review on Fedora 45 release Schedule:

Seems like we are having the Mass Rebuild RPM today.

which means `rawhide` may become turbulent for a bit

So more crashes?

I'd like to know if everything is ok about this change proposal before the dead line, I need you ^^

https://fedoraproject.org/wiki/Changes/CoreOS_default_to_enable_systemd-oomd_and_swap_on_Zram

Let's see it later if needed

🇵🇱 | Nik Nikovsky [unreachable on 26/8/26]: I was referring to our `rawhide` stream of CoreOS, which is really for development/testing only.

I only mean that our CI might start breaking because of so many changes coming in. Some of them may be bugs we need to get fixed. Some may be tests we need to adjust to new intended behavior.

jbtrystram: does that change proposal look good from your side?

Nemric: I don't see anything specific that I would change.

I think at some point we need to change the state so that the "wrangler" will pick it up

yesh it LGTM

yeah it LGTM

Nice, do we have any other insights about our schedule?

If not, I think we can go ahead and see what we have to discussion in our tracker repository.

jbtrystram: can you help Nemric move the change request to the next step in the process?

yeah

We're used to work together 😉

Good!

got it !

```

<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

<!-- When your change proposal page is completed and ready for review and announcement -->

```

that's done ! thanks

Ah yes, we thought this was worth bringing up again due to the test added in https://github.com/coreos/fedora-coreos-config/pull/4231 actually failing on aarch64 rawhide (see https://github.com/coreos/fedora-coreos-tracker/issues/2179)

Potentially it will start passing again with that ignition binary size decrease but we're really running up against the limits of the space in our /boot partition

yep. :(

Do we have any action items that we could create related to this issue?

honestly this particular issue is worth it's own team of people working on it. It's a significant effort to understand all the history involved and pull off a proper migration :(

we keep kicking the can, because the problem is a really thorny one

Ah ok. Well if we start a team to work on it I'd be willing to join at least

I am interested to join as well!

I am up to join on it as well.

Maybe we can set an action item to come up with a list of requirements for the effort?

!action: Create a list of requirements to measure the efforts related to increase size of our /boot partition for new installs issues.

Do we have any other ideas for this issue?

That should be a good start

Agree!

So, lets go to our open floor!

https://github.com/coreos/afterburn/pull/1264

Plugging this PR again, if anyone has time for review! We made some changes to make the logic a little less Azure-specific in case other providers would want to use the same functionality and to match the existing repo a little better. Would appreciate any feedback or thoughts on it!

What is the best way to handle such issue discovered on `next` stream that finally land on `stable` ?

https://github.com/coreos/fedora-coreos-tracker/issues/2176

Peyton Robertson: 👍️ - I approved the CI to run

Peyton Robertson: thanks, I'll have a look and give spresti a ping about it

Nemric: what question are you asking?

i.e. "how can we do better next time?" or "what can we do now about a failing service on `stable`?"

How can we do better next time 😉

That one should have just been pinned faster, fully on me

That service is safe to ignore though, currently it's not very helpful anyway due to https://github.com/coreos/fedora-coreos-tracker/issues/1623

Ignore / disable

I'm just asking to know the best process to use as I'm running `next` nodes to see errors that happens

rapneset: ehh. this is a community - I wouldn't put everything on your shoulders

Nemric: I guess my advice for next time is to raise the issue and be louder about it. Maybe you did that this time, I can't remember

no one to blame ! perhaps the process is itself not yet perfect 😉

suggest a test that will catch the same problem in the future.

of which, maybe we have one now?

I did just create the issue about `next stream` ... not loud enough 😄

In progess, needs confirmation it works on other arches, dowstream, etc.: https://github.com/coreos/fedora-coreos-config/pull/4240

No, you did also post in the matrix channel about it to be fair, which is how I first saw it

this problem occurs when the timer trigger the update service ... testing it would mean waiting for a 24h running CoreOS

this problem occurs when the timer triggers the update service ... testing it would mean waiting for a 24h running CoreOS

It occurs when running the service directly too

Which is what the test should check

is it realistic to write a test about every service that runs in CoreOS ?

Yes, when I did post it to matrix, I was thinking about a transcient problem, after days I did create the issue

for example most services run on boot and will show up as failed if they don't start (and basic tests will catch that).

jbtrystram: I would say no. it's not. but there are special cases

jbtrystram: probably not I guess but this one seems worth testing since it's for fwupd

IIRC we don't mount /boot/efi on purpose ( I don't know what it is though )

this test only runs after 24h - so our CI didnt' catch it

This service is just making some requests over the network

so we could add a test for it. or we could say we don't care about the use case and either disable it or just let it pass through

It doesn't need /boot/efi

ah, the issue linked above made me thought so. Sorry

It's a bit useless if you can't actually update anyway, don't get me wrong, but that's what I'm working on now so hopefully it will work at some stage

rapneset: agree. Thank you for caring

I don't know, but as I'm using `next` nodes every weeks I and others can see new issue at early stage

I'm asking about the best way to be louder ^^

I don't know, but as I'm using `next` nodes every 2 weeks I and others can see new issue at early stage

I'm asking about the best way to be louder ^^

Probably bringing it up in a community meeting I'd say

that's a good solution 😉

Folks, we are already out of time. I appreciate the participation and please feel free to continue our discussions in the channel. Thank you all to join us today and see you next week!

Thanks for hosting Yasmin de Souza

Issue + FedoraCoreOS matrix channel is as loud as it can get I'd say

I'd say there's more of us looking at the community meeting than regularly checking the coreos matrix, don't you think?

thanks Yasmin de Souza and all 🙂

Thanks Yasmin de Souza

i dont know why is not ending the meeting 😅

I guess we're trapped in the meeting forever now

yes, i think we are

Hey meetbot...

I am definitely checking the coreos matrix room more often than once a week

Thanks everyone, have a good rest of the day !

come on meetbot!

that's very strange

let try other tag to see what is the problem

Fair enough yes, but I usually see all of a community meeting, but not all of the matrix feed every week

meetbot is french and is on strike 🤣

All other stuff is working, but doesnt want to finish the meeting haha

you're all locked in here with me now

nirik: do you know what's going on here?

meetbot won't close the meeting

step one: don't panic. ;)

I'll take a look.

I know a lot of worst situations !

it's unable to get the fas id of the user ending the meeting. Not sure why. I'm restarting it's pod.