@ConfuSomu Thank you the issue is now fixed!
2 Likes
Hi, I recently got my fingerprint login and sudo to work. Does someone else want to try out my “guide” to see if I missed to write down any crucial steps?
1 Like
Is anyone here on AMD? I couldn’t get into GDM and it reported session never registered. Not sure why.
Currently, running Arch on my AMD Framework 13.
4 Likes
You’ll get amdgpu hangs/crashes with the current kernel (6.5.x) and BIOS 3.02, though it works, ish. The reason GDM borks is because the Wayland session crashes the first time you load it. You can load the X11 session, logout and then start the Wayland session and it’ll work. Starting the Wayland session from the TTY also works: XDG_SESSION_TYPE=wayland dbus-run-session gnome-session, but you might have to do it twice.
If by chance you have something like gdm-plymouth-nox installed there won’t be an X11 session at all so you’ll need to load up the normal gdm package first or always go from the TTY.
Other than that, everything works (bluetooth, WiFi etc.). I did find that without configuring the regulatory domain I got stuck on 802.11n (WiFi 4) and 2.4GHz bands. But once you follow the setup in Network configuration/Wireless - ArchWiki everything works.
4 Likes
Just to note, all of this is no longer true since BIOS 3.03. It has resolved all the GPU issues with newer kernels, and everything works as expected now.
My AMD framework is much happier with BIOS 3.03 - all of the GPU issues I was having have been resolved as far as I can tell.
One issue I have is that the internal microphone is incredibly loud, and needs to be set to 30% volume to be usable. My other Intel framework has the same problem, and I was able to solve that by disabling Mic Boost in ALSA. Strangely, that hasn’t solved the issue here.
Finished my first setup with arch and hyprland, really diggin it so far:
Bios 3.03 no real issues so far, didnt tried to get my fingerprint working
5 Likes
Has anyone done a drive swap from an intel machine to an AMD machine? What packages should I pre-install (then uninstall afterward)?
I know at least: power-profiles-daemon instead of thermald.
1 Like
The “Arch” recommendation would be to do a fresh install.
In my case, I did a swap from a desktop Intel to and AMD, and here would be some packages to clear / change to adapt to the new system, so from the top of my head:
- Remove custom linux kernel compiled for Intel if any. Now I just use the default linux kernel on that machine, but there might be something better like linux-zen ?
- Remove intel-ucode and install amd-ucode
- Check mkinitcpio.conf for things like intel’s kernel graphics driver (e.g. i915) that shouldn’t be used on AMD; remove
vulkan-intel, and similar packages. - Updated xorg.conf in case there is any intel specific configuration there
- Nvidia drivers and related packages in case the Intel machine also had an NVIDIA GPU.
1 Like
Why is that the recommendation?
Anyway, I just went through it, and most of the things worked (I was on wayland so no xorg). I also installed vdpau instead of the intel libva for video acceleration, but it’s hard to know if video acceleration is working.
Strangely, wluma stopped working when going from my 12th gen Intel → AMD.
2 Likes
That’s usually the recommendation I have seen floated up a lot in Arch related forums when it comes to changing system, especially when it comes to relatively drastic changes like CPU and such.
The rationale would be that through the life of the system under configuration A, there might be a lot of packages installed to enable a specific features or work around a problem that is native to said configuration. Some users also compile from source (e.g some packages on AUR), even if they don’t realize, so a CPU change might lead to a broken system in case the CPU that the program was compiled against is not used anymore.
More generally, it is quite easy to forget what a given package was installed in the first place, and actually unused packages tend to accumulate.
Therefore, the recommendation when updating to a physical configuration with a significant amount of difference is to do a fresh re-install, then copy the relevant config and dotfiles. Refresh your knowledge of Arch basics, while getting caught up with any changes that might have happened in Arch, and kind of force the user to properly go through their files and triage through.
Find the equivalent of top for your CPU / GPU, then try playing “Costa Rica 4K” on Youtube or equivalent to check whether the relevant pipeline of the processors are getting activated ? This page should have more info in case you are interested / free to go down a not so deep rabbit hole 
1 Like
The most important is to get the amd-ucode package and linux-firmware (if you didn’t already have it, it would be unexpected if you don’t). When it comes to software tools, just uninstall tools you no longer need and adapt configurations.
It can be a lot simpler to just reinstall the OS but you can carry over your existing installation simply by installing the microcode. It’s just a little bit of a chore to adapt configurations if you need to do so.
It’s less of a pain to fresh install than undo various configurations done over time.
On my 12th Gen board, I have kernel parameters that help save battery in sleep, disable hid sensor for brightness keys to work, config for wifi card, disabling watchdog, fixed pci quirkiness powertop complaints about, etc
Some of these issues will likely won’t exist in the new amd board or even 13th gen board.
1 Like
A few other quirks I’ve noticed going from Intel → AMD – it seems like the AMD sound card can’t handle PIPEWIRE_LATENCY=64/48000 (I use this because I use my laptop as a guitar amp) compared to the intel one.
I had to remove that from my ~/.config/environment.d to get audio to stop crackling (unless I use an external DAC)
Whoah yeah, the amdgpu errors are gone after the bios update and wayland doesn’t crash upon the first start anymore. Thanks framework team <3
Edit: Oh, no i the flickering again:
amdgpu 0000:c1:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xfff5b000000 flags=0x0000]
Got this while i took a screenshot via slrup and grim, but i didn’t set the kernel parameter mentioned here for now → [RESPONDED] AMD Ryzen 7040 (7840U) - Arch Linux amdgpu errors, blank screen on opening Steam
Just as an Info 
1 Like
Is anyone else having a kernel panic upon boot if no external monitor is connected, but was connected at shutdown?
Basically:
- boot normally
- connect and enable an external display (HDMI extension card)
- shutdown
- disconnect the external display
- boot
This results in a kernel panic for me. Subsequent boots work fine.
1 Like
I’m not looking for help at this point anymore, just providing some information in case someone is stuck–or has more knowledge.
I was running into the issue of boot hanging on A start job is running for /dev/disk/by-uuid/...(no limit) if I cold booted off battery. If I did a restart or booted plugged-in, Arch would start fine.
https://bbs.archlinux.org/viewtopic.php?id=291044 led my to believe it was possibly a systemd bug or an issue with systemd on encrypted btrfs (didn’t use encryption though).
I tried all combinations of the following but still hung on battery boots:
- Downgrading to 254, 253, or 252 of systemd
- Changing kernel versions to lts and zen
- Downgrading kernel versions
- Grub/systemd-boot
- btrfs/ext4
- various kernel parameters
Thus led me to believe it was maybe a hardware issue, so I tried Debian Bookworm. Bookworm worked 100% fine. Upgraded everything on Bookworm and it worked fine. Changed to Debian Trixie and it worked fine.
Maybe it’s a timing issue or maybe it is a firmware issue with the nvme module I have, not sure.
Other thing to check is a bad /etc/fstab entry. I’ve run into that a couple of times if I make a typo in that file.
1 Like
So linux 6.7 is now available on Arch. Does anyone have good links for what this fixes? I feel like there were some energy savings associated with it for AMD, but I cannot find that discussion.