Meeting started at 2024-08-28 16:26:50 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

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

we're 5 minutes early so let's give some time for people to join

Sure! I will be waiting for people to join!

we're ~5~ 3 minutes early so let's give some time for people to join

!hi

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

we're ~~5~~ 3 minutes early so let's give some time for people to join

we're 3 minutes early so let's give some time for people to join

!hi

Hristo Marinov (hricky) - he / him / his

!hi

None (jlebon)

note: i will have to drop in half an hour today

!hi

Dusty Mabe (dustymabe) - he / him / his

!hi

Michael Armijo (marmijo)

!HI

!hi

David Duncan (davdunc) - he / him / his

I don't think we have any action items for the last meeting so lets cover the topics from the tracker repository.

some prior discussion on this in https://github.com/coreos/fedora-coreos-tracker/issues/628

i don't think the person that opened the issue is here today

So this is about including `lspci` in the base imge

So this is about including `lspci` in the base image

!hi aaradhak

Aashish Radhakrishnan (aaradhak)

i have to admit `lspci` is pretty basic functionality

IMO

to summarize the discussion on the issue, lspci works from a privileged container but is very tiny, and could be useful to debug networking issues (which could prevent running said container)

It feels to me that this would be useful but there isn't a strong case to include it by default

no strong opinion either way. probably worth adding

Looks like Container Linux used to have it: https://github.com/coreos/bugs/issues/2578

and it looks like it's in Flatcar right now

+1 for inclusion from me

Should we make a voting for this?

yes!

Looks like would be a nice thing to have in the base image. So +1

+1

+1 for inclusion

+1

+1

+1

I think we all agree so lets take note on this.

It's less than 200KB on the disk

+1

!agreed: Include pciutils package

!agreed: Include pciutils package

i think without the colon

🎉

no ":"

Nice, thank you :)

Next topic

With the switch to building our disk images via osbuild, some files are not labeled correctly

This is silent right now as the SELinux policy has bootupd in permissive mode

but this will break in F41

so we need to fix this (and fix existing nodes) before F41

or on the F41 barrier

i wrote a summary in https://github.com/coreos/fedora-coreos-tracker/issues/1771#issuecomment-2305618100

https://github.com/coreos/fedora-coreos-tracker/issues/1772 is related as well

hmm, it's weird that CI didn't catch this. we do have bootupd tests

definitely as part of this, we should check why CI didn't fail and strengthen it as needed

do we catch selinux denials (even permissive ones) in CI?

in f41+ it's not permissive

cc Michael Nguyen

i know at one point we were making progress to having a test for that, but I forget if we ever enabled it or completed it

yeah, i filed https://github.com/coreos/coreos-assembler/issues/3837 related to that

so Jonathan Lebon does that cover the "we should check why CI didn't fail and strengthen it as needed" ?

So it looks like we are missing something in our osbuild pipeline but I could not see what from a quick look

or are you referring to something else?

dustymabe: something else :)

i'm wondering why our bootupd tests didn't fail when it was no longer permissive in rawhide

when rawhide was f41

travier: I think achileas hints at it in https://github.com/coreos/fedora-coreos-tracker/issues/1771#issuecomment-2263260317

how recently did the selinux policy land that made them not permissive?

https://github.com/fedora-selinux/selinux-policy/commit/0cbc7da8130fd7cf030ab61f68a3eb449a8d6391

https://github.com/fedora-selinux/selinux-policy/pull/2153

ok, and in f42 bootupd tests are failing?

not failing as far as I know

right, it hasn't been failing this whole time, including now

travier: thanks for linking https://github.com/coreos/fedora-coreos-tracker/issues/1772, i had missed that. seems like we should fix them together

https://github.com/coreos/fedora-coreos-config/blob/testing-devel/tests/kola/boot/bootupd

we only have a basic test as far as I can see

ok, then yes.. when we fix this we should make sure we have a test in place that fails when it is not yet fixed first

travier: where you saw this, was it `bootupctl status` failing, or actually updating the bootloader?

ahhh, https://bugzilla.redhat.com/show_bug.cgi?id=2300306 does a bootloader update, which is probably the determining factor

in https://github.com/coreos/bootupd/issues/694

we don't have a test for that currently

I'm filling an issue

yeah, clearly we should also check that the output of `bootupctl status` makes sense :)

we run `bootupctl status` in the upgrade test: https://github.com/coreos/fedora-coreos-config/blob/f5ea8ce3c5b2fcc23aca646885ceaae134936e48/tests/kola/upgrade/extended/test.sh#L148

yeah, we run it too in the bootupd test, but only that the command succeeds, not what it prints

e.g. in the context this test is run, it would work to add e.g. `| grep $(rpm -q grub)` on applicable arches

I don't think there is more to discuss about this one. It "just" needs work

Nice, lets go for the next one.

!topic tracker: Fedora 41 changes considerations

I ran the script this morning and there were no new changes

a few changes are about to be dropped / moved to F42

but nothing that should impact us

we should talk about composefs

have to step away

See you, Dusty!

it's being pulled back for atomic desktops, but i'm hopeful we can land it in f41 for coreos

reviewed https://github.com/coreos/fedora-coreos-config/pull/3009 yesterday. it looks sane overall to me

does anyone have concerns with trying to land it in f41?

I've been running Fedora Kinoite with composefs enabled approximately 2 months now without issues. It's not the same as Fedora CoreOS, but close.

I've been running Fedora Kinoite with composefs enabled for approximately 2 months now without issues. It's not the same as Fedora CoreOS, but close.

i'll update this PR and open it agains testing-devel tomorow morning to get a fresh CI run on it

travier: that's good to hear. i still need to migrate my silverblue

we also need to write a bit of documentation on how to turn it off (necessary to the kdump case)

Jonathan Lebon: Note that is comes with risks for Atomic Desktops

Jonathan Lebon: be warry, I had to reinstall my machine !

jbtrystram: sounds good. update PR, let rawhide CI run to validate, then change PR base to testing-devel

Can we go to the next topic?

https://gitlab.com/fedora/ostree/sig/-/issues/35#note_1986555833

yeah, saw that. thanks!

we should definitely be ready to pull it out though if once it hits next there are other issues that can't be fixed in time

!topic tracker: Rebase onto Fedora 41

How are we doing on branched?

looks like https://github.com/coreos/fedora-coreos-tracker/issues/1779 is still an issue

i think that has been fixed

There hasnt been any response on the BZ that i've seen.

hmm, but testiso tests are passing in the pipeline?

I'm a bit disappointed by the "turn everyone off 1 months before the freeze" of the selinux maintainers

I'm a bit disappointed by the "turn everyone off permissive 1 months before the freeze" of the selinux maintainers

I'm a bit disappointed by the "turn everyone off permissive 1 months before the freeze" of the SELinux maintainers

travier: yeah, i personally feel like a fedora change was needed there

Feels to me those are prime candidates for a local override that turn them back to permissive until we have the time to investigate

unrelated: i think we should file GH issues for selinux stuff, as mentionned in https://github.com/fedora-selinux/selinux-policy?tab=readme-ov-file#how-to-report-issues

there is no security benefits here

this flew totally under the radar

The affected tests are denylisted in rawhide and branched still. I can try to run them locally to see if they are still failing.

> hmm, but testiso tests are passing in the pipeline?

marmijo: oh wow, missed that

It's far worse if we regress on functionality here for those tests so I think we should do the permissive change asap

but hey, at least we're on systemd v256 now. the only fallout so far has been https://github.com/coreos/fedora-coreos-tracker/issues/1786 (which is also selinux-policy related)

Sorry about that. Everyone was on PTO when I did it: https://github.com/coreos/fedora-coreos-config/pull/3100

marmijo: no fault of yours

I have https://github.com/fedora-selinux/selinux-policy/pull/2257 ready

travier: agreed

@travier how can we turn permissive for certain policy only and not the whole system ?

ah, it's just there. Thanks

Jonathan Lebon: recently did it for SCOS: https://github.com/openshift/os/pull/1568

Jonathan Lebon recently did it for SCOS: https://github.com/openshift/os/pull/1568

travier: we can do that, but let's try to reach out to the selinux-policy maintainers first to try to do this the proper way (either fixing the bug, or merging your PR)

marmijo: could you make a PR with something similar to https://github.com/openshift/os/pull/1568 but for the domains in https://github.com/fedora-selinux/selinux-policy/pull/2257

marmijo: could you make a PR with something similar to https://github.com/openshift/os/pull/1568 but for the domains in https://github.com/fedora-selinux/selinux-policy/pull/2257 instead?

Sure thing! I'll get started on that after the meeting

We have only a few minutes, should we discuss the last topic from the tracker repository or have a quick open floor before finish the meeting?

let's go to open floor

Well, anyone has anything to say? If not, its already ending time.

https://github.com/coreos/fedora-coreos-tracker/issues/1553 looks like this one has been fixed but is waiting for an afterburn release

looks like https://github.com/coreos/afterburn/issues/1095 was filed, but not yet actioned. Yasmin Valim de Souza is that planned to be done soon?

Yup! I think there's a new release issue in the afterburn repo

Yes, it is!

Thanks, folks!

!endmeeting #105

Thanks everyone ! and Thanks Yasmin Valim de Souza for running :)

Thanks all!

careful, the meeting is not ended