To add to this, with rustup you can add different build targets than the current system - could let you build the binary on a more powerful pc and then just scp it over.

Your build looks good (setting the ongoing intel issues that somebody else already mentioned aside), but personally I’d consider a different drive than the Samsung - it’s a great drive, but usually overpriced imo. If you can get it for a good price then absolutely go for it, but most times I find sn850x drives significantly cheaper and insignificantly slower. Otherwise, the only other note I’d make is that grub is abysmally slow at higher resolutions on chips with no igpu, at least when using a nvidia gpu. I’m not certain if this would apply to an AMD gpu, and either way you can just use something better (cough cough refind) to avoid the problem, but for anyone who just wants the default out-of-the-box bootloader on most distros to just work properly it might be worth spending the extra ~$40 for the K series instead of the KF to get the igpu. It’s not something I’d recommend doing personally, but it’s at least worthwhile to know about when you’re making the K/KF choice imo. Anyway, good luck with your build and have fun with setting everything up!

I remember being able to figure out a solution with the kwin docs and dfeet for introspection, but it was a while ago and my memory is less than stellar lol. I ended up running all my window-related logic in the kwin script (js) and just using python+dbus to see if the script had been injected and do it if not. If you go the same route (though the python is unnecessary this way if you aren’t using it for something else, like running one of the windows you wanna manipulate) the workspace global variable stores all windows in stackingOrder, so looping through that list (for (window of workspace.stackingOrder) {…}) is an easy way to check each window. I definitely remember docs on the workspace/windows part, but tbh I think I just introspected with the jsconsole.log and the log kwin prints it to (journalctl maybe?). Sorry I don’t remember more about the process, I got into the kwin scripting for all of an hour cuz of the Wayland regression of not being able to control your own window’s size/position in qt so it was a bit of a hack fix I haven’t had to think about since.

I’ve had good luck interfacing with KDE windows using dbus in python, although if I remember right the more granular control also required javascript (still passed thru dbus with python). The only python library I needed was Qt (for their dbus implementation because I was already using their event loop, but any other lightweight dbus package should work fine).

I did a search for nvidia on my system and got these, which OP might wanna check for too:

egl-wayland
lib32-nvidia-utils
libvdpau
libxnvctrl
nvidia-open
nvidia-settings
nvidia-utils
opencl-nvidia 

I’ve installed extra packages for proton and machine learning, so some of these may not be there, but hopefully that helps.

Well your /efi entry looks right to me - maybe try mount -a (maybe capital A, going off memory here but whichever option is all) and watch for error messages or check dmesg?

sdb looks like the bootable USB to me - /dev/sda1 should be the system’s EFI, no? OP, could you try mounting that one (shouldn’t be encrypted afaik) and/or post the output of cat /etc/fstab? Edit: just realized you were unable to mount the encrypted drive in the first place so /etc is inaccessible, sorry