Custom Fedora OCI images for Framework laptops

Awesome! Appreciate the share!

1 Like

Hah this is so awesome! Thanks for sharing this!

2 Likes

got bluefin up and running on my FW13 AMD - really like it so far!
the only thing that is not working out of the box is the fingerprint scanner. is there anything special to do on the immutable system?

downloaded the cab file from: Updating Fingerprint Reader Firmware on Linux for 13th Gen and AMD Ryzen 7040 Series Laptops

tried to install it with fwupdtool, but it fails:

 sudo fwupdtool install --allow-reinstall --allow-older goodix-moc-609c-v01000330.cab 1e8c8470-a59c-571a-82fd-19c9fa32b9c3
Laden …                  [********                               ]11:58:06.743 FuEngine             failed to add device /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.0: ioctl error: Ungültige Adresse [14]
Laden …                  [***********                            ]11:58:08.722 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.722 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
Laden …                  [************                           ]11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
Laden …                  [************                           ]11:58:08.723 FuUdevDevice         fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice             fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
Schreiben …              [*******************                    ]
Ausgewähltes Gerät: Fingerprint Sensor
Entpacken …              [ -                                     ]
generic GUID requires a CHID, child, parent or sibling requirement

The problem is the CAB file doesn’t express the requirements appropriately for which systems it can apply to. This is a requirement with newer fwupd versions. Framework needs to respin it.

See [RESPONDED] Fedora 39 Kinoite Fingerprint Reader Not Working - #3 by Mario_Limonciello for more details.

3 Likes

After the last beta test with LVFS went sideways as I lacked the same input kits found on 13th gen and AMD Ryzen configs, I had to rely on the community…then was drawn into other more immediate issues.

Refocusing on this now. Request for input kits matching what current users are getting, will be testing our our LVFS beta (after some internal changes are done). It’s on the list, I promise! :slight_smile:

5 Likes

Very cool! Definitely get significant power savings using this, but the epp_performance command errors out, and with epp_balance_performance or lower (maybe epp_performance too, but can’t verify) I get random mouse dropout while gaming. Not sure what could cause this, but had to switch back to ublue main. Still a great image to rebase to whenever I need a full day of productivity without a recharge. Thanks for sharing, and I’d bet if this image gets more attention from the knowledgeable community here to polish stuff like that, it could become the defacto AMD framework image.

1 Like

Thanks for sharing your results. I will have to look into why the epp_performance setting isn’t working for you. Regarding the mouse maybe it’s due to the usb autosuspend configurations? I’m not sure I haven’t run into any issues with that myself yet.

But also wanted to give you a heads up that you shouldn’t need to manually set the epp settings anymore. I created a COPR with a patched power-profiles-daemon which is now integrated into the image. So when you select power saving / balanced / performance it should automatically set the epp setting for you (no need to use the just script anymore). I am planning on doing a more detailed post / tutorial for the community.

4 Likes

Yes! I’m glad people are finding the power of the fork! I’m on an Intel Framework so I can’t take lead on this, but if we figure it out and get the fixes in then we can just slipstream them in. If you wanna take lead we could set up a testing branch in the repo so we could stage things like this and then just land them when they’re ready.

I am hesistant to carry a patched g-p-p but if someone’s also talking to Fedora/GNOME and there’s communication effort to bring that upstream then it could be a great idea. I’m sure Matt and Fedora talk regularly so perhaps a testing branch might do some good here?

I think if we had a handful of people in the repo then the launch of the 16 could be smooth(er) if we set up branches for the models. My hope is that more Framework owners just dive in, we do shared ownership of the repos so all we need to figure out is a structure in the git repo to sort this and start to think about how to support future models.

EDIT: I’m addressing @Aman_Chhabra too!

1 Like

Happy Holidays! There’s been an ongoing discussion in Fedora about using tuned in F40 and beyond:

This discussion lead to this patch by Mario Limonciello:

We’ve added this patched GNOME power-profiles-daemon to our bazzite and bluefin images so we can try them out, so far the feedback from people trying it appears to be positive so I’m hoping to give it a try this week but thought I’d let you all know!

Note that the framework images are using TLP, so you’ll need to be on a non-framework GNOME image of bluefin or bazzite to try this. I’m hoping to just ship a toggle so end users don’t have to deal with this, so if you’re interested in working on that let me know!

2 Likes

Quick update, we are experimenting with tuned in our :testing images:

I just finished a trip with mine and I prefer it to the TLP setup on my Intel Framework 13. Battery lasts just as long but it doesn’t feel so crippled performance-wise on battery. I have not done hard science on this.

We now have and updated PPD and tuned in images so switching back and forth is a clan reboot. What I don’t have is the time to test them thoroughly, so if any of you have any time to investigate performance between the two (on AMD and Intel) then that’d be awesome. Thanks!

1 Like

I had the opposite experience. Tuned is simply another profile style power optimizer that attempts to figure out what the user wants. You probaly turned turbo off on battery in TLP and well tuned wants to use turbo “where needed” to enhance user experience. Probably why in your instance you are finding it more responsive, just wait until you hit the wrong workload on battery and it keeps kicking turbo in to give you the wanted experience. One of my big issues with tuned is that 1) at the time I tested it there was no easy way to turn turbo off (or I could not find the documentation), and 2) difficult to make it event driven. I don’t want to have to remember to change my profile, it should do it automatically. Primarily plugged in vs battery, docked vs not.

t has potential, but I will wait until it is actually ready.

I’m just using the built in GNOME widget (which drives tuned) to match what I want and it seems to be working fine.

1 Like

Plans for Fedora 40!

Hey ya’ll, we’ve been reorganizing and cleaning up all the Universal Blue images and I thought I’d give everyone a quick update for the Fedora 40 release.

Just about everything you need for the Framework 13 and 16 is in Fedora, there’s really no need to have a full image just for Framework hardware as it’s just passing a karg and a few minor tweaks. Therefore we have decided to sunset the dedicated Framework images and instead have Bazzite and Bluefin support the necessary tweaks to have those images working ootb on the 13 and 16.

The biggest change is we’re switching to tuned for power management. Fedora has plans to switch to this at some point. We switched to this about half way through the F39 cycle and it’s been excellent and allows for having tons of profiles and tweaks. All the desktop GUI stuff is ported over to use it so you shouldn’t notice a UX difference in the power selector thing:

image

  • Bluefin and Aurora(WIP) are more suitable for generic desktop use and work great on the 13 and 16.
  • Bazzite will be the go to image if you want to game on a Framework 16
  • Both include ROCm out of the box so things like ollama and pytorch should work out of the box, still investigating these.

If you’re looking for a more vanilla Fedora experience, you can use a base image - these will not include tuned. The GNOME ones come with the latest power-profiles-daemon and that has all the right AMD patches, they work great.

Rebasing to a new image

We will stop publishing the framework images sometime at the end of the month when Fedora 40 is released. If you’re on an existing framework image do an rpm-ostree status and look for this line with framework in it:

ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-framework:latest - this tells you the current image that you are on.

Whatever image you are on you will need to rebase to the non-framework version.

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-main:latest

Note that :latest will put you on F39 and will put you on F40 when it comes out, so if you want to control when to do the major update you can use :39 or :40 if you prefer to do it manually.

Note that we’re in the process of enabling F40 builds, so depending on the image a rebase to F40 now might not work, so just putting this up now in preparation for release. Thanks and if you have any questions feel free to ask!

3 Likes

Tuned doesn’t have support for amdgpu like PPD does. For whatever reason upstream hasn’t merged it. Please don’t switch until this is merged.

5 Likes

Gotcha, we can slipstream the patch in now and then drop it when it’s merged, thanks!

3 Likes

@Jorge_Castro Bazzite website down ?

1 Like

Misspelled the URL, fixed, thanks!

1 Like

Just wanted to say I’ve been on Fedora Atomic/Silverblue since I got my 1st gen Framework, and switching to Bluefin made both video playback and battery-life/heat a lot better. Thank you very much for the build!

1 Like

PPD again is ahead of tuned. PPD 0.21 now handles battery for AMD pstate differently than on AC for more efficiency.

Here are all the pull requests tracking everything.

My honest opinion is you are “jumping the gun” moving over ahead of regular Fedora. I intend to push back on regular Fedora’s move too until these are merged. Otherwise you will be asking for battery life regressions.

2 Likes

Understood, I’ll look at switching back before release.

3 Likes