I've been using Linux for about a year, currently running CachyOS with Hyprland and a heavily customized set of configuration files. I enjoy the flexibility, but lately almost every system update seems to introduce a new problem. I've had NVIDIA and VRAM-related issues affecting games and Blender, dependency updates have caused application problems, and one update completely broke my desktop environment. Fortunately, I use snapshots and can roll back, but the recurring maintenance is becoming exhausting.
My system has an RTX 3080 alongside integrated AMD graphics, uses Wayland with Hyprland, and includes several customizations and per-application environment settings. I'm wondering whether these problems are mainly caused by using a fast-moving Arch-based distribution, the NVIDIA and Wayland combination, my customized desktop configuration, or some combination of all three.
I'm not necessarily looking for a specific fix. I'd mainly like to understand whether this is normal for a setup like mine and how experienced users keep track of customizations, package changes, environment variables, driver versions, and update-related regressions. What tools or habits help you identify exactly what changed when an update causes something to fail?
4 Answers
This is less a general Linux problem and more the result of stacking several fast-moving components: a rolling-release base, a performance-focused derivative, a Wayland compositor, third-party configuration files, NVIDIA’s proprietary driver, and a fairly new kernel. Each layer can work well on its own, but together there are many more ways for an update to expose a compatibility issue.
Snapshots are useful, but they should be a safety net rather than the entire update strategy. Read update announcements, keep older kernels and known-good driver versions available, and update before you need the machine for important work so you have time to roll back or investigate.
Arch-based systems do have package testing, but rolling releases still prioritize getting current software out quickly rather than guaranteeing that every combination of hardware, compositor, driver, and third-party customization will keep working. The more customized the desktop, the more maintenance becomes part of the deal. There’s nothing inherently wrong with your setup; it’s just closer to an enthusiast workstation than a set-it-and-forget-it desktop.
For diagnosing regressions, check the package manager history and compare the list of recently upgraded packages with the time the problem started. Update major components separately when practical, especially the kernel, NVIDIA driver, compositor, and graphics libraries. Keep application-specific environment variables in clearly named files rather than scattered across shell startup scripts, and preserve a known-good configuration in version control.
Also remember that NVIDIA plus Wayland and a hybrid AMD/NVIDIA setup can be more sensitive than a simple single-GPU configuration. If games or Blender are the priority, testing with a stable kernel and driver combination may be more valuable than always using the newest packages.
For a rolling system, update habits matter a lot. Don’t update blindly right before shutting down, and avoid letting the machine go months without updates because large jumps can create their own dependency problems. Keep a bootable fallback kernel, save package lists, and record manually installed packages and configuration changes. If possible, test updates on a spare installation or wait briefly when a major kernel, graphics stack, or desktop release lands.
I’ve started updating at startup instead of before bed so I can deal with problems immediately. I also need to get more organized about recording package and configuration changes.
That makes sense. I’m comfortable with tinkering, but I probably underestimated how many moving parts I had combined. I’m mostly looking for a better way to identify which layer changed instead of guessing.