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.
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
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.
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)
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.
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.
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.
I’m running 6.7.1-arch1-1 on my Framework 13 AMD and so far so good. I had issues with Steam not running via flatpak, but I switched to the command line installation and it has been fine. That may have been related to my changing the bios to enable gaming.
I’m running KDE with Wayland and it’s been stable.
Does anyone have any suggestions for fixing severe flickering on Framework 13 13th Gen Intel, running Artix (Arch linux derivative)?
I have tried:
Reading Intel_graphics on the Arch Wiki top to bottom
Reading Framework_Laptop_13 on the Arch Wiki top to bottom
Switching from xf86-video-intel to modesetting [no screen output: either ‘failed to find device’ or ‘no driver available’]
options i915 enable_psr=0 enable_fbc=0 enable_dc=0 in /etc/modprobe.d/i915.conf
Option "DRI" "2" in /etc/X11/xorg.conf.d/20-intel.conf - no change
Option "DRI" "iris" - no change
Deleting /etc/X11/xorg.conf.d/20-intel.conf and uninstalling xf86-video-intel [claims it can’t find the intel module and doesn’t even try to load modesetting
Using XFCE instead of KDE [less flickering, but window content still doesn’t update until you resize the window]
Switching from 60Hz to 45Hz in system settings
Installing kwayland, and plasma-wayland-protocols, and trying Plasma with Wayland [black screen with underscore cursor only, nothing else happens]
export MESA_GL_VERSION_OVERRIDE=2 in /etc/profile [no change]
Trying Ubuntu 22.04 live ISO [WORKS. But I want to use Arch if possible]
I’ve started a project to tidy up the Framework entries on the wiki and organise information based on the generation of mainboard (along with setup and troubleshooting new parts that shipped with each iteration). I own a 7040 series Laptop 13 and have started to move information over to here but I need help from owners of other models to populate each page. You can find an overview here and the discussion section here.
No issues with bog standard Arch, Hyprland WM on iGPU since 6.5-ish up through current (6.9.3 IIRC), also i5-1340P.
That’s an awful lot of things you’ve messed with. Any luck if you go back to booting from a live installer medium? Maybe try one of the officially supported distros also?
Heya - thanks for the suggestion! I’ve just tried a KDE arch/artix installer and while it was fine at first, issues quickly became apparent. The wallpaper did not display (instead just black) - and even manually setting did not help.
I tried Ubuntu 22.04 again, and while it appears to work, some digging suggests that it is using software-based rendering in the live environment rather than hardware rendering, which causes the issue. All tests:
Distro
Desktop Environment
Status
Ubuntu 22.04 - live
GNOME
works, but software rendering
Parrot OS - live
MATE
works, but software rendering
Arch/Artix 202308 - live
KDE
does not work - hardware rendering
Arch/Artix
KDE
does not work - hardware rendering
Hardware/software rendering was confirmed by glxinfo | grep -i direct, or Firefox → about:support if glxinfo wasn’t available.
…so to this end, I am reasonably confident in diagnosing the issue as a faulty iGPU. Going to reach out to support. Thanks for the advice once again!