Ralphred

Read the install guide before you start, and have it open on another device when installing. When doing kernel configuration make liberal use of 'lscpi -nnk' and 'lsmod', you can use / in menuconfig to search for module names and make sure they are enabled. Remember you are essentially building an OS from the ground up, whilst there is a temptation to install a desktop meta package and let portage (the package manager) handle the rest, do your best to make sure everything underneath is installed, configured correctly and working first. OpenRC is a lot easier to use than systemd, especially for a first time install, you can always switch later.

Yeah, EFI bootloaders can be bigger than the traditionally allocated space, most people make an unused 1-2Mb partition at the start of the disk so as not to overwrite the bootloader.

Post the output of cat /proc/mounts and cat /etc/fstab please.

This is interesting, there is a bunch of stuff for "Soundblaster Recon 3Di" in the kernel source (sound/hda/patch_ca0132.c), but it's tied to SND_PCI_QUIRK(0x1458, 0xA016, "Recon3Di", QUIRK_R3DI), ...snip... SND_PCI_QUIRK(0x3842, 0x1038, "EVGA X99 Classified", QUIRK_R3DI), which is the equivalent of VEN_1458 and VEN_3842 (Gigabyte and EVGA respectively). MSI is 1462 if it's looking for a motherboard... Lets check the firmware files "ctefx[-something].bin" are being loaded (or even asked for) first: Please post the output of dmesg|grep -i "firm\|ctfx" Also the output of lspci -nnk

Gentoo Rolling Release Meta OS Specs: CPU: AMD 5600X GPU: Vega64 RAM: 16 GBs DDR4 @3000MHz Motheboard: Asus b350 Monitors: 2x 1080p@75Hz DE: KDE &| DWM Pros: Does exactly what you tell it, no more, no less. Easy to mix stable, testing and untested git packages. Easy to add/customise your own packages. Cons: Does exactly what you tell it, no more, no less. Steep learning curve for the uninitiated. Quirks: Everything* compiled from source (*some larger packages have binary options) Other comments: Not really an OS, more an "OS building toolkit". My desktop OS will be 20 years old next year, distro hopping isn't a viable thing when you have more than 10 years worth of tweaks hacks and customisation, it's just a chore.

Well, yes. I'm not a huge Mate expert but I know it's written using GTK, meaning to say GUI API used is GTK(3/4?). QT is "the other popular" GUI API, so a re-write of all the seen interface parts, and backend parts that need gconf etc to their QT counterparts. IMHO it would be easier to start with LXQT and add functionality to match Mate.

Yeah, you can fix that with hdajackretask. I remember the instructions for "permanent fix" not working though and ended up writing a script that has to be started before alsasound. Audacity is a fly in the ointment a lot of the time because it can/will ignore layers on top of ALSA it shouldn't be, I think I got the hump with it in the end and built it without alsa support. As far as outputs only (games firefox etc) go, if you can set your default alsa PCM to loop into pipewire that should fix most things. pcm.!default { type pulse } ctl.!default { type pulse } in ~/.asoundrc should do it. That sounds like something is messing with the levels, I know pulse does when it starts up, so maybe pipewire does too, and is set to shut down on inactivity, hence it happens over and over again?

Mangohud can be used to limit FPS too. "Why would I do that" you might ask, well slightly lower FPS is better than frametime spikes, and some games limit your choice of "FPS limit" to fractions of your vsync freq. EDIT: If you set a config file for mangohud, and edit said file whilst it's "live" it updates too, a bit like conky does, useful for diagnostics.

Post the outputs of cat /etc/fstab grep "^/" /proc/mounts uname -a and tell us the path to the games please...

Welcome to the "easier to install, harder to keep tweaked" curve. Might be time to bite the bullet and check out some upstream distros, put in the work at install time and have easier updates.

Yes, it is, all AM4's are apart from the old Zen+'s, a 3600 is Zen2.

Yes, use the code I've given you to programmatically modify your config file before starting fancontrol, or as I said statically compile the affected modules into your kernel. If you go the way of trying to direct udev, make notes 'cos you'll need them in 12 months when it stops working due to new "features", or a new mouse/headphones. The fact fancontrol is called with the config file in the command line means you could even go stupidly hacky future-proof by just making hwmon[n+10] config files and symlinking the correct one with a dependency service, no config template needed, no awk/sed needed, just ln and some bash substitution. Shit, fancontrol is written in bash, update it to theocontrol so it just autodetects the right hardware.

Use protontricks and make sure the prefix is set to use pulse as it's sound backend.

Rebuild the kernel with the "modules" in use for the hardware showing up in /sys/class/hwmon as "built in", or scrape /sys/class/hwmon/hwmon*/name in a wrapper script around effected programs and update the config/commands accordingly. Here is a nasty little hack I wrote in python to find my AMD card in hwmon (because module unloading for GPU passthrough) def findPath(self): for base,dirs,files in os.walk('/sys/class/hwmon/'): for dir in dirs: namefile=open('%s%s/name'%(base,dir)) name=namefile.readline().strip() namefile.close() if name=="amdgpu": return '%s%s/'%(base,dir) exit In fact, it's so small I can probably replicate it in bash... for dir in /sys/class/hwmon/hwmon*;do grep -q "amdgpu" $dir/name && echo $dir;done Yeah, that works...

Is the only thing that sticks out, but you aid it works over net.lo so... Bridging should have no cost, have you changed the ethernet cable*, run a graphical ping, checked the disk/network logs? *cable faults aren't binary like people think, cables exist on a spectrum from "always works" to "only useful as a animal leash"

Is the only one ringing bells in my head.

Everyone is a target for 0 day attacks my botnet owning friend. When I was doing government work back in the day the IME code was on a daughter board with the onboard NIC chips, we used to bin it and install a "safe" NIC. I used to cut the release tab off of blank crimped RJ45 plugs and stick them into the redundant ports to avoid mistakes.

Driver is too old, try for 23.1.x . I don't know how much of a PITA it is to use "a few bleeding edge" packages in debian**, might be easier to just build from the git repo. The AV1 PR is here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22585, should give you a starting point if you have to go that way. **Or just wait a while until it hits main.

Don't mess about with the amdgpu-pro stuff, AV1 encode was merged to mesa about 4 months ago (into 23.3), all you should need is the default kernel driver, libva and a new enough mesa (plus dependencies like LLVM etc). `vdpauinfo` and `vainfo` are your friends, and people forget that it's AMD's own engineers that write the kernel and mesa code.

Your BIOS will have the ability to set a custom curve for the CPU. GPU fan control is (should) be available via /sys/class/hwmon. Each hwmon[n] directory within there provides info and/or control for a specific piece of hardware. Running `cat /sys/class/hwmon/*/name` should give an idea of what each device is.

The general idea would be to have two iptables save files, one for when the vpn is down and you want "management" access, and one for for when it is up and working. Switching between configs could be done with ifup/down type scripts (if supported), hooks from the vpn package (if supported), or your own watchdog daemon looking for the interface to be up (simple bash script can do this). You need to take into account what the vpn does to iptables (if anything), and make sure not to close the ports that the vpn uses, and allow outgoing/related traffic for stuff the OS needs, other than that it's pretty straight forward, to the point it may be simpler to have both management and vpn tables loaded, and just set the jump in the default tables to the correct one.

This is unnecessary, everything you need should be included out of the box*. AMD (the company) work with both the kernel and mesa teams (drivers and 3d acceleration respectively) to make it this way. *Some mint officiando wanna weigh in on if they ship DCN:2 firmware by default? I can't think of a reason not too, but assumption is the father of bad advice...

Reading from the top it smells like and environment problem: Something in your ~/.bashrc or ~/.bash_profile is exporting an environment variable not set by KDE on login. Reading further it sounds like that missing envvar was a dev oversight that was fixed with a later package update.

If you put the mount definition in fstab with `noauto` in the options field, that will allow the mountpoint owner/group to mount and unmount without having to raise permission. If you end up with stale mount points and file handles this can cause issues, considering the simplest solution would be to wrap the other program with a mount/dismount. If this program is supposed to be running all the time, then it becomes a little more complicated. The most robust solution would be to watch the ip/port of the device for a the cifs mount to be available, mount it, rsync all the data to a local location, dismount again, then have the "imported with another program" program point to the local location, that way you don't have "users" interacting with a potentially fragile mount point.

Debian is actually a really good idea, you can cut out the cruft by just not installing it, and only install the tools for power management you want. I use an x220 Thinkpad and get about 7-8 hours out of it, I can't see it getting that battery life with useless nonsense running in the background. I have it do that hibernate/sleep thing too, so it copies the running ram to disk on sleep, then if I don't wake it up within a certain time it just shuts down into "hibernate" mode - means I can just close the lid on a Friday, and on Monday morning it still has battery life.