<@marmijo:fedora.im>
16:31:32
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
16:31:34
Meeting started at 2025-04-23 16:31:32 UTC
<@meetbot:fedora.im>
16:31:34
The Meeting name is 'fedora_coreos_meeting'
<@marmijo:fedora.im>
16:31:41
!topic roll call
<@ravanelli:matrix.org>
16:35:33
!hi ravanelli
<@zodbot:fedora.im>
16:35:35
Renata Ravanelli (ravanelli)
<@aaradhak:matrix.org>
16:36:32
!hi aaradhak
<@zodbot:fedora.im>
16:36:35
Aashish Radhakrishnan (aaradhak)
<@dustymabe:matrix.org>
16:37:13
!hi
<@zodbot:fedora.im>
16:37:15
Dusty Mabe (dustymabe) - he / him / his
<@siosm:matrix.org>
16:37:25
!hi
<@zodbot:fedora.im>
16:37:28
Timothée Ravier (siosm) - he / him / his
<@marmijo:fedora.im>
16:37:56
There aren't many attendees. I'll wait a few more minutes before starting
<@fifofonix:matrix.org>
16:38:01
!hi
<@zodbot:fedora.im>
16:38:02
Fifo Phonics (fifofonix)
<@marmijo:fedora.im>
16:39:16
!topic Action items from last meeting
<@marmijo:fedora.im>
16:39:55
No action items from the last meeting we had
<@marmijo:fedora.im>
16:40:09
!info We skipped the meeting last week due to availability.
<@marmijo:fedora.im>
16:40:40
!topic Review Fedora 43 Release Schedule
<@marmijo:fedora.im>
16:40:48
<@marmijo:fedora.im>
16:41:09
we are s till SUPER early in the Fedora 43 cycle. I'm sure there's not much for us to discuss here.
<@marmijo:fedora.im>
16:41:14
we are still SUPER early in the Fedora 43 cycle. I'm sure there's not much for us to discuss here.
<@dustymabe:matrix.org>
16:41:26
marmijo: :)
<@dustymabe:matrix.org>
16:41:33
always something to discuss
<@dustymabe:matrix.org>
16:42:07
of course there are changes (which we'll discuss in a dedicated topic)
<@marmijo:fedora.im>
16:42:12
I ran the fedora changes script and updated the target to fedora 43. We'll discuss the changes today as a meeting topic
<@dustymabe:matrix.org>
16:42:19
but also there are followon items from the move to F42
<@jbtrystram:matrix.org>
16:42:36
!hi
<@zodbot:fedora.im>
16:42:40
Jean-Baptiste Trystram (jbtrystram) - he / him / his
<@dustymabe:matrix.org>
16:42:42
https://github.com/coreos/fedora-coreos-tracker/issues/1851
<@marmijo:fedora.im>
16:42:59
Good point!
<@jlebon:fedora.im>
16:43:09
!hi
<@zodbot:fedora.im>
16:43:10
None (jlebon)
<@dustymabe:matrix.org>
16:43:10
We need some volunteers for pushing forward that big list at the bottom (i.e. our various containers that need updating)
<@aaradhak:matrix.org>
16:43:31
I can try to look into that
<@dustymabe:matrix.org>
16:43:34
and there are a few more cleanup items (i.e. related to `coreos-pool` koji tag)
<@dustymabe:matrix.org>
16:43:54
marmijo: would you be willing to walk through this one with me as a mentor?
<@marmijo:fedora.im>
16:44:31
Absolutely!
<@dustymabe:matrix.org>
16:45:26
ash since there are a lot of updates in that list feel free to find a partner (and also make a jira card for it since it's not a small amount of work)
<@dustymabe:matrix.org>
16:45:26
<@dustymabe:matrix.org>
16:45:26
ok let's action those two then.
<@marmijo:fedora.im>
16:45:45
Looks like we also need to update some container file links in the tracker.
<@marmijo:fedora.im>
16:46:23
ImageStream and BuildConfig have broken links for a few tools.
<@aaradhak:matrix.org>
16:46:32
sure will do.
<@marmijo:fedora.im>
16:47:35
Let's move on to the main topics for the meeting
<@marmijo:fedora.im>
16:47:47
!topic Migrate existing systems to OCI updates
<@marmijo:fedora.im>
16:47:53
<@marmijo:fedora.im>
16:48:54
jbtrystram: added the meeting label before last week's scheduled meeting, but we skipped it
<@dustymabe:matrix.org>
16:51:41
jbtrystram: want to introduce?
<@siosm:matrix.org>
16:51:44
Not sure what needs to be discussed? I think this is mostly asking folks to git a try before we enable that for everyone?
<@marmijo:fedora.im>
16:52:08
jbtrystram added the meeting label before last week's scheduled meeting, but we skipped it
<@dustymabe:matrix.org>
16:52:08
or maybe he wanted to get confirmation that it's OK to do the migration?
<@siosm:matrix.org>
16:52:27
https://github.com/coreos/fedora-coreos-config/pull/3355 has been merged so this will land in the next testing release
<@dustymabe:matrix.org>
16:52:44
travier: it's merged, but we don't run it by default
<@siosm:matrix.org>
16:52:50
ah indeed
<@dustymabe:matrix.org>
16:52:57
see https://github.com/coreos/fedora-coreos-config/pull/3458
<@siosm:matrix.org>
16:53:02
still, should make it easier to ask folks to test
<@siosm:matrix.org>
16:54:39
OK, JB isn't here so let's skip this one and talk about it async / next week?
<@marmijo:fedora.im>
16:55:11
sounds good. want to info anything here, or should we just move on?
<@siosm:matrix.org>
16:55:53
!info We are preparing the migration of existing nodes to container images for updates. Help with testing welcomed.
<@siosm:matrix.org>
16:56:05
<@siosm:matrix.org>
16:56:12
<@marmijo:fedora.im>
16:56:32
Thanks travier
<@marmijo:fedora.im>
16:56:41
!topic Enable automatic bootloader updates
<@marmijo:fedora.im>
16:56:47
<@siosm:matrix.org>
16:57:30
So this is an FYI so this should be coming soon
<@siosm:matrix.org>
16:57:56
Huijing did a lot of work on https://github.com/coreos/bootupd/issues/132 (support for updating the bootloader when RAID is setup)
<@dustymabe:matrix.org>
16:58:08
travier: do I remember correctly that this is already enabled by default in Silverblue?
<@siosm:matrix.org>
16:58:22
Once this is merged, we should be able to enable it by default on FCOS
<@siosm:matrix.org>
16:58:36
yes, it's already enabled by default on all Atomic Desktops since Fedora 41
<@dustymabe:matrix.org>
16:58:58
Any thoughts on if this should roll out in the next major.. or should we just YOLO it into F42 ?
<@siosm:matrix.org>
16:59:16
Anaconda RAID setups (and all partitions setups in general) use a single boot and ESP partitions layout so we don't have the mirroring issue
<@siosm:matrix.org>
17:00:04
I think that once we have the code ready and tested, we should just go with it. The longer we wait, the more painful it will be
<@siosm:matrix.org>
17:01:36
There quite strong guarantees that updates with bootupd are as safe as they can ever be so if things fail to update, it should not impact systems
<@siosm:matrix.org>
17:03:04
but it's still a risk as I agree as this is new code
<@dustymabe:matrix.org>
17:03:23
It also does update the BIOS MBR too?
<@siosm:matrix.org>
17:03:27
yes
<@dustymabe:matrix.org>
17:03:41
so.. that is something that package mode doesn't do today, correct?
<@siosm:matrix.org>
17:03:47
those are not strongly safe, only best effort safe
<@conan_kudo:matrix.org>
17:03:48
it does not
<@conan_kudo:matrix.org>
17:03:58
there is one more thing we should scope into bootupd updates FYI
<@siosm:matrix.org>
17:04:02
package mode does update both
<@conan_kudo:matrix.org>
17:04:21
<@jlebon:fedora.im>
17:04:23
related to this though: it's interesting that Anaconda does something different. As I recall, there were good reasons why we didn't RAID the ESP that shouldn't really be CoreOS-specific
<@dustymabe:matrix.org>
17:04:24
travier: really.. for some reason I didn't think it did (i.e. it just relied on file updates from RPM)
<@dustymabe:matrix.org>
17:04:31
travier: really.. for some reason I didn't think it did (i.e. it just relied on file updates from RPM, which only works for the EFI files)
<@dustymabe:matrix.org>
17:05:33
Jonathan Lebon: off the top of my head.. probably because EFI can't really read a RAIDED FS?
<@siosm:matrix.org>
17:05:38
hum OK, I though that package mode updated BIOS systems as well. Not sure where I got that from
<@dustymabe:matrix.org>
17:05:40
Jonathan Lebon: off the top of my head.. probably because EFI can't really read an actually RAIDED FS?
<@siosm:matrix.org>
17:05:57
no, the ESP can not be RAIDed
<@jlebon:fedora.im>
17:06:10
dustymabe: there's ways around that, but there are other issues too
<@siosm:matrix.org>
17:07:15
As Neal said, the next step for bootup is to unify the bootloader updates for package mode as well. This is tracked in https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1. I haven't been able to focus on it again
<@jlebon:fedora.im>
17:07:49
ok, I misread what you meant there. setting up RAID in Anaconda will only RAID e.g. the rootfs but otherwise there is only one bootfs and ESP?
<@siosm:matrix.org>
17:08:02
Anaconda does not install multiple ESP or boot partitions. It only ever install one, thus it's not RAIDed
<@siosm:matrix.org>
17:08:26
yes
<@dustymabe:matrix.org>
17:09:25
anybody know what happens on ppc64le and s390x ?
<@dustymabe:matrix.org>
17:09:37
i.e. are those updated today in package mode?
<@siosm:matrix.org>
17:09:47
we can not RAID the ESP because the content on the disk may be changed by the firmware so we can not expect the RAID to survive. The bootloader team also mentioned that some other state can not be safely synced between multiple boot partitions thus the single ESP/boot setup.
<@siosm:matrix.org>
17:10:32
For us it's a bit different as we don't set a EFI boot entry for the disk we install to, so we need both disks to be bootable or we could have system that fail to boot right after a coreos-installer install
<@dustymabe:matrix.org>
17:10:50
in our case we don't have multiple boot partitions though.. we have a single one, on top of a software RAID
<@dustymabe:matrix.org>
17:11:03
linux has no problem reading the software RAID so it's fine to do it for the /boot partition
<@dustymabe:matrix.org>
17:11:45
Thoughts on ^^
<@siosm:matrix.org>
17:12:22
I think that works because we don't use things in GRUB that write to /boot. If we did, GRUB would have to mount /boot RAIDed and I don't think that's the case for us / possible in GRUB?
<@dustymabe:matrix.org>
17:12:40
linux/GRUB has no problem reading the software RAID so it's fine to do it for the /boot partition
<@dustymabe:matrix.org>
17:13:50
I know GRUB reads things RAIDED (i.e. my desktop is a software RAID with no separate /boot partition) but I don't know about write
<@conan_kudo:matrix.org>
17:14:05
it's possible in GRUB
<@conan_kudo:matrix.org>
17:14:09
it's just the ESP we can't
<@conan_kudo:matrix.org>
17:14:17
everything from GRUB onward can be
<@jlebon:fedora.im>
17:15:34
yeah, we do use the GRUB RAID support in FCOS as well
<@dustymabe:matrix.org>
17:15:43
2. ppc64le and s390x ?
<@dustymabe:matrix.org>
17:15:43
ok. so differences in what we'd be doing versus package mode:
<@dustymabe:matrix.org>
17:15:43
<@dustymabe:matrix.org>
17:15:43
1. updating non EFI (this is good but also implies a risk, but I guess atomic desktops are already doing this?)
<@siosm:matrix.org>
17:15:53
then we should be good
<@siosm:matrix.org>
17:17:53
Ideally with https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1, we make the differences with package mode go away
<@dustymabe:matrix.org>
17:18:29
the big question in my mind is still if we want this to go straight in or not
<@dustymabe:matrix.org>
17:18:40
how about we roll it out to `next` for a few cycles first?
<@siosm:matrix.org>
17:19:04
works for me too 👍️
<@dustymabe:matrix.org>
17:19:04
I'm not sure how many people pay attention to it outside of Fedora major rebase cycles, but at the very least I think we should do that
<@dustymabe:matrix.org>
17:19:34
laziest thing to do would just be conditionalize it on F43 OR just let it go straight in to F42
<@dustymabe:matrix.org>
17:19:46
Anybody else have opinions?
<@jlebon:fedora.im>
17:21:39
I think we don't have to wait until F43.
<@jlebon:fedora.im>
17:21:53
rolling it out to next SGTM too
<@jlebon:fedora.im>
17:22:11
mostly unsure about the MBR part. how safe/unsafe is it?
<@dustymabe:matrix.org>
17:22:33
I guess we'll find out
<@jlebon:fedora.im>
17:23:19
i guess it basically just calls grub-install AFAICT
<@siosm:matrix.org>
17:24:16
yes, it calls out grub-install. It's not 100% safe as you technically interrupt the update at the wrong time and get a partially updated MBR.
<@siosm:matrix.org>
17:24:28
if we prefer, we can update only EFI systems
<@siosm:matrix.org>
17:24:41
this is the main use case for GRUB updates anyway
<@jlebon:fedora.im>
17:25:08
anyway, OK with it. but agree it's a risk. since package mode doesn't do it, we could consider disabling that part, but I guess the end goal is that we do use it for both anyway
<@dustymabe:matrix.org>
17:25:32
right. where could/should we get clarity on if this is something we want to do
<@dustymabe:matrix.org>
17:25:46
i.e. we should change the default for all of Fedora and not just ourselves (in the long run)
<@dustymabe:matrix.org>
17:26:01
so whatever we do today (for us) should be what all of Fedora wants to do in the future
<@dustymabe:matrix.org>
17:26:12
I guess some of that will be hashed out in https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1 ?
<@dustymabe:matrix.org>
17:26:25
of course I think the bootloader folks would have stronger opinions here?
<@jlebon:fedora.im>
17:26:31
exactly, yeah. parity with package mode right now means just updating EFI
<@marmijo:fedora.im>
17:27:41
We're just about out of time for the meeting
<@siosm:matrix.org>
17:27:43
They are taking part of the change linked above
<@siosm:matrix.org>
17:28:09
let's go to open floor quickly?
<@marmijo:fedora.im>
17:28:24
SGTM
<@marmijo:fedora.im>
17:28:26
!topic Open Floor
<@dustymabe:matrix.org>
17:28:58
Can someone try to capture what was discussed and decided from the above conversation?
<@marmijo:fedora.im>
17:29:20
I can do that
<@marmijo:fedora.im>
17:31:02
Alright, that's it for today. Thanks everyone for joining!
<@marmijo:fedora.im>
17:31:04
!endmeeting