So you have proven it perfectly. Verified!
Unstable is no option, systemd is the same version as testing at this time.
And: I run a different system, kernel 510 and 512 at unstable - everything fine…
Can be magic.
So you have proven it perfectly. Verified!
Just FYI for the future: instead of switching branches and everything, you can use downgrade for things like that
Some more details related to the unbootable 4.19 kernel with systemd 248.y :
By analysing the journalctl I got an half dozen of this entries:
systemd-udevd.service : failed to set up mount namespacing: /run/systemd/unit-root/proc/sys/kernel/domainname: Device or resource busy systemd-udevd.service : failed to step NAMESPACE spawning /usr/lib/systemd/systemd-udevd: Device or resource busy systemd-udevd.service : Main process exited, code=exited, status=226/NAMESPACE systemd-udevd.service : Failed with result 'exit-code' Failed to start Rule-Based Manager for Device Events and Files.
Afterwards only a keyboard reboot request is the only option.
Changed to experience problem as Saints Row 4 crashes, probably due mesa .
I doubted everything from corrupted shader cache to cpu overclock
Idem on my journalctl that I shared on previous update thread: dozen of those entries.
I knew it, but for some minutes I wanted to switch to stable ,also to see which packages deffered. And seeing systemd to a prevoious version and seen my wife’s pc booted with 4.19 after last updated, I supposed that had to be systemd. Downgraded and so on…
Trackpad do not work anymore in my Laptop Dell. Just an Intel with integrated graphics, nothing fancy.
This happened with this machine in kernel 4x versions, then after going to versions 5 it never happened again, in fact the kernels were not changed version, 510 and 512 are what I was using, all good until after the update.
As it uses the integrated graphics of Intel the session is Wayland, I tried with X but there was no change either.
Tell me what log or data you need to see if someone can help me. Thanks in advance.
Yes, I kwen it, too. I meant…to see which installed packages differed. It would not been simple check packages one by one…
After those not very important things, someone has an idea about how to solve the 4.19 issue with systemd 248.x?
Thank you all!
Head over to systemd’s GitHub page and try to find a bug you described. If no any, file a new one.
In unstable repo there is a newer version of kernel419…
Latest kernel 5.13. I am getting random lockups ever since upgrading the kernel. The only thing different that I have done on this kernel is install Dogecoin Core Wallet. It takes a huge amount of time to update the blockchain, and I suspect it is locking up because of the Dogecoin software, however I just downgraded kernel to 5.12 and the lockups went away. Prior to this downgrade, system would lock up even if Dogecoin wasn’t running, but as soon as I ran Dogecoin, the system would lock up for sure. Now that I’m back to 5.12 the system runs fine. Just wanted to make devs aware, my system has ran flawlessly to this point, so there seems to perhaps be an issue with the kernel 5.13. Perhaps Doge related, perhaps not. The lockups didn’t start happening until Doge had been updating for a full day and had roughly 6 hours left to finish updating the blockchain. But like I said, I was getting lockups on 5.13 kernel before I would even have a chance to launch Doge sometimes.
That is a kernel still in its development phase. It has only reached
testing only has an even older
rc2 available) and will proably released (go
Understood, just listing the issue to make folks aware. I am sitting at 5.12 for now until a more stable release.
4 posts were split to a new topic: GeForce GT710 driver issues
Well… this looks like a bug in x.org and the intel driver when using SNA… changing over to UXA for X11 fixes it, i.e. adding the following into /etc/X11/xorg.conf.d/20-intel.conf
Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" EndSection
fixes it. Linux 5.11 is fine with SNA (the default) but 5.12 crashes X unless using UXA.
Maybe I should try this solution too for the issue I reported before. Will get back as soon as I know.
EDIT: It worked, it worked!
Thank you @chadders
So far, it is running here without problems. Nothing extraordinary in the logs.
I was even able to get the nvidia driver 390.143 running on this kernel.
Let’s keep fingers crossed that it remains this way
Sorry for the unrelated question, but did this update not become stable enough to reach stable channel?
When we push a new testing update then the current gets obsolete. A new testing cycle has started today.