No graphical session after update to 41.20241117.3 on Aurora. #1963
Comments
mejiasjrg
changed the title
|
These are all the commits that affected that image from 12/nov to 17/nov. Apparently it is f41 update that broke your system, as you are on the first build of day 12/nov (before the f41-in-stable commit).
|
|
Some hardware information could be useful, please run a |
Here you are: It might be worth mentioning that I'm also running Bluefin-gts and Vauxite:latest in this same machine flawlessly. As they are both based on ostree images, this issue seems to be limited to bootc images. |
|
Use |
Correct. I just want it to boot to the working image while a solution is found. |
|
What GPU do you have. By any chance an old intel haswell iGPU (4th Gen, from 2014?) |
I rebased to from Only a reinstall to aurora (ISO from august I had laying around) would "fix" it. I "fixed" it by rebasing to |
I don't have access to the machine at the moment, and I don't remember what iGPU it has. But it is a 12 year-old machine. |
As per Jorge Castro's suggestion, I rebased to 41.20241112.1 using the ujust rebase-helper, and it is working fine. |
Here is the device-info, as TXT this time, so it doesn't go anywhere. Aurora@Lenovo_B470e-2024-11-25.txt Edit: what neofetch shows... |
I wonder if the behavior would change if you chuck in a different GPU and use that and see if that works. See if some new QT component/Plasma is acting weirdly with the GPU/driver as I don't have this issue on my other modern machines. Would be a lot easier if the atomic stuff had proper live ISOs for testing. Have you looked at the memory usage? There might be a memory leak somewhere. Go to another tty and do startplasma-wayland, plasmashell should crash/no wallpaper, panel etc. if we're having the same issue. Look at the memory usage with htop at the same time. |
As this is a laptop, I don't think that is possible.
Not really, but I think the memory usage is about the same. I'm afraid I don´t know how to detect a memory leak.
I did that, but it just reloaded plasma. I mean, it showed the splash screen and then the desktop with all the apps open (Firefox, Terminal & Dolphin). Memory usage kept about the same: 1.39 GB before, 1.41 GB after. (Remember I'm running the 41.20241112.1 image, and as it is pinned, the 41.20241117.3 image is not available). |
|
I was describing the behavior of the apparently broken images newer than 41-20241117. In my case the memory (and swap) usage was rapidly growing and was nowhere near reasonable and everything slowed down to a halt and/or my kernel probably panicked and I had to hard shutdown afterwards. |
|
Check the kernel and mesa versions for each image, maybe it was a change in there, seems like a good place to start. |
Will do a little testing in the coming weeks kinoite/aurora41: 11th Nov kinoite/aurora41: 12th Nov 6.11.6 and 6.11.7??? aurora40: from Oct 28 ✅ kinoite40: 25th Nov old mesa, new kernel |
I thought of rebasing to specific daily images until I found the last working image and the first non-working one, and then find the differences and, hopefully, pin down the culprit. But I just ran |
|
|
This issue is happening to me as well on both the aurora-nvidia and kinoite-nvidia images. My GPU is a Gtx 750 ti. |
|
On a GTX 750ti, the Nvidia images uses a driver that does not support your card |
Huh? As of the latest beta driver (565) the GTX 750ti is still listed as supported on Nvidia's website. Also, the driver was working just fine before the update a week ago or so. |
|
You're right. I thought it stopped providing support to 9XX, 8XX and 7XX.
…On Fri, Nov 29, 2024, 8:13 AM DeeBeeDouble ***@***.***> wrote:
On a GTX 750ti, the Nvidia images uses a driver that does not support your
card
Huh? As of the latest beta driver (565) the GTX 750ti is still listed as
supported on Nvidia's website. Also, the driver was working just fine
before the update a week ago or so.
—
Reply to this email directly, view it on GitHub
<#1963 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQPNFFNM5EHB5ZUDGLYDFRL2DBR7HAVCNFSM6AAAAABSKQRGASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBXG44TOMJZGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Describe the bug
The system updated from 41.20241112.1 to 41.20241117.3 and on the next boot it showed the arrow cursor for a little while and then a blank screen. It didn't even show the login screen. I changed to a terminal with Ctrl-Alt-F2 and could login with no issues. Tried sudo systemctl restart sddm, and got the blank screen again.
Rebooted the machine and selected the second entry in the grub menu, and the system booted normally to the graphical session. Then I issued rpm-ostree rollback, reboted, and issued systemctl start rpm-ostreed-automatic.service to make the system update again, hoping there might be a new (different) update, but instead updated to 41.20241117.3 again, and again got the blank screen.
I finally did the rollback again and am posting from the system running 41.20241112.1
What did you expect to happen?
I expected the system to boot normally running 41.20241117.3
Output of
bootc statusCurrent staged image: ghcr.io/ublue-os/aurora:stable Image version: 41.20241117.3 (2024-11-17 15:47:30 UTC) Image digest: sha256:fb3a023ce3c7609591c7524cb0c5a679453e5e0ff62cef6f334b4d7ca165965b Current booted image: ghcr.io/ublue-os/aurora:stable Image version: 41.20241112.1 (2024-11-12 21:06:27 UTC) Image digest: sha256:f99e7cf789398600ffe7d1ade44ca0bceb31d76cbe8b8eb140a8b284804d6f6c Current rollback image: ghcr.io/ublue-os/aurora:stable Image version: 41.20241117.3 (2024-11-17 15:47:30 UTC) Image digest: sha256:fb3a023ce3c7609591c7524cb0c5a679453e5e0ff62cef6f334b4d7ca165965bOutput of
groupsExtra information or context
For the average user Aurora is intended to, this would have been a show-stopper. Not good.
The text was updated successfully, but these errors were encountered: