Fedora 41 Readiness Tracker

[p5]

Please can maintainers try to keep this list up-to-date with any issues that could hold back the F41 cycle.

TODO:

• minimize 3rd party dependencies
  • feat: use negativo17 in lieu of rpmfusion #636
  • feat: use negativo17 in lieu of rpmfusion hwe#282
• Split nvidia into -nvidia and nvidia-open
  • team decided against auto-rebase Update ublue-update to rebase existing systems
• Cleanup old MATE images
  • fix: remove mate images #639
  • chore(ci): stop building mate hwe#280
• Cleanup redundant HWE images (No need to do this)
  • can surface images go away due to fsync-kernel?
  • can asus images go away due to fsync-kernel?
• Update kernel-cache repo - feat: enable Fedora 41 builds kernel-cache#27
• Update akmods repo - F41 akmods Tracker akmods#248
  • NON-blocker kmod evdi: chore: enable evdi builds for F41 akmods#258
• Update main repo - feat: enable Fedora 41 builds #638
  • re-add missing libs to F41 - feat: add missing packages to Fedora 41 builds #655
  • will not be added for F4+: missing libvdpau
• Update hwe repo
• Update Bazzite
• Update Bluefin: F41 Release Tracker bluefin#1685
• ublue-update loginctl commands need to be changed since Fedora 41 (systemd v256) ublue-update#132
• ublue-selinux-generator selinux F41 ublue-sulogin-generator selinux #653
• F41 ISO installers for Bazzite / Bluefin / Aurora
• Update uCore
  • feat: enable coreos-stable on F41 kernel-cache#39
  • feat: enable coreos-stable for F41 akmods#271
• Bootupd Testing - https://gitlab.com/fedora/ostree/sig/-/issues/1
• Announce secure boot key rotation
  - Draft announcement

[travier]

I deferred composefs to F42.

[travier]

We can probably include testing bootupd in this list: https://gitlab.com/fedora/ostree/sig/-/issues/1

[yodatak]

Hello is there is a way to test bazzite fedora 41 to iron some bug and help make it stable would love to help ?

[p5]

Hello is there is a way to test bazzite fedora 41 to iron some bug and help make it stable would love to help ?

Not yet. We're usually waiting around for a while for dependencies to start building for the newest release.
I'll create a PR today to see what we're waiting for.

[travier]

Bootupd is in F41 but there is still a major bug right now: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd#How_To_Test

The fix should be in tomorrow's build.

[castrojo]

Ok most of this stuff is straightforward, and composefs is for F42 so less things to worry about. 😄

Can we get consensus on the Asus and Surface images? For bluefin: fsync in latest now and it might be worth just putting those users there for now, and then when fsync lands in stable post key rotation people will have 2 choices. Note that we'll probably have to keep them around another cycle, we don't have the live rebaser enabled, we'd have to slow roll it.

I've now experienced the need for an Asus image with my newly paved G14, but I am unsure if there are other options. That asus control center thing is a perfect sysext candidate so maybe keep it around until that's ready? I think surface can go though.

Now that kernel-cache exists custom image folks can now opt into fsync if they want so they'll have more flexibility in that regard and then get onto the stock image. Also q good lesson: Whenever we do an hwe thing we should just also outline an exit strategy for it since ideally we want these to be temporary.

(And probably we should stop making them in the future unless we have to, especially since we need the builder room for nvidia builds that are about to double their resource requirements.

[travier]

Hum, the fixed ostree is still not here. You can get it from https://bodhi.fedoraproject.org/updates/FEDORA-2024-3945fdf385 in the mean time.

The main challenge for UBlue from my perspective is going to be to test bootloader updates with bootupd on all the hardware that you support.

You need to:

• Install UBlue based on Fedora 40
• Rebase to an F41 image with the fixed ostree above
• Use the instructions from https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd#How_To_Test

Testing directly installing using F41 would be good as well but I'm less afraid that it will break things (apart from dual boot via GRUB, which won't work anymore: fedora-silverblue/issue-tracker#530).

I want to enable bootloader updates by default on boot for F41 for EFI only but I would prefer to do that if you are confortable with it as well and testing here is successful.

Thanks!

[m2Giles]

Can we get consensus on the Asus and Surface images? For bluefin: fsync in latest now and it might be worth just putting those users there for now, and then when fsync lands in stable post key rotation people will have 2 choices. Note that we'll probably have to keep them around another cycle, we don't have the live rebaser enabled, we'd have to slow roll it.

We will still need the images because of the additional packages on both surface and Asus. Surface swaps out the Wacom packages and some other items. Asus has control GUI app and a bunch of added firmware.

Instead we change how we build them to be a FROM bluefin and add those changes instead of building from Silverblue. We do not build Asus and surface images during PRs anymore so there won't be any changes for PRs.

[castrojo]

The main challenge for UBlue from my perspective is going to be to test bootloader updates with bootupd on all the hardware that you support.

Hey just to confirm, we have images with bootc/bootupd already on them (Bluefin does at least), and have had so for a long time. They would still need to explicitly upgrade right?

I can start testing this weekend, and then I can post instructions on the forum for a call for testing.

apart from dual boot via GRUB, which won't work anymore:

I am glad we decided to not support this, though we have people with custom setups. 😄

[travier]

Can you show me how you added bootupd to the current images? As far as I could find it's not here https://github.com/search?q=org%3Aublue-os+bootupd&type=code and I don't include it in the F40 container images.

Once it's properly added in the image (https://pagure.io/workstation-ostree-config/blob/main/f/bootupd.yaml), the installer will use it for new installations. It's in the F41 container images right now.

For updating systems, we will have a systemd unit that will update systems on boot: https://pagure.io/workstation-ostree-config/pull-request/571

[travier]

I am glad we decided to not support this, though we have people with custom setups. 😄

It will still be possible to manually setup a boot entry for another system by adding it in the GRUB config. It "just" won't be done by default anymore.

[fiftydinar]

@travier bootc package is installed, which pulls bootupd.

https://github.com/search?q=org%3Aublue-os+bootc&type=code

[travier]

OK, then I wonder how your ISOs work without the post process part from https://pagure.io/workstation-ostree-config/blob/main/f/bootupd.yaml 🤔

[travier]

Ah it's there: https://github.com/ublue-os/bluefin/blob/d02a9454ffb2e5bc2336b275da02230d77f1deda/build_files/bootc.sh#L4

[fiftydinar]

OK, then I wonder how your ISOs work without the post process part from pagure.io/workstation-ostree-config/blob/main/f/bootupd.yaml 🤔

It's included in Bluefin/Aurora at least:

https://github.com/search?q=org%3Aublue-os+bootupctl+backend+generate-update-metadata&type=code

I think that only Bazzite doesn't install bootc and uses older ISO version which doesn't require it

[travier]

Then you're lucky no-one tried it out yet as we found bugs! 😅

[fiftydinar]

Then you're lucky no-one tried it out yet as we found bugs! 😅

Hmm, bugs about bootupctl backend generate-update-metadata?
Or some new Anaconda bugs with bootc?

[travier]

Bugs when adopting and updating systems without bootupd to use bootupd

[travier]

New installations are fine

[travier]

The "updating old systems" part is #634 (comment). It's what needs testing the most.

[travier]

Alright, we've now landed the needed fixes so we should be good for testing adopting systems without bootupd:

• Install UBlue from a version before bootupd was included in the image (I don't know if you still have those at hand?)
• Rebase to an F41 image of UBlue
• Use the instructions from fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd#How_To_Test to test adopting and updating using bootupd

[p5]

Awesome!
We're currently still waiting for some upstream dependencies before we're able to publish F41 images, but we'll definitely start testing ASAP!

[castrojo]

In case anyone is wondering, don't followup the bootupd instructions if you're on F40. 😄

[m2Giles]

One item, for the F41 images when built in main and hwe, I recommend that we give them the convenience tag of Beta.

1. Bluefin/Aurora are prepped to convert Beta to a version number.

2. We can ship a service to yell at you if still on Beta after the release is finalized. We had a fair amount of people using 39 tags who were confused why they didn't roll forward to 40 when they rebased to 39 from 38.

[antheas]

I think the old secureboot key should stay there for a year more, I cannot think of 1 benefit to removing it.

It is not more secure, as the users will still have the old key. If we care about security we should tell the users of the old key how to remove the previous one after they enroll the new one.

[nikodunk]

Rebasing to Silverblue F41 from Bluefin dx 40 now works smoothly on a bare-metal install, FWIW.

[znmeb]

I can wait till Bluefin:latest goes to 41 - Bluefin 40 is rock solid. 👍

[antheas]

Little blocker:

Oct 26 15:00:21 antheas-ally-x setroubleshoot[1861]: SELinux is preventing ublue-sulogin-g from read access on the file passwd.
                                                     
                                                     *****  Plugin catchall (100. confidence) suggests   **************************
                                                     
                                                     If you believe that ublue-sulogin-g should be allowed read access on the passwd file by default.
                                                     Then you should report this as a bug.
                                                     You can generate a local policy module to allow this access.
                                                     Do
                                                     allow this access for now by executing:
                                                     # ausearch -c 'ublue-sulogin-g' --raw | audit2allow -M my-ubluesuloging
                                                     # semodule -X 300 -i my-ubluesuloging.pp

[travier]

Heads up: I somehow forgot to push the "bootupd enabled by default" / bootloader updates enabled by default on boot change to the F41 branch for the Atomic Desktops containers so it's not in F41 yet. I'm pushing this one now. Current known issue is coreos/bootupd#762.