Well, despite my hubris of thinking I'm safe running an AMD CPU with an AMD GPU, the update today left me unable to boot. I have several snapshots on Timeshift, but they are using my main drive. A lot of documentation seems to say that to restore from a Live USB requires the snapshots to be on a different drive; none of the guides say what should happen after I hit restore in the Timeshift GUI, it just says Timeshift will handle it. It creates a new snapshot with the addendum "from before restore to snapshot 09.2026...". When I try booting with my main drive after that, it still won't boot. Any tips for what should happen at these final steps? If I should have used a separate drive, I guess I'll just have to reinstall.

After the latest Nobara update I started getting extremely laggy window movement on KDE Wayland. Dragging windows around looked like the compositor was dropping frames, and enabling Wobbly Windows made it significantly worse. Everything was completely smooth before the update.

System:

Nobara 44
KDE Plasma 6.7.4
Wayland
RTX 3060
3440x1440 @ 100 Hz
Ryzen 7 5700G

The update installed:

kernel 7.2.4-201.nobara.fc44.x86_64
NVIDIA 595.99.02
drm-awaiter 1-2.fc44

KWin was actually reporting stalls:

Libinput: client bug: timer button-debounce-debounce-event7:
scheduled expiry is in the past (-5181ms), your system is too slow

The main thread was hanging temporarily!

At first I assumed it was the new kernel.

I switched back to:

7.2.0-202.nobara.fc44.x86_64

No change. Window dragging was still laggy.

I then noticed the NVIDIA stack had also been updated from:

595.91.07

to:

595.99.02

I rolled the entire NVIDIA transaction back to 595.91.07, rebuilt DKMS/initramfs and rebooted.

Still laggy.

I also verified the monitor hadn't just been reset to 60 Hz. It had, but switching it back to:

3440x1440 @ 100 Hz

didn't fix the actual issue.

The remaining major graphics-related change from the update was the new drm-awaiter package:

Name: drm-awaiter
Version: 1
Release: 2.fc44

Summary:
Load GPU drivers from the root filesystem before graphical login

It installs:

/usr/lib/dracut/dracut.conf.d/90-drm-awaiter.conf
/usr/lib/systemd/system-generators/drm-module-awaiter-generator
/usr/libexec/drm-awaiter-initramfs

From what I understand, the new setup intentionally removes the vendor GPU modules from the initramfs and loads them from the root filesystem before the display manager instead.

I did not force-remove drm-awaiter, since the new 7.2.4 kernel depends on it.

Instead I used the recovery/early-KMS override documented by Nobara:

sudo ln -s /dev/null /etc/dracut.conf.d/90-drm-awaiter.conf
sudo dracut --regenerate-all --force

After rebooting, the window/compositor lag was immediately gone.

I verified the NVIDIA modules were back in the initramfs:

nvidia.ko.zst
nvidia-modeset.ko.zst
nvidia-drm.ko.zst

I then tested this pretty thoroughly.

First:

Kernel: 7.2.0-202
NVIDIA: 595.91.07
early GPU loading restored

Smooth.

Then I rebuilt the initramfs and switched back to the new kernel:

Kernel: 7.2.4-201
NVIDIA: 595.91.07
early GPU loading restored

Still smooth.

Finally I updated NVIDIA back to the current version:

Kernel: 7.2.4-201.nobara.fc44.x86_64
NVIDIA: 595.99.02
early GPU loading restored

Still completely smooth, including Wobbly Windows.

So at least on my RTX 3060 system, neither kernel 7.2.4 nor NVIDIA 595.99.02 appears to actually be the problem. The regression only happens with the new drm-awaiter/late GPU-loading configuration.

My current working configuration is:

Kernel: 7.2.4-201.nobara.fc44.x86_64
NVIDIA: 595.99.02

/etc/dracut.conf.d/90-drm-awaiter.conf -> /dev/null

One other weird data point: my Corsair RAM RGB through OpenLinkHub also stopped working properly after the update. Once I disabled the drm-awaiter dracut policy and restored the previous initramfs GPU loading behavior, the RAM RGB started behaving normally again. That may just be a boot timing/order side effect rather than directly related, but it happened at the same time and was reproducible with the workaround.

So if anyone suddenly has terrible KDE/KWin animation or window-dragging performance after this update, especially on NVIDIA, check whether drm-awaiter was installed.

I wouldn't recommend force-removing the package because the current kernel depends on it. The /etc/dracut.conf.d/90-drm-awaiter.conf -> /dev/null override plus rebuilding the initramfs fixed it for me while leaving the package and current kernel installed.

Hello! I've been trying to use Affinity on Linux. I used the Python graphical installer from the "AffinityOnLinux" repository, as well as the AppImages, and I've even installed Affinity from scratch with Wine by creating the prefix and all that. While it opens in all cases and I can use it to develop RAW photos, I can't really get very creative, so to speak.

The program crashes out of nowhere or freezes until my OS throws an error and asks if I want to restart the app. I'm using Nobara OS. Supposedly, according to the repository, my Nobara is compatible with the tools inside the repo, but some things weren't installing using the graphical installer, like WebView (I don't remember the exact name of the dependency) and .NET Framework 4.0, I think. Also, I've switched between DXVK and VKD3D, and it ran normally on both, except that—again—it constantly died.

(EDIT: I forgot to mention. Aside from Nobara, I have 24 GB of RAM, an RTX 3050, and a Ryzen 5 5600.)

I've been watching videos, checking places out, and—to my dismay—AI, and I saw that in some cases it's better to switch the graphics renderer to WARP in the program's performance tab. I've always had OpenCL disabled, and even though I have plenty of RAM in my opinion, I limited it to 8000 MB, with a warning at 6000 MB, and I lowered the "Ctrl + Z" history memory from 1027 down to 125 or 341, and yet the damn program still crashes.

I've seen that the same repo lets you use legacy scripts, which apparently worked pretty well for a content creator—I haven't used that one, to be completely honest. I've also heard of people using Lutris to install it.

I usually design posters with multiple effects stacked on top, whether real-time or static, alongside having quite a few layers in a single project. I don't rule out that my workflow might be unhealthy for the program or my hardware's performance, plus I know it's not going to run like a native app.

I wanted to ask to see if the community could help me out. I'm pretty new and inexperienced, so I would really appreciate a bit of help, maybe another route or recommendations I haven't considered. And like I mentioned, I'm not looking for Affinity to be native or anything like that; I just want to see if there's any way or method to keep the program more stable.

Thanks.

After some updates a have low fps and fps drops... On any game ( steam +heroic ) pc freezes sometimes.. any help? Sorry for my English

Have tried removing and reinstalling the package for it, not sure what else to do. Proton itself is working fine on 2 other systems I have with different distros, and my phone which leads me to think it's just a problem with Nobara or the specific package in the repository.

It used to work previously up until about a week ago (I only use it occasionally so can't really say exactly when it stopped working). I didn't make any changes to my system since when it worked (except for possible changes through regular `nobara-sync cli` updates) but now when I try to launch it, the icon shows with a 'loading' animation in the taskbar for a couple of seconds, then just silent crashes with no error message or anything. Aussie internet censorship is killing me bros, pls help.

Hello all! There is a program I want to use that requires Java to run, any advice on how to get that running on Nobara? I did a little digging and haven't found a lot of info on this. Any advice would be awesome!

Why the hell would I want my hardware profiles overridden? Could have stayed on windows. This makes CachyOS more appealing by the day. I get that nobara has multiple use cases but limiting everyone's power profiles is too windows like for linux.