according DDR5 validated module list in the link below, I wanted to ask those who are running arch on FW16, what is the highest ram possible/necessary to have on FW16? and from which manufacturer?
Does using fwupdmgr for bios updates still require enabling the lvfs-testing remote repo? I remember when they first started supporting lvfs, they said you would need to enable lvfs-testing, but I’m wondering if you only need that for beta bios releases now? I noticed today that the 0.0.3.6 bios was available but when I looked it up, it says its still in testing and may not be suitable for production.
If you want to install the BETA versions, then yes.
Once it goes to stable it will be moved to the default lfvs repo
anyone have issues with Wi-Fi on the framework (AMD Ryzen 7040 Series)? I’m using Omarchy and I’m always running into issues with iwctl hanging up and not actually connecting to a network. Any ideas?
If you’re using the MediaTek wifi card that it came with, I would recommend changing it out for an AX210 Intel wifi card; Intel wifi cards are much better behaved on Linux.
1 Like
Thanks for the info, I guess this is a known issue with the latest release of omarchy. I wasn’t having issues on v1 release.
Well, that’s part of the problem. I’ve had problems with both Mediatek and Qualcomm wifi cards (in general not just wifi 7) where they’d work “just fine” on one kernel and would be completely broken on another, sometimes on minor version bumps. On top of that, you can easily get 1Gbit+ speeds with the AX210 (assuming you have capable equipment and internet connection) while the others struggle to even get 200-400Mbit in my experience.
1 Like
The mediatek also does a bit over 1Gbit on 5Ghz in my 13 but I already had the ax210 and it never let me down so I just keep using that since the be200 was a no-go.
You get those speeds on Linux? If so they must have fixed that over the last couple kernel releases.
Yes but that was way back when I first got the laptop so probably nothing to do with recent kernels.
I’m trying to set up the temperature sensor in arch + niri + waybar. Unfortunately, all I get in the waybar log is
[warning] module temperature: Disabling module "temperature", Can't open /sys/class/thermal/thermal_zone0/temp
Running sensors just gives
BAT0-acpi-0
Adapter: ACPI interface
in0: 10.00 V
power1: 0.00 V
I can’t see anything under /sys that looks like a temperature sensor. The commented-out line in the default waybar conf suggests /sys/class/hwmon/hwmon2/temp1_input, but there is only hwmon0 and hwmon1, and neither contains temp1_input.
Installing the acpi package and running acpi -t results in blank output.
Do I need to install another package to get the thermal sensor working? Is there something I have to configure in the BIOS in order to enable them?
CPU is AMD Ryzen 7 7840HS w/ Radeon 780M Graphics, if that matters.
Actually, now that I’ve engaged the brain, the problem is almost certainly the fact that I’m doing this setup in a VM. No wonder it can’t find the sensors 
I am in Batch 8 of the new gen framework 16. I got the 5070, but doing some reading, I’ve heard mixed things about Nvidia driver support on Arch. Something about poor Wayland support. Should I see if I can change my order to the AMD card, or will it be fine after getting configuration done. The only reason I went for the 5070 is because I don’t have any Nvidia in my house and thought it would be nice to have something with an Nvidia card for those weird incompatibilities that crop up with AMD.
1 Like
You’ll be fine for two reasons:
- Your laptop will operate in a hybrid-graphics mode, which means that most things on your desktop will be run on the AMD igpu, while only intensive applications like games will run on your 5070.
- Nvidia drivers have improved a ton over the past couple years. It was true that they didn’t work well with Wayland, but they’ve put a lot of work in to improve that. I’ve heard plenty of people say they don’t have issues with NVIDIA in wayland anymore.
Personally, before my fw16, I had a laptop with an intel igpu and nvidia discrete gpu, and even when nvidia drivers legitimately did suck for Wayland, I could still run with wayland just fine because the intel igpu could handle that fine. I don’t think there’s anything to worry about.
1 Like
Thank you for the detailed response!
Thank you!
I think you can get up to 128 GBs! I will find the post and update you on what type of memory gets up to that!
Edit I had the same question to and this was the response made by wonderful @Adrian_Joachim
I used this thread (among others) to help me diagnose, so I’m sharing what worked for me:
I was getting error messages like this after choosing my root dataset in ZFSBootMenu:
i2c_designware AMDI0010:00: Unknown Synopsys component type: 0xffffffff
so likely the kexec issue that other ZBM users seem to have hit. But as a new ZFS user, I really wanted to try ZBM. None of the teardown hooks recommended by ZBM docs worked on their own. Instead, I built a kernel for it with the following options:
CONFIG_I2C_DESIGNWARE_CORE=m
CONFIG_I2C_DESIGNWARE_PLATFORM=m
CONFIG_I2C_DESIGNWARE_BAYTRAIL=m
CONFIG_I2C_DESIGNWARE_PCI=m
(The zbm config.yaml Kernel options let you point it at the kernel/initramfs once built). I also removed autodetect from the ZBM kernel’s mkinitcpio.conf when building its initramfs. Finally, I modprobe -r’d all of them in my teardown script. That last part may have been overkill as I got error messages indicating that they weren’t loaded. After booting into arch with these settings the touchpad worked normally!
Just installed EndeavourOS on my Gen2 FW16 that arrived a couple of days ago. Ran into a rather puzzling issue that took a while to debug, so sharing here. Basically, what happened was that as soon as the graphical target was reached, the system blackscreened. But, TTY (via Ctrl+Alt+F3) worked, and when shut down, I would see system log info, same as when booting up. So basic text display worked, but the actual graphical environment wasn’t initializing. Note that I’m using KDE Plasma with Wayland. Notably, I was able to manually start an instance with dbus-run-session startplasma-wayland. I eventually found that the issue has to do with SDDM starting the greeter with X11, but the desktop environment using Wayland, and evidently, the FW16 doesn’t like that transition. Forcing SDDM to use Wayland for the greeter solved this issue. Configure /etc/sddm.conf.d/wayland.conf as shown here (and below):
[General]
DisplayServer=wayland
GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell
[Wayland]
CompositorCommand=kwin_wayland --drm --no-lockscreen
For me, this already existed, so just making sure these settings were correctly set solved the issue.
For reference, I installed the current 2025-11 (Ganymede) version of EOS, and have kernel version ~6.18 with FW16 BIOS 3.0.4 (latest).
(edits to fix codeblock formatting)