Various kernel/hwe issues supporting Surface/Asus devices

[castrojo]

Tracker issue for Asus and Surface. The main issue is no one on the team has any of these devices. We've been making these since like F37 and they're still mostly unmaintained. Since there's no real plan for any of these patches to go upstream we need to reevaluate our ability to provide these.

We tried to see if we could reuse Bazzite's kernel (which carries these patches) but those don't seem to work either. m2 is looking at re-enabling asus and surface for now so we have F41 back and working and see if we can limp along for the rest of the cycle.

Then we'd like to just drop support for asus and surface from bluefin for F42 and on, and then if someone wants to make builds on these it'll at least be a much easier dnf swap than what we had setup in the past.

[daegalus]

A dnf swap is fine as long as we don't have so many extra packages depending on the kernel packages. I tried a kernel swap and there was a bunch of surface and tools depending on stuff, even though it was an Asus laptop .

So if it is easier, a kernel swap would work for most.

I would also consider maintaining a set of Asus images. I just had no clue there was even a need for maintainers.

Also why not rely on upstream kernels for support of these hardware's. Maintain the pieces that bluefin covers, but rely on the testing and communities of the kernels for compatibility.

Is there a reason you need to maintain those yourselves?

I am just still not seeing where the pain points are of maintain Asus and Surface builds

[castrojo]

Also why not rely on upstream kernels for support of these hardware's.

The upstream kernel doesn't carry the patches for asus/surface. What we've done in the past is build images that swap in the asus-linux or surface-linux kernels. We were hoping that bazzite's kernel (which carries those patches), would give us one kernel to support both, but that hasn't been working.

[daegalus]

Also why not rely on upstream kernels for support of these hardware's.

The upstream kernel doesn't carry the patches for asus/surface. What we've done in the past is build images that swap in the asus-linux or surface-linux kernels. We were hoping that bazzite's kernel (which carries those patches), would give us one kernel to support both, but that hasn't been working.

Sorry, I misspoke. I did mean the Asus/Surface kernels as "upstream" as for these images the upstream would be the respectively asus-kernel or linux-surface projects. I had a surface in the past, and now an Asus, so I am familiar with both projects, and the few extra packages that are needed outside the kernel. Like the touchscreen daemon for surface and the rogctl and asusctl for asus.

But again, outside of maintaining the images with the normal bluefin stuff, why does the burden of maintaining the kernels/supporting them lie on this project? The Asus and Surface communities have their own discords, githubs, and support articles. Asus Kernel even has an outdated silverblue guide, which still is mostly relevant: https://asus-linux.org/guides/fedora-silverblue-guide/

If people open tickets or issues related to the kernels, just pass them onto the respective communities for those communities to help debug/fix. ANd only support the UBlue/Bluefin/Bazzite specific stuff.

[Edit] Again, I will read up on how to make custom images, and I can at minimum try to make Asus images and try to maintain them. Most of it will be copy and paste from what you guys already did.

[castrojo]

maintaining the images with the normal bluefin stuff, why does the burden of maintaining the kernels/supporting them lie on this project?

This is what we're discussing. It increases the amount of images we have to build and support and it's not something we're interested in doing considering the time that we have available. Similarly punting all of our issues to those projects isn't exactly something we're interested in either.

[daegalus]

ok, that is fair. I will see what I can do to make an Asus build going. Ill report back if I have any success.

[castrojo]

Happy to help get them going if someone makes a repo, it'd be grabbing this: https://github.com/ublue-os/image-template

And then doing a dnf kernel swap, which is relatively new (you probably want to avoid the rpm-ostree replace stuff as it's on the way out).

[daegalus]

Happy to help get them going if someone makes a repo, it'd be grabbing this: https://github.com/ublue-os/image-template

And then doing a dnf kernel swap, which is relatively new (you probably want to avoid the rpm-ostree replace stuff as it's on the way out).

Do you have a link or reference to the dnf kernel swap method? I am only familiar with the rpm-ostree replace method

[tulilirockz]

Do you have a link or reference to the dnf kernel swap method? I am only familiar with the rpm-ostree replace method

It should be quite similar to what you would do on Fedora Workstation to install it, but on the containerfile:

FROM quay.io/fedora-ostree-desktops/silverblue:41

RUN dnf5 config-manager addrepo --from-repofile=https://pkg.surfacelinux.com/fedora/linux-surface.repo
RUN dnf5 -y remove kernel* && \
    rm -r /root # not necessary on ublue-os/main derived images
RUN dnf5 -y install --allowerasing kernel-surface iptsd libwacom-surface

This seems to build just fine, but I haven't tested it. You should be able to replace the base image with whatever one you want to use (Bazzite, Bluefin, Aurora [...])

[daegalus]

Do you have a link or reference to the dnf kernel swap method? I am only familiar with the rpm-ostree replace method

It should be quite similar to what you would do on Fedora Workstation to install it, but on the containerfile:

FROM quay.io/fedora-ostree-desktops/silverblue:41

RUN dnf5 config-manager addrepo --from-repofile=https://pkg.surfacelinux.com/fedora/linux-surface.repo
RUN dnf5 -y remove kernel* && \
    rm -r /root # not necessary on ublue-os/main derived images
RUN dnf5 -y install --allowerasing kernel-surface iptsd libwacom-surface

This seems to build just fine, but I haven't tested it. You should be able to replace the base image with whatever one you want to use (Bazzite, Bluefin, Aurora [...])

Awesome, thx. I'll probably get something up and running soon (like tomorrow soon).

[daegalus]

Ok, I have made some progress. I just started a build that I think might succeed. It is missing a few things that got removed was part of kernel removal, but then fail when trying to add them (v4l2loopback, kmods for controllers, etc).

But for now I think I can get a functioning image. I will be rebasing to it when I get it all working.

https://github.com/daegalus/redfin (I may or may not have to rename it, cause I don't want issue with Redfin the real estate company. Maybe Rosefin or Rockfin [since it sounds close to ROG], or something come up with something unique.)

[tulilirockz]

Ok, I have made some progress. I just started a build that I think might succeed. It is missing a few things that got removed was part of kernel removal, but then fail when trying to add them (v4l2loopback, kmods for controllers, etc).

But for now I think I can get a functioning image. I will be rebasing to it when I get it all working.

https://github.com/daegalus/redfin (I may or may not have to rename it, cause I don't want issue with Redfin the real estate company. Maybe Rosefin or Rockfin [since it sounds close to ROG], or something come up with something unique.)

You can remove the kernel packages w/o removing anything else by using this instead:

RUN for pkg in kernel kernel-core kernel-modules kernel-modules-core ; do rpm --erase $pkg --nodeps ; done

[daegalus]

Ok, I had some successful builds. I rebased onto the image and it wouldn't boot. Just nothing after selecting it in the menu.

Now I am thinking that I replaced the kernel, but do I need to rerun something with dracut? Or rebuild the initramfs? Because I don't think it's the Nvidia drivers. I just get a failed boot, no kernel messages.

[drf-jpg]

@tulilirockz I'm not sure that you're able to use DNF5 to update kernels at this time. From: https://fedoraproject.org/wiki/Changes/DNFAndBootcInImageModeFedora#Current_status.

DNF5 when installed on a image-based/ostree system can be used to install RPMs if the system is unlocked, it also works on most container builds, one major exception at the moment are kernel installations and kernel updates. DNF is not part of image variants at the moment, however CoreOS is exploring adding it via: coreos/fedora-coreos-tracker#1687

[tulilirockz]

@tulilirockz I'm not sure that you're able to use DNF5 to update kernels at this time. From: https://fedoraproject.org/wiki/Changes/DNFAndBootcInImageModeFedora#Current_status.

DNF5 when installed on a image-based/ostree system can be used to install RPMs if the system is unlocked, it also works on most container builds, one major exception at the moment are kernel installations and kernel updates. DNF is not part of image variants at the moment, however CoreOS is exploring adding it via: coreos/fedora-coreos-tracker#1687

Ive done it multiple times, you can do it, even if it is unsupported LOL. At build time it should be entirely fine

[daegalus]

Regardless, the swap works, but it never boots the kernel.

So something in the swap is causing it to not rebuild initramfs.

I tried running. dracut --regenerate-all -f and rpm-ostree initramfs --enable. Both through an error about ostree. Dracut just said it's an ostree

rpm-ostreee complains about not being booted by ostree.

Haven't figured out the issue.

[drf-jpg]

I've been trying to take advantage of this myself for #2066 in drf-jpg/bluefin-mainline#1 but I get a kernel panic immediately after boot. Seems to be a problem with the initramfs.

I put details in that PR about updating kernels, but I'm not having too great a time with it. Perhaps it will help you, though?