anyways, reverting back to stable branch for now
anyways, reverting back to stable branch for now
Nthe post install has begun :Yay:
Agah, should've reverted back to my prior version, instead of deploying stable again
Astable is on 6.7
Atime to find the last version of bazzite on 6.6
Mhttps://github.com/ublue-os/bazzite/pkgs/container/bazzite-deck you can look at the manifests to see which kernel each built images uses
GitHub
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
JI'm kinda against it, because having the lockdown module loaded ahead of time could prevent fiddling with things ahead of time, plus I am unsure if this will really allow you to disable it
Jbut I can look into it
Abazzite supports rolling back to builds from specific dates, i'm trying to track down which date was the last build with 6.6
e.g.
e.g.
Jany build older than 2 days
Anice, thank you. looks like it's
39-20240205
Aarch does not have that option compiled and has the other ones
Ain any case, up to you. But I can not use that kernel with that option on and Im sure im not the only one
JYes, but Fedora isn't arch and they do these kind of decisions in isolation
JI'll first have to dig out why this decision was made, what recommended fixes for hibernation and so on are etc.
Jwhat you actually want is
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT turned offJits a custom config included in kernel-ark (upstream Fedora kernel) which forces lockdown on if secure boot is enabled
Ai dont think so, right now my memory policy is strict
Aand thats not a problem
JThis will let you find the kernel version on a given image
skopeo inspect docker://ghcr.io/ublue-os/bazzite:39-20240210 | grep ostree.linuxJlet me make sure I understand the problem right
Jthe kernel is in lockdown mode which prevents you from doing various things, correct?
Ain integrity mode
Aspecifically
Jit doesn't really matter which one it is
JSince I run kernel-fsync myself (though only on a vanilla Fedora system) I dont think
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY or similar configs are the problemJlockdown is not enabled for me at all
Anice, thank you for the tip.
Jand I never disabled it in any shape or form
JI dont use SB so its probably just
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT forcing it on for youAperhaps
Athis option is not set either
JI can go fork the copr and make a custom build with it turned off for you to test
Aits either one of those
Ain any case, i made an arch version of your patch series that works. I dont think using a fedora kernel on arch is ideal. But its something to consider in the future
Afor me, for example, my swap file is in an encrypted partition. So it is perfectly safe to hibernate
Abut lockdown is written in such a way where it cant see that and disables hibernation
A@Kyle Gospo So followup related to LGO:
- latest bazzite-deck testing image fixed the refresh rate slider on the LGO, but introduced 60hz 30fps cap bug
- image 39-20240205 (kernel 6.6.14-202) does not have the bug
- image 39-20240209 (kernel 6.7.4-201) introduces the bug
- it sounds like this also introduced the bug to the ROG Ally, see here 🎮bazzite
Would it be possible to have a LGO-specific bazzite image on 6.6 + gamescope patch for refresh rate slider?
- latest bazzite-deck testing image fixed the refresh rate slider on the LGO, but introduced 60hz 30fps cap bug
- image 39-20240205 (kernel 6.6.14-202) does not have the bug
- image 39-20240209 (kernel 6.7.4-201) introduces the bug
- it sounds like this also introduced the bug to the ROG Ally, see here 🎮bazzite
Would it be possible to have a LGO-specific bazzite image on 6.6 + gamescope patch for refresh rate slider?
J6.7.4-202 should be done in ~20 minutes
Jyou can see if that works 
Asure, i can try it
Ajust let me know when it's up
Aside note, having images available by date is amazing. made it super easy to track down what image introduced the bug
Jthough uhhh
J202 only re-adds the steamdeck oled hw quirks patch
Anote that even the latest stable build still had the bug
Awhich i'm assuming was
39-20240210Ai wonder what changed between the two images that causes the bug? 
Jbuild is done, results should be in the repo in a few minutes
Aso just for more context, this bug was known about before, it was seen on Nobara v39 (which was on kernel 6.8 when the issue was first reported on the LGO)
edit: it might've been 6.7 on nobara
edit: it might've been 6.7 on nobara
Aso it's not a new bug, this is just the first time I was able to pin it down to some specific change causing the issue
