Other Features of the Installer
Without options, the .run file executes the installer after unpacking it. The installer can be run as a separate step in the process, or can be run at a later time to get updates, etc. Some of the more important commandline options of nvidia-installer are: nvidia-installer options --uninstall
During installation, the installer will make backups of any conflicting files and record the installation of new files. The uninstall option undoes an install, restoring the system to its pre-install state. --ui=none
The installer uses an ncurses-based user interface if it is able to locate the correct ncurses library. Otherwise, it will fall back to a simple commandline user interface. This option disables the use of the ncurses library.
This is way out of my league #lol
I don’t feel confident in doing these kind of things on my system. I am afraid I will break it. I am a very basic Linux user. I did try to get more info with logwatch but I was not able to set it up and would not recognize my commands.
Sure, I could change nvidia_drm.modeset=1 kernel parameter but I doubt it will resolve it.
Indeed, after cat /proc/cmdline I don’t get anything else, there is no resume=entry
Strange enough, I was able to see that this issue kinda “disappears” temporarily if I restart the computer from any active session, then it will reach login screen without going through that strange screen display thing.
It sounds very steampunk, like it would appear when Nvidia card is not “heated up”
I wonder if an update would be able to fix it…
is needed.
I could be wrong but it seem like really a plymouth issue. Looks like it can’t fire plymouth due to some not supported resolution.
You can try this:
When you boot and see the boot screen press c you will be taken to the Grub prompt.
Type videoinfo and see the supported video resolution. Then post it here.
Opps my apologies again… I was not clear enough. Due to my eyes problem I am not able/forgot to type some words I want to include in my post. I was planning to write" kde plasma wayland",that’s what the nvidia_drm.modeset=1 is needed without it I’ve seen my screen just turned black after login all the time with nvidia gpu.
Thanks for the link, I’ve already see it on the past but never paid to close attention at the time, will do when I have some free time.
In my case it’s just to test parameters temporary and be able to revert the change if something goes wrong but thanks for the precision about the conf files.
I can completely relate to that nvidia_drm.modeset=1 did not change anything for me as for the resume= it doesn’t look like it can be the cause of the problem ( thanks to your logs ).
Just to add to the discussion about this, reading multiple thread on the OpenSuse reddit I can see that there’s a good amount of people that have issues with the 545 drivers ( here is a list of the threads https://paste.opensuse.org/pastes/c360b1b7f768 )
To summaries the issues there are the long and glitched boot witch is the center of the discussion here but also it seems that wayland session do not work, also Leap users seems to be impacted too ( they are on 545 version too )
So maybe adding nvidia_drm.modeset=1 as conram suggested solve the wayland problem but not the boot problem ? I have not started a wayland session since June so …
For now I will restart and try adding the nvidia_drm.fbdev=1 to the kernel parameters to see if it change something …
For some reasons my long broken shutdown seems to be fixed … no idea why and what fixed it if it was starting with nvidia_drm.fbdev=1 or if it’s because I have accidentally displayed the kernel version chooser screen the first time and selected the first one or if it’s because I haven’t put my computer to sleep before every restart …
Didn’t tried to start a wayland session …
I think we will need to wait and hope a new version of nvidia ( or the kernel maybe ? ) will solve the issues, for now my computer is still usable and I always put it to sleep anyway, so it’s either I rollback and lock the 535 version or live with the inconvenience
Yes it’s experimental but it was worth trying, thanks for trying.
@Aboutduck well just remove all the plymouth and libplymouth packages and lock, then run dracut -f --regenerate-all and then won’t need that entry. It may not want to remove one or two plymouth files from memory zypper rm *ply* then add a lock zypper al *ply*
I think for now I will just keep the plymouth.enable=0 in the kernel parameters to disable it but keep plymouth installed just in case I need to enable it again, I don’t really want to risk breaking more things just now
I will keep that in mind for the future, thanks for the explanation.
@Aboutduck ok, well if you edit grub at boot and add a 3 to the end of the linux[efi] line and boot to multi-user target it’s all ok? Then from that tty login as root user and run systemctl isolate graphical.target what happens?
Just tried adding 3 to the linux line from Grub ( plymouth still disabled ) and I did get all of the boot errors (
flip event timeout … ) before it asked for my user/password.
Logged in as root ( the TTY wish me fun ) and tried to type systemctl isolate graphical.target, screen did turn back for a brief moment and the graphical usual login screen show up.
After that I have rebooted, in another note it feel like starting the computer with plymouth disabled is faster…
So it gets removed…