Meeting started at 2026-07-22 15:30:52 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

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

!hi

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

!hi

!hi

rapneset: Rolv Apneseth (rapneset)

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

!hi

apiaseck: Adam Piasecki (c4rt0) - he / him / his

!hi

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

We have one action item from the last meeting:

!hi

spresti: Steven Presti (spresti)

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

I think that this one is from rapneset

!hi

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

!hi

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

Yes, I just posted a comment at https://github.com/coreos/fedora-coreos-tracker/issues/1465#issuecomment-5048180334 about my findings

!hi

Clément Verna: Clement Verna (cverna) - he / him / his

It'll likely be a decent bit of work even if we are taking Timothees suggestion, with the documentation etc. that we'll need to do, but whether or not we take the suggestion seems like a big decision to make

!hi

Yasmin Valim de Souza: Yasmin Valim de Souza (ydesouza)

Wondering if this can be a case where we break the auto update promise? Would that make things easier? ie we would ask folks to reprovision their nodes?

How often do people re-provision? I wonder if people will re-provision without re-reading what we add to the docs, and break their partitions by accident.

Clément Verna: i don't think any part of the proposal suggested we automigrate older nodes to the new disk layout

rapneset: those older nodes would stay with the smaller partitions, right?

The main thing this would break is re-provisioning nodes when users have custom data partitions after the root, which would get clobbered

As far as I understand, yes older nodes keep the smaller partitions

Ah great, I didn't go through all the proposal, was just asking out of curiosity

but Clément Verna you do ask a good question..

the outcome of this is basically that older nodes will likely hit a logical barrier of no longer being able to upgrade

i.e. if they routinely do this, they may not check the docs every time / if they have it automated.

the reason we want to increase the size is to give ourselves more room and if we start to use that extra space the older nodes won't update properly

I think that's acceptable - we'd force them to reprovision. though, I'd love to find a way around it

in the past one idea was to combine the EFI and /boot partitions but use the same amount of space that they previously consumed.

in that case a "migration" could be performed (either manual or automated)

but we never quite fleshed out our options properly there.

From what I understood, the merging of EFI and /boot also required some more work in ostree: https://github.com/ostreedev/ostree/issues/1951

Could that happen when we switch to f45 for example. I guess this is when we might have most chances for folks to notice some announcement

F45 being an example, could f46 etc .. depending on when we make this happen

it could, but we're pretty late in the "changes" window for F45 already

Yeah this would be a big change

I think we go over the f45 release schedule soon in this meeting?

For f45 - with our rawhide aarch64 space issues (can't update) is it worth trying to get this change in?

> I think we go over the f45 release schedule soon in this meeting?

its the next thing in the agenda, there are no tracker items so we have plenty of time tho

FTR we can also actually move filesystems/data around using sfdisk

but I think we'd want to instruct the users to do this manually and to make backups beforehand

here's an example where I do something like this for a SBC I deploy Fedora CoreOS too

here's an example where I do something like this for a SBC I deploy Fedora CoreOS too

```

dd if=/dev/mmcblk0 iseek=64 seek=64 of=/dev/mmcblk1 bs=512 count=${uboot_size_blocks}

echo 'start=+32M' | sfdisk --move-data -N 1 /dev/mmcblk1

echo 'start=+32M' | sfdisk --move-data -N 2 /dev/mmcblk1

echo 'start=+32M' | sfdisk --move-data -N 3 /dev/mmcblk1

echo 'start=+32M' | sfdisk --move-data -N 4 /dev/mmcblk1

```

we could provide a script for them to run in the initramfs or something

either way. thank you rapneset for digging further into the problem

rapneset++

cverna gave a cookie to rapneset. They now have 1 cookie, 1 of which was obtained in the Fedora 44 release cycle

acervera gave a cookie to dustymabe. They now have 203 cookies, 2 of which were obtained in the Fedora 44 release cycle

Not a problem. Would we be happy going ahead with taking Timothees suggestion? That seems like the biggest potential pain point

ydesouza gave a cookie to dustymabe. They now have 204 cookies, 3 of which were obtained in the Fedora 44 release cycle

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

rapneset++

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

🍪 party 🎉

rapneset: sorry. I'm not sure it's clear to me. What exactly is Timothee's suggestion?

To not implement some kind of partition preservation in coreos-installer I believe

https://github.com/coreos/fedora-coreos-tracker/issues/1465#issuecomment-3666174243

i.e. I don't care if we don't make it easy, but I do care if someone unknowingly is going to delete their data

I think I'm fine with not implementing partition preservation in coreos-installer, but is there any way we can prevent someone from destructing their data?

Angel Cervera Roldan: had some concerns

Yeah I'm not too familiar with what would actually need to be done for that but I think not clobbering the extra data partition, i.e. just detecting it's there and refusing to reprovision to the new layout, is what we'd be foregoing implementing. RAID and luks might make that difficult was my reading of it

Clément Verna: what do you think?

If we can fail safe I think that's great, but not sure we can cover all the cases. I think doing something like a Fedora Magazine article might be useful

To help make the risks more visible

I'm worried about the implications downstream as well

I couldn't tell for certain if there would actually be implications downstream - what might happen?

same thing that might happen upstream :)

Also, I haven't had time to go through it yet but is https://github.com/coreos/fedora-coreos-tracker/issues/2188 also relevant to this issue?

rapneset: kind of related, but not really. This is more about the size of the XFS filesystem by default and not the starting point of the partition 4

that's a different issue

Ok thanks

I guess what I meant is would there be the same re-provisioning concern or is there something else to worry about

rapneset: maybe let's set up some time for a small group of us to brainstorm on the failure scenarios here and think of a way to avoid inadvertent data destruction

Sounds good

I will quickly go over the release schedule, and then we can circle back to this if needed

So that we dont run out of time

yesterday, we reached: Change Checkpoint: Proposal submission deadline (Self Contained Changes)

next checkpoint (Tue 2026-08-04) will be

Retire Orphaned and Long-Time FTBFS Rawhide Packages

next checkpoint (Tue 2026-08-04) will be: Retire Orphaned and Long-Time FTBFS Rawhide Packages

Re the proposal for butane ignition merge, we are in the fesco voting phase now :)

https://forge.fedoraproject.org/fesco/tickets/issues/3650

Nice!!!!

spresti++

dustymabe has already given cookies to spresti during the F44 timeframe

This is awesome!

c4rt0 gave a cookie to dustymabe. They now have 205 cookies, 4 of which were obtained in the Fedora 44 release cycle

Nice!

Thanks for working on this, spresti

rapneset has already given cookies to spresti during the F44 timeframe

spresti++

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

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

There are no open issues with the meeting label

!topic No meeting topics found.

spresti: https://github.com/coreos/ignition/pull/2235 is the latest version of the PR?

So we are on open floor

Yeah, It will need to be updated, again once the vote is in, to refresh with latest butane / have butane frozen

Pending pr in butane with the freeze notes.

acervera has already given cookies to spresti during the F44 timeframe

I can't wait to change some of my configs over (at least for things like `include`ing other configs it will make things much more composable)

Just related to the butane freeze in relation to the partition size stuff - do we need to make changes to https://github.com/coreos/butane/blob/main/config/fcos/v1_7/translate.go#L49-L50?

Butane freeze sounds scary, but its just a lever for the process of moving active changes to ignition's repo for butane not really freezing butane forever. So if changes are needed they would just land in ignitions repo

Fair enough

Do you know how hard it would be to add new layout templates like the comment suggests?

Anyway we're running low on time, if anyone else has other topics to discuss go ahead

Mmm.... im not sureee. we could brake people using exp specs if we just changed those settings, and you getinto some issues where you cannot cleanly upgrade from old specs to new specs in non obvious ways from a ux perspective.

I would have to look into it a bit. But thats likely why a new layout is required.. ie. a clear jump point

Makes sense

We have 4 minutes left, if anyone else wants to bring something up / wrap anything up :)

A layout here I think is refering to somthing like "base_v2

but not confident in that statement

Okay, we are now out of time! Thank you everyone for coming and enjoy the rest of your day.