No RootFS download available for Ubuntu 24.10

[orende]

I just came here from this video from UbuntuConf 2024 and wanted to try FEX out. However, I'm running Ubuntu 24.10 on a Lenovo Yoga Slim 7x with arm64. When I ran the installer script, I got a list of RootFS alternatives, but none of them match my Ubuntu version. Should I use the closest one (24.04) or do something else in order to be able to proceed?

Debugging info:

fex-emu-armv8.4 (2501~o) ...
fex-emu-binfmt32 (2501~o) ...
fex-emu-binfmt64 (2501~o) ...

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.10
Release:	24.10
Codename:	oracular
$ uname -a
Linux user-Yoga-Slim-7-14Q8X9 6.12.0-28-qcom-x1e #28-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 24 03:56:34 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

[Sonicadvance1]

Use the closest available image for now. I haven't gotten around to making a 24.10 image due to issues around i386 Mesa cross compiling and some LLVM dependencies.

[kaazoo]

Hi, there is a Ubuntu Asahi 24.10 based config here: https://github.com/kaazoo/RootFS/blob/main/Configs/Ubuntu_24_10_asahi.json

You could remove the Asahi Linux specific stuff and should have a more or less generic Ubuntu 24.10 config.

Also see https://kernelpanik.net/vulkan_and_steam_on_ubuntu_asahi/

[Sonicadvance1]

Turns out the Debian/Ubuntu packages for i386 llvm have been broken for quite a few releases and it still isn't resolved in Oracular either. I've updated the Ubuntu 24.04 image to use kisak-ppa to work around the issue. But until Debian or Ubuntu package maintainers fix the broken packages it will be hard for us to build an "everything" Mesa config for this distro.

Fedora and Arch don't have this problem and package llvm i386 packages correctly. I'll should be able to update the Arch image soon. Although I may just wait for the Mesa 25.1 release.

[tobhe]

@Sonicadvance1 do you have a link to the issue the exact issue you are facing in Ubuntu and Debian? I can try to get things moving

[Sonicadvance1]

@Sonicadvance1 do you have a link to the issue the exact issue you are facing in Ubuntu and Debian? I can try to get things moving

I didn't open one but I found one:
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-18/+bug/2088386

The repro case is to just install any of the new i386 llvm packages and watch the world break since x86-64 and i386 packages overwrite each other's files. It is such a pervasive issue when developing 32-bit software (like mesa!) that I figured people were aware of it.

[tobhe]

Sounds familiar, I thought that got fixed at some point. Let me see if I can find out more and eventually escalate it.

EDIT: See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%231076131 fixed more than once, unfortunately it keeps coming back.
For the Ubuntu one: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-18/+bug/2063207

[kaazoo]

You could also just try out my root FS (see my blog post above) and/or config. I think we don't disable anything in our mesa build, so it may also just run fine on non-Apple hardware.

[tobhe]

So from what I found so far I think oracular is actually fixed and should not be a problem. A fix for noble was uploaded but caused a regression in bpftools and thus never landed (?) https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-18/+bug/2063207/comments/17.
I'll see if I can get noble fixed anyway.

[Sonicadvance1]

You could also just try out my root FS (see my blog post above) and/or config. I think we don't disable anything in our mesa build, so it may also just run fine on non-Apple hardware.

Looking at the ubuntu-asahi mesa packages provided on i386/x86-64.
gallium-drivers=softpipe,asahi,nouveau,r300,virgl,crocus,i915,iris,svga,radeonsi,zink,llvmpipe
vulkan-drivers=asahi,intel,intel_hasvk,amd,swrast,virtio,nouveau(?)

So it looks like explicitly freedreno is explicitly only built on arm/arm64, and turnip is explicitly commented out in the rules.

Additionally that means panfrost,etnaviv,vc4,v3d are disabled. d3d12 as well but I don't think too many people are using FEX under WSL atm.

[Sonicadvance1]

So from what I found so far I think oracular is actually fixed and should not be a problem. A fix for noble was uploaded but caused a regression in bpftools and thus never landed (?) https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-18/+bug/2063207/comments/17. I'll see if I can get noble fixed anyway.

I can see in the package file list that /usr/lib/llvm-19/lib/libLLVM.so conflicts in both i386 and amd64 llvm-19-dev on oracular still.
https://packages.ubuntu.com/oracular/amd64/llvm-19-dev/filelist
https://packages.ubuntu.com/oracular/i386/llvm-19-dev/filelist

I think some of the spirv and related packages have the same problem.

[tobhe]

I can see in the package file list that /usr/lib/llvm-19/lib/libLLVM.so conflicts in both i386 and amd64 llvm-19-dev on oracular still.

That could be, I have tested with 18. The Debian bug also mentions 19 being affected again. I'll see if I can reproduce it and create a tracking bug for that too.

EDIT: Oh the -dev packages aren't marked MultiArch at all so that is expected. libllvm19:amd64 and libllvm19:i386 can coexist as expected

[Sonicadvance1]

I can see in the package file list that /usr/lib/llvm-19/lib/libLLVM.so conflicts in both i386 and amd64 llvm-19-dev on oracular still.

That could be, I have tested with 18. The Debian bug also mentions 19 being affected again. I'll see if I can reproduce it and create a tracking bug for that too.

It looks like the workaround in the 18 package was to just move the SO file. There's still a bunch of conflicts looking at the file list. libLLVM.so was just the easy one to point out.
https://packages.ubuntu.com/oracular/amd64/llvm-18-dev/filelist
https://packages.ubuntu.com/oracular/i386/llvm-18-dev/filelist

But it /does/ look like some of the other tools were fixed...? I'll need to recheck once the llvm dev packages are fixed.