bazzite supports rolling back to builds from specific dates, i'm trying to track down which date was
bazzite 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_BOOTits 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.linuxlet 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_EARLYlockdown 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_BOOTperhaps
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-20240210i 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
J6.8?
Ayeah, but we never figured out when the bug first started happening
Jthat hasn't been released yet, and I don't think GE would put an RC kernel into nobara
Asorry, might've been 6.7
Ait's been a while since we first encountered the bug, i didn't document the exact kernel version on nobara when it happened
Abut it was at least 6.7 on nobara
Jcould be that we inherited it from nobara
Qhmm this is weird, I still have gamescope possibly crashing sometimes on sleep even after the patches I mentioned in that issue were merged - but this doesn't happen every time like the other crash
