mtalexan
commented
3 days ago Incidentally, this brought up basically the same topic and was closed almost immediately without any resolution whatso ever: https://github.com/ublue-os/bazzite/issues/899
Open mtalexan opened 3 days ago
mtalexan
commented
3 days ago Incidentally, this brought up basically the same topic and was closed almost immediately without any resolution whatso ever: https://github.com/ublue-os/bazzite/issues/899
mtalexan
commented
3 days ago I'm not at all sure where the fsync kernel-core being used is coming from, but at a rough guess it looks like maybe this copr could add what's needed, presuming it keeps old enough builds that it would still have the 6.9 kernel (the oldest kernel version Fedora itself still supports). https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/
mtalexan
commented
3 days ago Yeah ok. This is a clear initial comfig bug in UBlue. Any ostrees shipping with the fsync kernel require the copr repo to be included in the /etc/yum.repos.d/ files, and the default kernels from the fefora-updates.repo to be disabled. Exactly as the https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/ explains. If you want to add a ujust command to toggle the Fedora kernels back on that could make sense so people could then install newer kernels without fsync patches, but the default has to be to use the matching kernel packages from the copr.
mtalexan
commented
3 days ago I see why the copr repo isn't installed and setup as the default. The copr only keeps the most recent build, none of the past ones, which means it has only the 6.11 kernel right now. The current latest UBlue/Bazzite-provided kernel-core-6.9.12-205.fsync.fc40.x86_64 is relatively old, and is not supported by the copr anymore (probably hasn't been for >1 year).
I guess if UBlue is going to ship with the fsync kernel and not keep to the bleeding edge like the upstream copr supports, it's going to have to figure out how to support a cached version of all the associated kernel packages so it has the older fsync versions available. Maybe UBlue needs to setup it's own copr just to host cached copies of things?
In the meantime, it's not possible to build kernel drivers for any fsync UBlue images as far as I can tell. The minimum necessary kernel-devel doesn't exist anymore and (apparently) wasn't cached before it was removed from the upstream copr. From all appearances, it looks like even the UBlue akmods layer isn't functional for fsync kernels (it doesn't actually appear to be functional for anything to be honest, relying on GitHub releases of container images to keep cached copies of the kernel RPMs but the most recent release being from April 2024 and therefore way out of date).
mtalexan
commented
3 days ago Looking more at the UBlue akmods, it appears there's actually nightly updates to the akmods container images that just aren't published as releases. So doing this would get the set of RPMs from the latest for the fsync kernel:
$ podman pull ghcr.io/ublue-os/fsync-kernel:40
...
$ podman container create --name=foo ghcr.io/ublue-os/fsync-kernel:40
...
$ podman container cp foo:/tmp/rpms $(pwd)
...
$ ls rpms/
kernel-6.11.2-201.fsync.fc40.x86_64.rpm kernel-devel-matched-6.11.2-201.fsync.fc40.x86_64.rpm kernel-modules-core-6.11.2-201.fsync.fc40.x86_64.rpm
kernel-core-6.11.2-201.fsync.fc40.x86_64.rpm kernel-headers-6.11.2-201.fsync.fc40.x86_64.rpm kernel-modules-extra-6.11.2-201.fsync.fc40.x86_64.rpm
kernel-devel-6.11.2-201.fsync.fc40.x86_64.rpm kernel-modules-6.11.2-201.fsync.fc40.x86_64.rpm kernel-uki-virt-6.11.2-201.fsync.fc40.x86_64.rpmThis is running into a similar issue as the copr though, it only has the latest available kernel version.
Describe the bug
When running either
rpm-ostree updateorujust update, I get the report that there's nothing to update. However I need to build a custom out of tree kernel driver for the lighting on my laptop keyboard (Asus Predator device), so I need thekernel-develinstalled. I tried this and then discovered it didn't match the currentkernel-corethat was installed by default.After installing
kernel-coreandkernel-devel:And when I try to install the matching version for
kernel-coreexplicitly:This is a brand new install of the latest Bazzite, with the only change to the repo being the addition of the VSCode RPM repo. There is no matching
kernel-develorkernel-headersfor the fsync kernel-core available in any repos.What did you expect to happen?
I expected there to be a
kernel-develandkernel-headersmatching the default shippedkernel-core. On Bazzite this is a custom UBlue fsync version (apparently) and doesn't keep up with the latest from upstream Fedora, so UBlue would be responsible for providing the associatedkernel-develandkernel-headersto match their customkernel-core.Output of
rpm-ostree statusState: idle Deployments: ● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable Digest: sha256:f0a715ec44064ebfa14504db0c72b3790542ce3bcd3d7f3b9fb068e6a04197e7 Version: 40.20240930.0 (2024-09-30T15:25:37Z) LayeredPackages: code grubby kernel-devel kernel-devel-uname-r sunshine zsh
ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable Digest: sha256:f0a715ec44064ebfa14504db0c72b3790542ce3bcd3d7f3b9fb068e6a04197e7 Version: 40.20240930.0 (2024-09-30T15:25:37Z) LayeredPackages: code grubby kernel-devel sunshine zsh
Hardware
$ inxi CPU: 14-core (6-mt/8-st) 12th Gen Intel Core i9-12900H (-MST AMCP-) speed/min/max: 771/400/4900:5000:3800 MHz Kernel: 6.9.12-205.fsync.fc40.x86_64 x86_64 Up: 27m Mem: 8.37/31.04 GiB (27.0%) Storage: 92.53 GiB/-4784 Procs: 460 Shell: Zsh inxi: 3.3.34
$ cat /sys/devices/virtual/dmi/id/product_name Predator PH315-55s
Extra information or context
The particulars of the device don't really matter, the problem is that there seems to be no repos to provide updates or support for the custom fsync
kernel-corethat ships with Bazzite.It's reasonable that the
kernel-headerandkernel-develmatching thekernel-corearen't installed by default in the Bazzite ostree refs, and it's certainly easier to distribute the customkernel-corepurely by including it directly there rather than providing it via an RPM repo on copr or something, but some method of getting thekernel-develandkernel-headersmatching it are a minimum necessity of having a custom kernel in the first place.