Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No graphical session after update to 41.20241117.3 on Aurora. #1963

Open
mejiasjrg opened this issue Nov 23, 2024 · 15 comments
Open

No graphical session after update to 41.20241117.3 on Aurora. #1963

mejiasjrg opened this issue Nov 23, 2024 · 15 comments
Labels
aurora KDE forever! bug Something isn't working

Comments

@mejiasjrg
Copy link

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 status

Current 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:fb3a023ce3c7609591c7524cb0c5a679453e5e0ff62cef6f334b4d7ca165965b

Output of groups

jm wheel

Extra information or context

For the average user Aurora is intended to, this would have been a show-stopper. Not good.

@mejiasjrg mejiasjrg changed the title No graphical session after update to 41.20241117.3 No graphical session after update to 41.20241117.3 on Aurora. Nov 23, 2024
@dosubot dosubot bot added aurora KDE forever! bug Something isn't working labels Nov 23, 2024
@tulilirockz
Copy link
Collaborator

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).

Image

@castrojo
Copy link
Member

Some hardware information could be useful, please run a ujust device-info and paste the URL it returns, thanks!

@mejiasjrg
Copy link
Author

Some hardware information could be useful, please run a ujust device-info and paste the URL it returns, thanks!

Here you are:
https://paste.centos.org/view/9776d16c

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.
By the way, how do I prevent the system from staging the 41.20241117.3 image? It did last night, and I just checked and the image is staged again.
Thank you!

@castrojo
Copy link
Member

Use ujust rebase-helper to pin to the image you want, I don't think you want to turn off updates though.

@mejiasjrg
Copy link
Author

Use ujust rebase-helper to pin to the image you want, I don't think you want to turn off updates though.

Correct. I just want it to boot to the working image while a solution is found.
Thank you!

@Renner0E
Copy link

What GPU do you have. By any chance an old intel haswell iGPU (4th Gen, from 2014?)
The pastebin is expired

@Renner0E
Copy link

Renner0E commented Nov 25, 2024

Use ujust rebase-helper to pin to the image you want, I don't think you want to turn off updates though.

Correct. I just want it to boot to the working image while a solution is found. Thank you!

I rebased to from aurora:latest to aurora:40 but that did not fix anything.
Rollbacks did not work at all.

Only a reinstall to aurora (ISO from august I had laying around) would "fix" it.
Updating to F41 made the issue appear again.
But this time the rollback actually reverted me back to a working system.

I "fixed" it by rebasing to aurora:40 after a reinstall.

@mejiasjrg
Copy link
Author

What GPU do you have. By any chance an old intel haswell iGPU (4th Gen, from 2014?) The pastebin is expired

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.
In about 4 hours I will be able to paste the machine info again.

@mejiasjrg
Copy link
Author

Use ujust rebase-helper to pin to the image you want, I don't think you want to turn off updates though.

Correct. I just want it to boot to the working image while a solution is found. Thank you!

I rebased to from aurora:latest to aurora:40 but that did not fix anything. Rollbacks did not work at all.

Only a reinstall to aurora (ISO from august I had laying around) would "fix" it. Updating to F41 made the issue appear again. But this time the rollback actually reverted me back to a working system.

I "fixed" it by rebasing to aurora:40 after a reinstall.

As per Jorge Castro's suggestion, I rebased to 41.20241112.1 using the ujust rebase-helper, and it is working fine.

@mejiasjrg
Copy link
Author

mejiasjrg commented Nov 25, 2024

What GPU do you have. By any chance an old intel haswell iGPU (4th Gen, from 2014?) The pastebin is expired

Here is the device-info, as TXT this time, so it doesn't go anywhere.
It says the PCI Video Card is: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller

Aurora@Lenovo_B470e-2024-11-25.txt

Edit: what neofetch shows...
Image

@Renner0E
Copy link

Renner0E commented Nov 26, 2024

Intel 2nd Gen Sandy Bridge 2012

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.

@mejiasjrg
Copy link
Author

I wonder if the behavior would change if you chuck in a different GPU and use that and see if that works

As this is a laptop, I don't think that is possible.

Have you looked at the memory usage? There might be a memory leak somewhere.

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.

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.

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).

@Renner0E
Copy link

Renner0E commented Nov 26, 2024

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.

@castrojo
Copy link
Member

Check the kernel and mesa versions for each image, maybe it was a change in there, seems like a good place to start.

@Renner0E
Copy link

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

mesa-libGLU-9.0.3-5.fc41.x86_64
kernel-tools-libs-6.11.6-300.fc41.x86_64
kernel-modules-core-6.11.6-300.fc41.x86_64
kernel-core-6.11.6-300.fc41.x86_64
kernel-modules-6.11.6-300.fc41.x86_64
kernel-6.11.6-300.fc41.x86_64
kernel-tools-6.11.6-300.fc41.x86_64
kernel-modules-extra-6.11.6-300.fc41.x86_64
mesa-filesystem-24.2.4-1.fc41.x86_64
mesa-libgbm-24.2.4-1.fc41.x86_64
mesa-libglapi-24.2.4-1.fc41.x86_64
mesa-dri-drivers-24.2.4-1.fc41.x86_64
mesa-libEGL-24.2.4-1.fc41.x86_64
mesa-libGL-24.2.4-1.fc41.x86_64
mesa-va-drivers-24.2.4-1.fc41.x86_64
mesa-vulkan-drivers-24.2.4-1.fc41.x86_64
mesa-libxatracker-24.2.4-1.fc41.x86_64

kinoite/aurora41: 12th Nov 6.11.6 and 6.11.7???

mesa-libGLU-9.0.3-5.fc41.x86_64
kernel-tools-libs-6.11.7-300.fc41.x86_64
kernel-tools-6.11.7-300.fc41.x86_64
kernel-modules-core-6.11.6-300.fc41.x86_64
kernel-core-6.11.6-300.fc41.x86_64
kernel-modules-6.11.6-300.fc41.x86_64
kernel-6.11.6-300.fc41.x86_64
kernel-modules-extra-6.11.6-300.fc41.x86_64
mesa-filesystem-24.2.4-1.fc41.x86_64
mesa-libgbm-24.2.4-1.fc41.x86_64
mesa-libglapi-24.2.4-1.fc41.x86_64
mesa-dri-drivers-24.2.4-1.fc41.x86_64
mesa-libEGL-24.2.4-1.fc41.x86_64
mesa-libGL-24.2.4-1.fc41.x86_64
mesa-va-drivers-24.2.4-1.fc41.x86_64
mesa-vulkan-drivers-24.2.4-1.fc41.x86_64
mesa-libxatracker-24.2.4-1.fc41.x86_64

aurora40: from Oct 28 ✅
ghcr.io/ublue-os/aurora:40-20241028

mesa-libGLU-9.0.3-4.fc40.x86_64
mesa-filesystem-24.1.7-1.fc40.x86_64
mesa-va-drivers-24.1.7-1.fc40.x86_64
mesa-libglapi-24.1.7-1.fc40.x86_64
mesa-dri-drivers-24.1.7-1.fc40.x86_64
mesa-libgbm-24.1.7-1.fc40.x86_64
mesa-libEGL-24.1.7-1.fc40.x86_64
mesa-libGL-24.1.7-1.fc40.x86_64
mesa-vulkan-drivers-24.1.7-1.fc40.x86_64
mesa-libxatracker-24.1.7-1.fc40.x86_64
kernel-tools-libs-6.11.4-201.fc40.x86_64
kernel-tools-6.11.4-201.fc40.x86_64
kernel-modules-core-6.11.4-201.fc40.x86_64
kernel-core-6.11.4-201.fc40.x86_64
kernel-modules-6.11.4-201.fc40.x86_64
kernel-6.11.4-201.fc40.x86_64
kernel-modules-extra-6.11.4-201.fc40.x86_64
kernel-headers-6.11.3-200.fc40.x86_64

kinoite40: 25th Nov old mesa, new kernel
I have to test this image in the coming weeks.
ghcr.io/ublue-os/kinoite-main:40-20241125

mesa-libGLU-9.0.3-4.fc40.x86_64
kernel-modules-core-6.11.8-200.fc40.x86_64
kernel-core-6.11.8-200.fc40.x86_64
kernel-modules-6.11.8-200.fc40.x86_64
kernel-6.11.8-200.fc40.x86_64
kernel-modules-extra-6.11.8-200.fc40.x86_64
mesa-filesystem-24.1.7-1.fc40.x86_64
mesa-va-drivers-24.1.7-1.fc40.x86_64
mesa-libglapi-24.1.7-1.fc40.x86_64
mesa-dri-drivers-24.1.7-1.fc40.x86_64
mesa-libgbm-24.1.7-1.fc40.x86_64
mesa-libEGL-24.1.7-1.fc40.x86_64
mesa-libGL-24.1.7-1.fc40.x86_64
mesa-vulkan-drivers-24.1.7-1.fc40.x86_64
mesa-libxatracker-24.1.7-1.fc40.x86_64
kernel-tools-libs-6.11.8-200.fc40.x86_64
kernel-tools-6.11.8-200.fc40.x86_64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aurora KDE forever! bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants