ublue-os / akmods Goto Github PK
View Code? Open in Web Editor NEWA caching layer for pre-built Fedora akmod RPMs
License: Apache License 2.0
A caching layer for pre-built Fedora akmod RPMs
License: Apache License 2.0
Should improve the README to help users know how to use this repo to install a single kmod rather than all of them as the current instructions describe.
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
This repository currently has no open or pending branches.
Containerfile.common
Containerfile.extra
Containerfile.nvidia
Containerfile.nvidia-open
Containerfile.test
Containerfile.zfs
.github/workflows/release-please.yml
google-github-actions/release-please-action v4
.github/workflows/reusable-build.yml
actions/checkout v4
Wandalen/wretry.action v3.5.0
docker/metadata-action v5
redhat-actions/buildah-build v2
redhat-actions/buildah-build v2
ASzc/change-string-case-action v6
Wandalen/wretry.action v3.5.0
docker/login-action v3
sigstore/cosign-installer v3.6.0
ubuntu 24.04
In my custom image, the facetimehd kmod fails. I have checked with the blue-build team and they think it has something to do with kernel versions.
[stage-5 4/5] RUN --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind,from=stage-modules,src=/modules,dst=/tmp/modules,rw --mount=type=bind,from=stage-akmods-main,src=/rpms,dst=/tmp/rpms,rw --mount=type=bind,from=ghcr.io/blue-build/cli:83d654d3a25c2fc679e8d814badd579ec5337020-build-scripts,src=/scripts/,dst=/tmp/scripts/ --mount=type=cache,dst=/var/cache/rpm-ostree,id=rpm-ostree-cache-myos-gnome-intel-mac-latest,sharing=locked source /tmp/scripts/exports.sh && /tmp/scripts/run_module.sh akmods '{"type":"akmods","install":["facetimehd"]}':
6.705 Updating metadata for 'rpmfusion-nonfree-updates-testing'...done
7.878 Updating metadata for 'rpmfusion-free'...done
8.725 Updating metadata for 'rpmfusion-nonfree-updates'...done
9.518 Updating metadata for 'rpmfusion-free-updates-testing'...done
10.81 Updating metadata for 'rpmfusion-free-updates'...done
12.23 Updating metadata for 'updates'...done
12.61 Updating metadata for 'fedora-cisco-openh264'...done
15.32 Updating metadata for 'fedora'...done
15.94 Updating metadata for 'updates-archive'...done
15.95 error: Updating rpm-md repo 'updates-archive': cannot update repo 'updates-archive': Yum repo downloading error: Downloading error(s): repodata/2e7db4492173b6c437fd1299dc335e63d09f24cbdadeac5175a61b787c2f7a44-filelists.xml.zck - Cannot download, all mirrors were already tried without success; Last error: Status code: 403 for https://fedoraproject-updates-archive.fedoraproject.org/fedora/40/x86_64/repodata/2e7db4492173b6c437fd1299dc335e63d09f24cbdadeac5175a61b787c2f7a44-filelists.xml.zck (IP: 3.161.213.74)
ERROR: failed to solve: process "/bin/sh -c source /tmp/scripts/exports.sh && /tmp/scripts/run_module.sh akmods '{"type":"akmods","install":["facetimehd"]}'" did not complete successfully: exit code: 1
[02:07:02 ERROR] => Failed to build image
Error: Process completed with exit code 1.
`
The more kmods we add to Containerfile.common
the longer builds take, and, the more likely we break downstream builds for Aurora/Bluefin and others.
Specifically, there are a number of kmods which have been added which are only used in Bazzite. While these are good for us to build, Bazzite builds less frequently and is more actively than managed than some other downstream images.
I propose to add another "stream" of kmod builds to this repo so we'll have:
Containerfile.nvidia
- as is, just builds nvidia kmodContainerfile.common
- will build common/shared kmods (eg, those which were originally in main:kmods
images, and/or are used in both Aurora/Bluefin and Bazzite)Containerfile.extra
- new addition will be primarily for kmods used in Bazzite or any others we need to build but don't fit in common
The new extra
category would NOT blog merge queues for akmods
which would allow our hwe
and bluefin
builds to stay more reliable, even if we have somewhat experimental kmods in extra
.
Hi everyone! Just got Bazzite on my desktop and this is my first daily drive immutable distro. Loving it so far.
I know it's kinda niche but I would like to request the Akmod for the Nuvoton NCT6687-R chipset. It is responsible for the sensors on some B550 motherboards from MSI and ASUS.
Here is a repository that already builds a kmod for it: https://github.com/Fred78290/nct6687d
Not sure why no one tried to upstream it to mainline kernel, tho.
All Images
I saw these failures...
https://github.com/ublue-os/akmods/actions/runs/8421318593/job/23058006965#step:12:160
I checked the COPR...
https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/packages/
Looks like sentry updated fsync-kernel...
from: 6.7.9-204.fsync
to: 6.7.9-207.fsync
Hello i cannot find how to install it and i cannot find on the akmod repo https://copr.fedorainfracloud.org/coprs/ublue-os/akmods/
● ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-nvidia:39 (index: 0)
Digest: sha256:f04201a1821488caedbc333991afa5b835f0418f8cc600966be7ee012d65ea58
Version: 39.20240130.0 (2024-01-31T04:03:22Z)
BaseCommit: fc1981d154b646bdf8ec260d8d3acbf5c827689c7570418eaaabe4cce72deff3
Commit: b3ec67a7f59d820ac26b98224bbd0eba66363ad7ae0bbe7d93541456b481911b
├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2023-08-10T15:35:19Z)
├─ copr:copr.fedorainfracloud.org:ublue-os:akmods (2024-01-30T22:21:21Z)
├─ fedora (2023-11-01T00:12:39Z)
├─ google-chrome (2024-01-30T18:24:44Z)
├─ rpmfusion-free (2023-11-04T16:49:08Z)
├─ rpmfusion-nonfree (2023-11-04T17:26:32Z)
├─ rpmfusion-nonfree-nvidia-driver (2024-01-25T09:11:40Z)
├─ rpmfusion-nonfree-steam (2023-08-10T16:27:35Z)
└─ updates (2024-02-01T01:46:41Z)
Staged: no
StateRoot: fedora
RemovedBasePackages: gst-editing-services 1.22.5-1.fc39 rygel 0.42.5-1.fc39
LayeredPackages: fish flatpak-spawn langpacks-fr openssl1.1 perf strace vagrant
LocalPackages: xpipe-1.7.16-1.x86_64
Silverblue
Per #54 , the akmods repo now builds the following images/tags:
should update README to reflect this with appropriate examples for usage.
Relates to ublue-os/website#403
Here is the relevant terminal output:
0.161 ================================================ Start 'akmods' Module ================================================ 0.174 Installing akmods 0.175 Installing: openrgb xpadneo 0.198 error: Handling argument /tmp/rpms/kmods/*openrgb*.rpm: No such file or directory (os error 2)
Here is my recipe.yml:
Recipe.yml
It would be nice if we can at least include the major.minor.patch for the kernel version in the tag.
Ie
akmods:fsync-40-6.9.8
As an additional tag. It would make it easier to grab older versions and match them to the kernel instead of looping through the ostree.linux label and then pulling through date-tag
Running Silverblue as a VM inside of Parallels on an M1 Mac, it would be great to have a way to install the Parallels Tools into the VM.
I did some googling and couldn't find an easy way to download these tools from the internet - Parallels seems to want you to get the ISO from the Parallels installation. I'm willing to provide them if needed, I don't want to put a link in the issue in case it violates Parallels terms of use (I don't know that it does, I just haven't looked)
Thanks!
Silverblue
the xone
driver disables too many other controllers by disabling the stock xpad
driver in the kernel ... to properly use it, we also need to include xpad-noone
but we don't have a quick way to do that right now.
For now, let's disable xone
. I'll file another ticket to get xpad-noone
working and add both back.
See ublue-os/main#25
I'd like to request the it87
kernel module because sensors
and sensors-detect
doesn't expose my fans on my motherboard (Gigabyte B550i). I need this functionality because I have a deshrouded GPU and use mobo fan headers for my GPU fans. I can use CoolerControl for that easily, however I need the sensors/control of those sensors via this module.
I was evaluating EndeavourOS and was able to install that from AUR by going down a rabbit hole.
Bazzite
In order to support custom kernels (eg for asus and surface images) we need those kernels to be used as part of the kmods build process.
Perhaps we do something like this:
matrix:
kernel_flavor: [default, asus, surface]
And then our kmods Containerfile(s):
default
asus
/surface
Tags should be something like this:
Sadly, after JUST getting xone
added, we've had to disable it as they don't yet have a tagged release with kernel 6.3 support, which is the new kernel on Fedora as of today.
This ticket is a reminder to check-in on the following repos to watch for movement on this issue:
See: #18
Hello,
Surface books come with an integrated wireless xbox receiver but no hardware pairing button. This means on the current surface images there is no way to initiate paring. Would it be possible to integrate the patch in the following pull request? medusalix/xone#45
Thanks!
This simplifies things in Containerfile so there is no need to edit this whenever new Fedora version gets released.
main-39
= main-latest
This one benefits from it:
blue-build/legacy-template#212
Any chance to include the acpi_ec kmod package?
it provides /dev/ec which is used to control fans and other features in several MSI laptops
upstream: https://github.com/saidsay-so/acpi_ec
there is a repo which contains required files to build: https://copr.fedorainfracloud.org/coprs/maximmaxim345/nbfc-linux/package/acpi_ec-kmod/
Desktop
@bsherman has enabled builds for Fedora 40 but disabled those which are not yet supported or fail to compile.
This issue will track the rollout to the remaining packages.
Builds to enable:
I try to add the evdi DisplayLink driver in my Containerfile:
COPY --from=ghcr.io/ublue-os/akmods:${AKMODS_FLAVOR}-${IMAGE_MAJOR_VERSION} /rpms/ /tmp/akmods-rpms
RUN find /tmp/akmods-rpms
RUN rpm-ostree install /tmp/akmods-rpms/kmods/kmod-evdi-*.rpm
However, during image building, I get the following error:
error: Could not depsolve transaction; 1 problem detected:
Problem: conflicting requests
- nothing provides evdi-kmod-common >= 1.14.1 needed by kmod-evdi-6.6.8-200.fc39.x86_64-1.14.1-4.20231123gita943d98.fc39.x86_64 from @commandline
Did I made a mistake during the integration of this akmods?
Or is this a bug with the package?
All Images
As of ~5 hours ago, the openrazer
and openrgb
akmods are causing build failures in my ublue-os/startingpoint builds.
See my GitHub Actions workflow. The error for both akmods appears similar:
Problem 1: package kmod-openrazer-6.7.3-200.fc39.x86_64-100.0.0.git.530.886f986d-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System
Problem 2: package kmod-openrgb-6.7.3-200.fc39.x86_64-0.0.git.15.f3f94bed-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.7.3-200.fc39.x86_64 from updates
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive
- package kernel-core-6.6.14-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- conflicting requests
- cannot install both kernel-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-core-6.7.3-200.fc39.x86_64 from updates
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from updates-archive
- package kernel-6.6.14-200.fc39.x86_64 from @System requires kernel-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
- package kernel-modules-extra-6.6.14-200.fc39.x86_64 from @System requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System
See my ublue-os image repository for more details, particularly:
Image recipes: recipe-sway.yml and recipe-hyprland.yml -- failure takes place in both recipes, since they share common akmods configuration.
Akmods module: common-akmods.yml
Image Fedora version: 39
These recipes were building successfully without any changes ~19hrs ago, see https://github.com/michaelhaaf/wayblue/actions/runs/7808947655/job/21299949213#step:15:255 for most recent successful build.
See https://github.com/michaelhaaf/wayblue/actions/runs/7818120114/job/21327583531#step:15:281 for full log.
=== Launching module of type: akmods ===
Installing akmods
Installing: openrazer openrgb
Enabled rpm-md repositories: copr:copr.fedorainfracloud.org:ublue-os:akmods fedora-multimedia rpmfusion-nonfree-updates rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree fedora-cisco-openh264 fedora updates updates-archive
Updating metadata for 'copr:copr.fedorainfracloud.org:ublue-os:akmods'...done
Updating metadata for 'fedora-multimedia'...done
Updating metadata for 'rpmfusion-nonfree-updates'...done
Updating metadata for 'rpmfusion-free-updates'...done
Updating metadata for 'rpmfusion-free'...done
Updating metadata for 'rpmfusion-nonfree'...done
Updating metadata for 'fedora-cisco-openh264'...done
Updating metadata for 'fedora'...done
Updating metadata for 'updates'...done
Updating metadata for 'updates-archive'...done
Importing rpm-md...done
rpm-md repo 'copr:copr.fedorainfracloud.org:ublue-os:akmods'; generated: 2024-02-06T09:39:07Z solvables: 140
rpm-md repo 'fedora-multimedia'; generated: 2024-02-06T09:45:57Z solvables: 380
rpm-md repo 'rpmfusion-nonfree-updates'; generated: 2024-02-04T23:32:13Z solvables: 62
rpm-md repo 'rpmfusion-free-updates'; generated: 2024-02-04T23:14:39Z solvables: 152
rpm-md repo 'rpmfusion-free'; generated: 2023-11-04T16:49:08Z solvables: 445
rpm-md repo 'rpmfusion-nonfree'; generated: 2023-11-04T17:26:32Z solvables: 208
rpm-md repo 'fedora-cisco-openh264'; generated: 2023-03-14T10:57:01Z solvables: 4
rpm-md repo 'fedora'; generated: 2023-11-01T00:12:39Z solvables: 70825
rpm-md repo 'updates'; generated: 2024-02-07T01:42:10Z solvables: 21559
rpm-md repo 'updates-archive'; generated: 2024-02-07T02:09:46Z solvables: 28569
Resolving dependencies...done
error: Could not depsolve transaction; 2 problems detected:
Problem 1: package kmod-openrazer-6.7.3-200.fc39.x86_64-100.0.0.git.530.886f986d-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System
- conflicting requests
Problem 2: package kmod-openrgb-6.7.3-200.fc39.x86_64-0.0.git.15.f3f94bed-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.7.3-200.fc39.x86_64 from updates
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive
- package kernel-core-6.6.14-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
- conflicting requests
- cannot install both kernel-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-core-6.7.3-200.fc39.x86_64 from updates
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from updates-archive
- package kernel-6.6.14-200.fc39.x86_64 from @System requires kernel-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
- package kernel-modules-extra-6.6.14-200.fc39.x86_64 from @System requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
- cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System
error building at STEP "RUN chmod +x /tmp/build.sh && /tmp/build.sh && rm -rf /tmp/* /var/* && ostree container commit": error while running runtime: exit status 1
time="2024-02-07T16:40:37Z" level=error msg="exit status 1"
Error: Error: buildah exited with code 1
It seems RPMfusion has dropped the 470 driver ( https://admin.rpmfusion.org/pkgdb/package/nonfree/nvidia-470xx-kmod/ ). So, it may be time to switch to negativo17 for nvidia.
@KyleGospo and I have previously discussed this. The negativo17 packaging allows more granular installation of only desired components. For example, in ucore I already use negativo17 as it allows only installing nvidia-driver-cuda
which is just the driver and CUDA support, as is proper for a server. RPMfusion's package pulled in all of Xorg and Wayland. In addition, negativo17 provides a cuda-gcc
package to aid users needing (nvidia's CUDA does not yet support GCC 14 which is current in Fedora).
We were not keen to move to negativo17 before now, but because they only package the latest drivers, while we were using both latest and legacy 470 drivers from RPMfusion.
With RPMfusion's orphaning of the 470 package, I believe we should now move to negativo17. This will mean dropping the 470 driver... but it's orphaned upstream, so I unless we want to maintain the package, I don't think we can continue providing it in good conscience.
I'll prep the appropriate PRs for this.
I'd like to request that the digimend-kernel-drivers be included to allow support for more drawing tablets than the Wacom driver supports.
I hope this request is being done properly.
Bazzite
There are several packages which we'd like to include in ublue, specifically kmods, which do not have an upstream akmod build, or do not have an RPMs built at all, even if the project provides a spec file.
Some examples:
Beyond these which have no current solution, there are things we install which are in random COPR repos or in negativo17. Negativo17 seems reliable, but it's still an additional third party beyond rpmfusion, and random COPRs, well, it's like ubuntu-PPA land. If we don't know the maintainer, it's a gamble.
The goal is to provide a team ublue managed repo that:
For any RPMs we need to build, we should host the spec files in our own github repo. This ensures control of what we are building and minimizes risk of a third party causing our RPMs to include any surprises.
I believe we could have a single repo rpm-specs
(open to suggestions on name) with the various maintained spec files in it.
If we went all in on some of my suggestions for packages above it could include:
There may be subdirs for supporting files for each spec, or perhaps each spec goes into a distinct sub-dir by default.
One proposal, though a potentially janky approach, would involve having a dedicated github repo which is setup for github pages. This is distinct from rpm-specs
, maybe call it rpm-repo
.
Github actions in this repo would on whatever trigger, build the RPMs from rpm-specs
, run a create-repo
script that creates the yum repo metadata, and then commits resulting metadata and RPM binaries to the rpm-repo
git repo such that the contents of the repo are available to use.
This is kinda janky, but it could possibly work.
The major pro is we don't need any extra user management, its just github.
The major con is we'll be reinventing some wheels and doing some janky stuff.
Another proposal is to use a single COPR repo/project (insert proper terminology here). The spec files would still be hosted in a github rpm-specs
repo as described above, but all building and repo hosting would be done in COPR.
There are webhooks and apis in COPR which should at least allow triggers of builds when changes are made to specs, or from other actions. Possibly the api could be used to add a new spec to the COPR.
The major pro here is COPR is specifically made to build and host RPMs.
The major con is user access/permissions management. We think it's single user. A possible workaround could be to manage limited access to a shared credential similar to how we already manage private key escrow for signing OCI images. Also, if we only need access to "setup" a build/project since webhooks could trigger rebuilds, this may be less of an issue than originally thought.
I'd like some team feedback on this. A few of us have been thinking about this for months, but not really made progress. It becomes more of a blocker to progress as the days go on. Whichever path is taken will require some effort. No need to rush it, but it's good to be on the same page with goals and approach.
Please merge upstream fixes released recently from https://github.com/medusalix/xone or specifically this commit to fix an issue with the wireless xbox 2.4ghz dongles locking up.
Issue referenced in discord here: https://discord.com/channels/1072614816579063828/1211498927489159168
Thanks!
Bazzite
These kmods have spec files here: https://github.com/ublue-os/packages/tree/main/akmods
And build in our copr here: https://copr.fedorainfracloud.org/coprs/ublue-os/akmods/packages/
They aren't currently building for kernel 6.8, so they are still in the repo but skipping build conditionally.
I'd like to request Fingerprint Drivers XPS 15 9500 to allow logging into the system with.
I am running on bluefin dx.
All Images
Hello,
I see that currently Bazzite has dedicated images for Framework/Surface/Asus laptops (as seen in Image Picker). Would it be possible/feasible to also add dedicated images for Tuxedo latpops?
From what I gather, this would require building/including kernel modules/drivers from tuxedo-drivers and also preinstalling Tuxedo Control Center app - which itself depends on said tuxedo-drivers.
I found that there was already ticket related to that in akmods repo, but I'm not sure if any decision regarding it has been made. Also (in the meantime), tuxedo-keyboard has been deprecated in favor of tuxedo-drivers.
I'm asking this because I have a Tuxedo laptop on the way (Pulse 14 Gen 3) and there are some HW related features (KB backlight, fan control etc.) which won't work properly with Linux kernel without those drivers. If possible, I'd like to use Bazzite or Bluefin on this laptop since Bazzite has been great on my Steam Deck OLED so far.
Thank you in advance.
Best Regards
So I'm looking at trying to do a PR to add an akmod to the repo ( https://github.com/DHowett/framework-laptop-kmod ) but there's something that I just don't quite understand, the "how to" points to the wl script, and its just that, a script. How do you actually download the code for the mod into the build? Like I can get the script together, but I don't think that'll download the actual relevant code into the mod. Do I need to wrap it in a COPR? I'm attempting to wrap this up in a script as we speak so I can get it before the akmod is wrapped into ublue so I can simplify it upstream, but even then its complicated, as the make file for the kmod assumes your applying it to the system you're on, so I'd need to know the kernel that's being built, not the kernel of the runner building it... Its a fun challenge! Jorge suggested I open this so here we are.
We have "kernel package skew" when our upstream images are built on kernel A.B.C, but before our akmods
images are built the the fedora repos update to kernel A.B.D. Or sometimes, even while the upstream images are building the change happens resulting in those having both kernels, while we expect a single kernel version.
The idea would be to notice if our upstream base image is not current with fedora repo, and upgrade the kernel packages during the build.
Major Concern - this may prevent downstream (eg, hwe and bazzite) from further replacing kernels?
Minor Concern - this WILL add the extra weight of another set of kernel packages in a layer to to main
images, which is wasted in downstream images which replace the kernel.
This requires implementation in both akmods
and main
.
There are a number of copr packages for system76 support https://copr.fedorainfracloud.org/coprs/szydell/system76/
These are a lot or quality of life pieces and hardware support for things like the keyboard backlight and fan control.
All Images
Bluefin and Aurora are now shipping this kmod and it can be moved from extras to common.
I'd like to request the package akmod-VirtualBox
.
Currently, I cannot use VirtualBox in ublue with secure boot. I should be very straightforward, since it is already provided in RPM Fusion Free.
All Images
Following up on: #28
We now have an akmods repo hosted under the org Copr. Access can be requested from the Copr here: https://copr.fedorainfracloud.org/coprs/ublue-os/akmods
This shouldn't impede looking for potentially better options in the future though
Tuxedo-keyboard adds drivers for keyboard backlight, fan control and other hardware enablements on Tuxedo Computers and other laptops using Clevo chassis.
Only available as dkms at the moment, although I have opened an issue about kmod availability
All Images
I would like to request to add acpi_call dkms to the akmods. (this way ublue will be superior to fedora (that's a joke please don't kill me))
I have yet another motherboard that uses acpi to controls fans and some other stuff. I don't even understand why it isn't in the mainline kernel since a lot of laptops seems to have use of it but still.
Neraly all lenovo, clevo, PCspecialist laptops are concerned. and there are many more that I don't know.
This is a common issue for me on a lot of distro to control my fans and sometimes power.
All Images
There was a failed effort to create an akmod spec and build for openrazer over at their official build on OBS
We could probably pickup the contributed akmod spec file and build it in COPR then it would be easy to add here with our new akmods flow.
It is a bit more commitment than just using existing akmods though.
The xone driver disables too many other controllers by disabling the stock xpad driver in the kernel ... to properly use it, we also need to include xpad-noone .
Goals of this ticket:
xpad-noone
building as akmodxpad-noone
to this repo/imagexone
See: #25 and ublue-os/main#256 for context.
I think we should also offer https://github.com/NVIDIA/open-gpu-kernel-modules. Maybe do -nvidia and -nvidia-open.
RPMFusion has packages for each variant.
All Images
Since we use differing kernels from upstream, we should be properly setting the ostree.linux label on the image to reflect the actual kernel within the image.
Relates: ublue-os/hwe#220
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.