[Bug] you can't install akmod-wl

[dnkmmr69420]

When I install akmod-wl on my laptop using the silverblue-main:37 image, I get the following error. It works fine on the official silverblue image but this error apears on ublue. To reproduce, install silverblue, rebase to silverblue-main:37 image, type sudo rpm-ostree install akmod-wl then you get this error. The same thing happens on my laptop and in a vm.

Downloading from 'rpmfusion-nonfree'... done Importing packages... done Checking out packages... done Running pre scripts... done Running post scripts... done error: Running %post for akmod-wl: bwrap(/bin/sh): Child process killed by signal 1; run journalctl -t 'rpm-ostree(akmod-wl.post)' for more information

[dreamyukii]

can you run journalctl -t 'rpm-ostree(akmod-wl.post)' and send the output in github gist?

[dnkmmr69420]

one second. I gotta boot into the vm and type that in

[dnkmmr69420]

https://gist.github.com/dnkmmr69420/b372c2ecdb400afb33f6a20bd24bb9c7 here is the link

[bsherman]

Hi @dnkmmr69420 , I noticed you wanted the wl akmod.

Not sure if you got any further with this, but akmods can't be built trivially with an rpm-ostree install as on Fedora Workstation.

That's part of why the ublue-os project exists, trying to take some of that headache out of the system.

I know the team is working on a process to enable more akmods, but in the meantime, I added akmod-wl to the kmods I'm building on my image. https://github.com/bsherman/ublue-kmods/

If you are interested in how the build process works, take a look at the changes I made to add this new akmod to what I was already doing: https://github.com/bsherman/ublue-kmods/pull/1/files

Hope it's helpful!

[bsherman]

@dnkmmr69420 bonus!

We just added this driver to the new ublue akmods repo so it'll be in all ublue main and derivative images after the next build cycle.

[dnkmmr69420]

that's good

[xalt7x]

@castrojo , can you please reopen it?
I have exactly the same issue.

Reproduced with such steps:

1. clean install from "universalblue-38-x86_64-20230701.iso"
2. rpm-ostree update
3. Restart
4. rpm-ostree install akmod-wl

My logs bellow (actually they're the same as @dnkmmr69420 had)
akmod-wl_rpm-ostree_output.txt
akmod-wl_journalctl_output.txt

P.S. After rebasing to Fedora Silverblue 38 & adding RPMFusion installation succeed.

akmod-wl_rpm-ostree_output_fedora.txt
akmod-wl_journalctl_output_fedora.txt

P.P.S. I guess until this issue is resolved users need to produce custom image, fork akmod repo and enable required RPMs.

[bsherman]

@xalt7x I'm going to close this issue again. The original problem described here and as you describe, is not a problem with Universal Blue. What y'all have described is the general difficulty of using dynamically built kmods on an immutable system, specifically Fedora Silverblue/CoreOS/etc.

We did briefly include akmod-wl in the Universal Blue main images, before realizing when installed it prevents newer broadcom wireless devices from working.

P.P.S. I guess until this issue is resolved users need to produce custom image, fork akmod repo and ublue-os/akmods#46 (comment) required RPMs.

You have started to reference the recommended process here.

If you want to build akmods not provided in our akmods repo, you can fork and add to it. However, I'd suggest the following if you desire a kmod we provide, such as the legacy broadcom wl driver:

Generally speaking, please follow these instructions: https://github.com/ublue-os/akmods/blob/main/README.md?plain=1#L11-L13

But those instructions will have you installing every kmod available. In general, you probably only want to add one or a few from that repo.

Using those instructions as a template, I'd change it to look like this:

# Run the build script, then clean up temp files and finalize container build.
COPY --from=ghcr.io/ublue-os/akmods:${FEDORA_MAJOR_VERSION} /rpms/ /tmp/rpms
RUN rpm-ostree install /tmp/ublue-os-wallpapers-0.1-1.fc38.noarch.rpm && \
        chmod +x /tmp/scripts/build.sh && \
        /tmp/scripts/build.sh && \
        rpm-ostree install /tmp/rpms/kmods/kmod-wl-*.rpm && \
        rm -rf /tmp/* /var/* && \
        ostree container commit

This presupposes you will build a custom image based on silverblue-main, kinoite-main, etc which has rpmfusion repo enabled by default.

[bsherman]

Also, I did file this ticket to remind us to improve the readme in akmods ublue-os/akmods#49

[xalt7x]

The original problem described here and as you describe, is not a problem with Universal Blue. What y'all have described is the general difficulty of using dynamically built kmods on an immutable system, specifically Fedora Silverblue/CoreOS/etc.

Well, as a user I can say that:

1. On Fedora Silverblue after RPM Fusion setup I'm able to install "akmod-wl" and it even survives release upgrades.
2. On "Universal Blue" simple installation of that package doesn't work.

---

Is there any way to resolve this without building a custom image?

[bsherman]

Well, as a user I can say that:
2) On "Universal Blue" simple installation of that package doesn't work.

I do appreciate the distinction, thank you for clarifying.

Is there any way to resolve this without building a custom image?

My guess is this is one of the quirky problems with our unofficial upstream images. Every time we find one of those, it's just work to find out exactly what isn't working, how the upstream image differs from standard, and fix/mitigate it if possible.

I'll reopen, sorry for rushing to re-close.

[xalt7x]

Problem seem more global as other akmod from RPMFusion (free and non-free) cannot be installed on top of Universal Blue images.

I've tested "silverblue-main:38".
Packages that failed to install with "rpm-ostree install"

• VirtualBox (which depends on akmod-VirtualBox)
• akmod-wl
• ndiswrapper (which depends on akmod-ndiswrapper)
  Didn't test but pretty sure that legacy akmod-nvidia-390xx and akmod-nvidia-340xx won't install as well

All of them fail with the same error (posted here and here )

@castrojo , @bsherman
Do you think the exclusion of the pre-built drivers/akmods from the image can solve this problem?

[bsherman]

I should tell you, I don't see this as a high priority problem, but I do welcome any information you can provide if you want to keep working on solving it.

Why is this not high priority? From my perspective, the whole concept of Universal Blue is to provide the tools to enable users to have a highly reliable system, built with cloud technologies, customized (either personally, or through a downstream like bluefin or bazzite), and where the heavy lifting of compiling kernel drivers, etc, is all done before installing on one's machine.

Do you think the exclusion of the pre-built drivers/akmods from the image can solve this problem?

No, excluding rpms built in our akmods repo won't solve the problem. The problem existed before Universal Blue we had even started building akmods. Our first kmod was nvidia, and there was a clear desire by people in the community to have more drivers easy to access, so we've been working to improve that exactly because it's a pain to build kmods as an overlay.

Technically speaking, I think the problem is one of the following:

1. as mentioned before, there are differences in Silverblue ostree images vs container-native images, and that itself may be the issue
2. our upstream container-native images are not official from Fedora, so perhaps the unofficial versions have some quirks (and it looks like there will not be official ones until at least Fedora 40 https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable )

We have done nothing intentional to cripple the direct install of akmods as an rpm-ostree overlay, but I personally abandoned that approach and dove into Universal Blue contribution as soon as I found it. I always felt it was pretty horrible and error prone to do local kernel mod recompiles with every kernel update or driver update using akmod(Fedora) or dkms(ubuntu/debian); so being able to do that work in Github and installing only after things built clean has been wonderful.

[xalt7x]

Thanks for the explanation. Now I see the bigger picture
Well, to me, this issue kind of breaks the idea of general-purpose operating systems. For now, I'd stick with upstream and wait for "Ostree Native Container". As I didn't have major problems with kmods, I don't feel like the installation of some random driver packages is worth creating full-blown forks.

[xalt7x]

Hello @bsherman and @castrojo ,

I'm happy to inform that the new "nokmods" branches don't seem to be affected by this issue and bazzite issue #229

---

Today I've re-tested installation of the proprietary Nvidia driver on non-Nvidia ublue-os images

rpm-ostree install akmod-nvidia-470xx xorg-x11-drv-nvidia-470xx
rpm-ostree kargs --append=rd.driver.blacklist=nouveau --append=modprobe.blacklist=nouveau --append=nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init

Results:

1. silverblue-main:38 version 38.20230924.0 (2023-09-24T07:15:11Z)
   failed to build akmod
2. silverblue-nokmods:38 version 38.20230924.0 (2023-09-24T07:09:46Z)
   Nvidia driver worked after restart

---

Should I open a new issue in the akmods repo?

[bsherman]

Hello @bsherman and @castrojo ,

I'm happy to inform that the new "nokmods" branches don't seem to be affected by this issue and bazzite issue #229

Wow! That's good to know! And, I apologize for directly answering your question above completely incorrectly; apparently removing all our pre built akmods DID solve this. I truly thought the solution had been attempted and not halped.

Should I open a new issue in the akmods repo?

What would the new issue be for?

[xalt7x]

Should I open a new issue in the akmods repo?

What would the new issue be for?

Well, original issue was about an old Broadcom driver (for which we already have a simple workaround. And now we're discussing other, more global one (my bad :-) ) . So I thought, maybe it will be a good idea to open a new issue with more appropriate title, description, location etc...

[bsherman]

maybe it will be a good idea to open a new issue with more appropriate title, description, location etc...

You are always welcome to open issues where you think appropriate. :-)