In the updates i receive
sddm 0.21.0-8 -5,35 MiB
sddm-kcm 6.6.0-1.1 -0,61 MiB
But i changed it from ssdm to plasma login manager, so i delete it after the update, i hope it will start as before, i will report.
Yes it works - i don´t know if is a problem wenn the packages are installed if i use the plasma login manager, but if i saw that many users have problems after reboot maybe it is helpful. If not delete my Post.
Before someone does this, please understand the implications.
This breaks virtualization passthrough and also lowers some security mechanisms of the kernel, by allowing certain hardware to access the memory directly.
CachyOS provides an LTS kernel (recently bumped up to 6.18). I suggest using that instead until this is fixed.
Kernel 6.19 hasn’t even reached the Arch testing team (I am in it), because it has boot failure issues.
Oh please let me know of anything that might help, because I am in a pretty awkward situation since almost a week now.
Update: my problem was self-made, I didn’t actually have a problem with the kernel.
This should work or disabling IOMMU in BIOS will also work.
Another thing I would suggest is too see jf there are any bios update available for your boards. There have been a good amount of AGESA updates lately in the last few months.
the security implications note is kinda legit I guess but it’s more of an enterprise/hypervisor issue or corporate computing problem. Home users don’t tend to run sketchy external docks for instance that’s trying to read your memory and most people here aren’t doing passthrough VMs (or running multiple at a time where the protection really works). Not like your leaving fucking port 22 open to the world or RDP.
Kernel 6.19 hasn’t even reached the Arch testing team (I am in it), because it has boot failure issues.
I’m curious about this statement. Is this implying that this kernel is not established as a stable kernel in Arch’s repos? If that’s the case and this kernel has yet to be approved by Arch’s testing team then why are we using it in cachyos as a stable kernel? Arch is already bleeding edge so are we trying to be just the blood in the edge or am I missing something?
Considering we are a smaller community with I believe smaller user and dev pool than vanilla Arch, and that cachy (at least on paper) tries to be a more newbie-friendly approach to Arch is this the smartest thing to do?
So, same issue. I was walking through troubleshooting steps and came across the same advice of disabling iommu. But as soon as I added splash back to grub options, boot failed again. Turns out, it was taking too long for amdgpu to load. I added amdgpu to my mkinitcpio modules, and the issue was resolved entirely. System booted with no need for additional grub entries. Hope this helps
System:
Ryzen 9 3700X
RX 5700XT
Asus Prime X570 Pro
All fixes were completed after upgrading to latest BIOS
I had the same issue and just managed to update everything today and successfully boot. I don’t know if the source of my issue is the same as yours but I’m leaving this here just in case.
On my machine, I had a config file - /etc/default/limine - that was pushing the wrong value for the resume=UUID in the cmdline. So the system was not able to retrive the disk. I recently got a new computer and I’m still setting up everything, that’s why I ended up with this, I think.