How to revert KMS Display Settings to default IF I can only access desktop with nomodeset in grub?
Problem:
Was using desktop normally and had to reboot after desktop froze.
The monitor now gets no signal when attempting to boot into the OS.
I attempted to boot into a recovery mode in grub boot with "init=/bin/bash/" and that also gets no signal.
Adding nomodeset in grub, allows me to boot into and access and use the desktop.
I'm using an AMD RX 6800 XT GPU.
Possible Solution Question:
How do you revert KMS Display Settings to default if you can only access the desktop with nomodeset? While in nomodeset I don't even see everything I had installed like desktop effects for instance, so I don't know how to remove them if I can't see them. I assume that if I were able to revert KMS display settings to default and save them, that next time I try to boot normally, I will be able to see the desktop again without getting no signal.
90 Replies
not really sure what has happened for you, but what are your kargs?
rpm-ostree kargs
maybe it will give us somewhere to start looking since nomodeset works for you
it is odd that you are the only person who has the issue as i run an rx 6600xt myself and i think someone else has the same card as yourd.luks.options=discard rhgb quiet root=UUID=[Numbers Edited By Me in this UUID message for potential privacy/security purposes] rootflags=subvol=root rw ostree=/ostree/boot.0/default/c9a3acf1383c3bb8ccadb7e17dc817103e89ec06cf9b640cd0dd0bcbe8968198/0 kvm.ignore_msrs=1 kvm.report_ignored_msrs=0
Hopefully this will suffice for what you asked for
for reference the uuid is just your partition uuid, you get a new one whenever you format the partition 🙂
I wasnt sure, but I try to be cautious when I do something im not sure about
thats fine
hmm nothing in kargs should cause the issue
what does
rpm-ostree initramfs say?Initramfs regeneration: enabled
Initramfs args: "-I /etc/crypttab /etc/modprobe.d/amdgpu.conf"
ok thats normal too and
/etc/modprobe.d/amdgpu.conf should only contain
How do I check to make sure thats the case?
Nevermind, figured that out. Yes thats the exact thing it contains in mine.
I don't think I messed with any of the larger configs that you are asking me to check. I mostly just added desktop effects, themes, maybe changed resolution, added widgets, stuff like that.
i wanted to check it since nomodeset bypassed the issue
Of course, but just letting you know, nonetheless 🙂
did you ever try an older image after you got the issue?
No I haven't
oh ok
I really need to fix this one somehow, I dont have a way to test a different version
you can rebase to a different version if you have a date you know your computer worked within the last 90 days
as that can help us find out if its caused by an updated driver
Well first, I dont know how that even works, and second, what happens to my files if I were to do that?
nothing happens to your files
it only replaces the immutable system part with an older version
Oh I see
Could it potentially be caused by a failed update?
As I do remember a few days ago seeing some message about update failing
Is there some log I can view to see the update failed message?
not sure how rpm-ostree handles failed updates (as in interrupted during commit)
if it was from the ublue updater its probably a distrobox update failing as thats usually the case
systemctl status ublue-update right after you see the message
but if you want to try an older image (since i am sure your current previous image is no longer the last one that worked as there have been updates since your post)Id say maybe try one 2 weeks ago
rpm-ostree status to get your current image urlim guessing because this issue occurred like 1-2 days ago, but it may have already happened 7 days before that and i just hadnt noticed it yet until i had to restart
then copy that link and do
rpm-ostree rebase linkhere and replace the part after the : at the end with 39-yyyymmdd
yyyy = 2024
mm = 01
dd = day of month you want to go back tobut to be honest It may have even happen a month ago because one time i had restarted a month or so ago, and i got no signal, so i kept restarting the desktop and it finally worked randomly, but this time when it happened again, i restarted like 100 times and nothing worked except nomodeset
I didnt document the issue enough unfortunately so I apologize for less precision on that
example:
ostree-image-signed:docker://ghcr.io/hikariknight/deckstation:latest --> ostree-image-signed:docker://ghcr.io/hikariknight/deckstation:39-20240111
thats fine
also dont use that link as a rebase url, its my own personal image and its my testing playground 🤣
its just an exampleok theres a bunch of text there, what am i looking for specifically
ostree-image-signed:docker blablabla
thats the image url
its showing three of them
ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:39
Version: 39.20240112.0 (2024-01-12T16:51:48Z)
Version: 39.20240108.0 (2024-01-08T16:12:45Z)
Version: 39.20231230.0 (2023-12-30T23:56:29Z)
that means you have 1 current, 1 previous and 1 pending/incoming most likely unless you pinned one
i also see this, perhaps its related to the issue somehow? "LayeredPackages: edk2-ovmf guestfs-tools libvirt-daemon-config-network libvirt-daemon-kvm
python3-libguestfs qemu qemu-kvm virt-install virt-manager virt-top virt-viewer
"
stuff i manually installed It seems
i doubt its related to those as i use virt-manager qemu and ovmf myself
ok
well you do have previous deployments
1 from 8th of january andone from 30th of december
you can try select either ostree:1 or ostree:2 from your grub boot then
as that will effectively be an older image
I tried it, they still have no signal
is it no signal for the whole boot sequence or is it after login?
no signal immediately after grub, no bazzite loading screen appears
i know my card does not like x11 and gives me a black screen (but does give signal)
an i even let it run like 15 minutes, no signal the entire time
ok i have no idea whats going on then 🤔
when i use nomodeset, i immediately get bazzite loading screen after grub
and desktop login appears in a few seconds
I believe its some display settings in the KMS that need to be set to default
for instance i have wobbly windows effect turned on
i forget the actual name
But I think some of those settings really did a number somehow
else its the failed update thingy
when you say KMS i am thinking kernel mode setting
well, I used an ai to help me and it told me its called KMS lol
but maybe its wrong
i was asking it how to change the default settings and save them while in nomodeset
it was not helpful at all
wobbly windows wouldnt give you a black screen right after grub though
fair point
a failed video driver issue maybe
do you have access to a second computer?
sort of, it depends what needs to be done with it
ssh login to your computer that has the issue and get logs from it
when it fails at booting
ah
theres no way to view the logs in nomodeset?
im using nomodeset right now to speak to you
you can maybe grab some previous logs
but they will be rotated by day
if we can do it that way, itd be ideal
so might be a lot of stuff we do not need
i can reboot desktop to generate the log
just tell me everything i need to do, and ill write down the time and everything so we know where to look
dmesg might be useful
and maybe cat /var/log/boot.logok and those are only after i reboot again to generate a new log right
as im trying to follow what you want me to do without assuming
dmesg will print its log to the screen so you can just do
dmesg > ~/dmesg.log to write it to your homefolder
the other one you couls be able to just cp
so you want me to copy those now?
I thought you want the messages from the boot after grub
A bit confused
copy them when you are connected over ssh when there is no output on the screen
if you are familiar with ssh
oh, ive never used ssh before
im not a linux newb but in some cases i may as well be
I dont know how to connect via ssh
also, the other pc id have to use is likely compromised so not ideal to use it..
well you can enable ssh on the computer with
sudo systemctl enable --now sshd
then grab the ipaddress for the machine using ifconfig
then when you reboot you can use ssh username@ipaddress to connect to the computer
as long as the boot process completes and you get a login screen or desktop in the background, you will be able to access the commandline through sshis this the only way you know of? theres no way to just generate a log file without using ssh?
its what i use if i get an issue where any normal way to interact with the pc is not possible
alternative would be to remove
quiet from the kernel args in grub and hope it will show something before screen goes black againalso I may as well share some of these error messages I already see in dmesg,maybe itd be useful somehow
0.139137] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
[ 0.139137] MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.
ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
7.452017] gcadapter_oc: loading out-of-tree module taints kernel.
[ 16.000732] i2c i2c-0: 2/8 memory slots populated (from DMI)
[ 16.000737] i2c i2c-0: Systems with more than 4 memory slots not supported yet, not instantiating SPD
[ 16.031557] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 16.073141] scsi 1:0:0:1: Failed to get diagnostic page 0x1
[ 16.073146] scsi 1:0:0:1: Failed to bind enclosure -19
[ 16.073162] ses 1:0:0:1: Attached Enclosure device
16.733898] EDAC sbridge: Seeking for: PCI ID 8086:2fbb
[ 16.733927] EDAC sbridge: CPU SrcID #0, Ha #0, Channel #0 has DIMMs, but ECC is disabled
[ 16.733932] EDAC sbridge: Couldn't find mci handler
[ 16.733934] EDAC sbridge: Failed to register device with error -19.
[ 18.945885] kauditd_printk_skb: 24516 callbacks suppressed
considering this is from nomodeset it might just ignore the actual issue
27.651704] kvm_intel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.
[ 28.661402] kwin_wayland[1589]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
how would i do the ssh thing using windows over wifi? walk me through it like im a baby cause you didnt give enough context as i never did it before
im going to try removing the quiet from grub first
you would use the cmd or powershell, windows 10 has had the ssh client in it for a while
same command
and is the cpu data leak thing from nomodeset or is that something else? is there fixes for that yet?
just a warning about a hardware vulnerability related to hyperthreading (essentially if you care about it, disable hyperthreating/smt in bios and get less performance)
I did this, which one is the ip address? lo? enol? tailscale0? virbr0?
the device name will be different for you
but its not tailscale0 or virbr0 or lo
lol well guess ill have to try a few
its the inet and not the broadcast right?
most local networks are 192.168.xxx.xxx
inet is the ip
ok
if this doesnt get us anywhere then we will have to ping kyle and check if he has any ideas since he does the most work on bazzite and might have an inkling to what it might be, or he might be as confused as me about the issue.
ok
so 1. try removing quiet from grub
2. open second desktop with windows open command prompt and ssh "myusername@myip
3. type dmesg > ~/dmesg.log
4. sudo cp /var/log/boot.log ~/boot.log
5. sudo chown $USER:$USER ~/boot.log
look good?
6 and 7 are the same line
what do you mean
and 4 and 5 are the same line
as in they are the same command
2 commands
not 4
you mean its like this?: sudo chown $USER:$USER ~/boot.log
yes
got it
same with the copy of the log
once both commands are run you can reboot and grab the logs from your home directory
ok great, you mean reboot with nomodeset right
also how do i turn off ssh after im done with it
reboot without adding nomodeset
ok i meant when i go and get the logs when im done doing the ssh thiing
im going to go try it now
yeah then you reboot back to nomodeset after you copied the logs
thank you for trying to help I really appreciate it
if you just get connection refused even after a min or 2 then it means the pc is not finishing the boot sequence
did you get into the pc?
So I did what you said, but before I even looked at the logs, I got a lost signal again even with nomodeset. So I checked the hdmi wire and it was coming loose and now I can get into the desktop without nomodeset, however, I dont want to mark this as solved yet just in case there is some additional weirdness going on, as I swear I checked the wire before I even posted this topic
Its also strange to me that if thats the actual issue, that i could still access so much without the wire plugged in
would make sense given how goofy this issue is
AMD is a first class citizen on linux, especially your model
should be zero problems