"Display not found" after upgrade to 15.2 and nvidia & nouveau removed?? only tty

@mrmazda posted: Please upload /var/log/Xorg.0.log or ~/.local/share/xorg/Xorg.0.log where we can take a look - in a new thread with an appropriate thread subject.

Odds are NVidia driver installation has been imperfectly purged. If you have nomodeset or nouveau.modeset=0 on kernel cmdline it must go.

Folks:

Jumping over to a new thread with news of fresh disaster on the upgrade from 15.1 to 15.2 in my '09 MBP with nvidia card . . . ran it via zypper and that failed half way through, then did a “fresh upgrade” via a usb drive . . . and that showed “removing nvidia” from the repos, but after the install rebooting to the new 5.3 kernel brought an “OOPS” window . . . and only the old 4.12 kernel would boot. Advice from the forum suggested that “there are no nvidia drivers for 15.2” and suggestion to “remove nvidia and nouveau to get the default video driver” . . . and then the request posted above . . . to which showed, “no file or directory found.”

Since then I tried to run “zypper rm nvidia.” and “zypper rm nouveau.” and both of those commands showed “no nvidia products found” and “no nouveau products found” . . . but then running lsmod showed that “nouveau” was still listed in the video sub-category along with apple_gmux . . . .

So now on reboot the pumping Leap splash shows, then it goes to a window with a bunch of question marks, then it goes to grub . . . and selecting any of the options for kernel loads the dmesg and goes to a tty log in . . . no gui . . . .

I tried to install “pastebinit” but I guess that isn’t an OpenSUSE product . . . I also tried to run “zypper autoremove” to try to clean out any “stuff” but seems like zypper doesn’t know from “autoremove” . . . .

So right now I have a nice tty console . . . hoping to get down to the default, what “DDX”???

n_s

What exactly is a

fresh upgrade
Did you mean fresh installation??? If so, there would be no proprietary NVidia software installed.

zypper rm "*nvidia*"
zypper rm xf86-video-nouveau

will eradicate nvidia rpms and the nouveau DDX, but it won’t necessarily undo /lib/ damage done by the original nvidia driver installation process, and may leave behind /etc/X11/xorg.conf or /etc/X11/xorg.conf.d/* that needs to be removed. This would be particularly true having had the 15.1 to 15.2 process intervene. NVidia tainting needs to be removed according to the instructions that accompany nvidia installation.

In openSUSE instead of pastebinit we have susepaste, which seems to be broken more often than not. I just tested what I wanted to have you do and it didn’t work.

You could try force reinstalling the major X components:

zypper rm xorg-x11-driver-video xf86-video-nouveau
zypper al xorg-x11-driver-video xf86-video-nouveau
zypper in -f \
xorg-x11 \
xorg-x11-Xvnc \
xorg-x11-essentials \
xorg-x11-fonts-core \
xorg-x11-server \
Mesa \
Mesa-demo-x \
Mesa-dri \
Mesa-gallium \
Mesa-libEGL1 \
Mesa-libGL1 \
Mesa-libGLESv2-2 \
Mesa-libglapi0
zypper in -f
xorg-x11 \
xorg-x11-Xvnc \
xorg-x11-essentials \
xorg-x11-fonts-core \
xorg-x11-server \
Mesa \
Mesa-demo-x \
Mesa-dri \
Mesa-gallium \
Mesa-libEGL1 \
Mesa-libGL1 \
Mesa-libGLESv2-2 \
Mesa-libglapi0 \
libx86emu2 \
libxcb-composite0 \
libxcb-dri2 \
libxcb-dri3 \
libxcb-glx0 \
libxcb-icccm4 \
libxcb-image0 \
libxcb-keysyms1 \
libxcb-present0 \
libxcb-randr0 \
libxcb-render-util0 \
libxcb-render0 \
libxcb-shape0 \
libxcb-shm0 \
libxcb-sync1 \
libxcb-util1 \
libxcb-xfixes0 \
libxcb-xinerama0 \
libxcb-xkb1 \
libxcb-xv0 \
libxcb1 \
libxkbcommon-x11 \
libxkbcommon0 \
libxkbfile1 \
libxshmfence1 \
libxslt1 \
libxvidcore4 \
xf86-video-vesa \
xf86-video-fbdev \
xdpyinfo \
xrandr

A fresh scratch installation would seem easier.

The kernel module named nouveau is required for the nouveau DDX and the modesetting DDX to utilize the kernel modesetting functionality they depend on. You can’t remove it. It’s a kernel package component. You can only blacklist it if you don’t want it utilized.

@mrmazda:

It was a “fresh” install that I selected “upgrade” . . . .

filtered for error messages
Code:
sudo journalctl -p err -b
Any failed units?
Code:
sudo systemctl list-units --state=failed

I ran some of the deano_ferrari commands and it showed a couple of errors . . .

usbhid 4-1.3:1.0: can't add hid device -62

and then state=failed

display-manager.service loaded failed failed X Display manager

Seems like this “upgrade” is a botch up . . . and perhaps rather than trying to recover it and “force” all of those line items, perhaps better to start with a nuke n pave . . . ?? If there was a simple way to run a couple of lines of command to get X back it might be worth fiddling with, but perhaps the botch is irreparable???

What is reported by

sudo systemctl status display-manager
sudo journalctl - u display-manager

You could capture this output to a text file like this

sudo systemctl status display-manager > out.txt
sudo journalctl - u display-manager > out2.txt

then copy to a memory stick so that you can easily share verbose output.

Here’s the basic idea on how to do that from a TTY…

You can also do this using udiskctl

udisksctl mount -b <device_name>

where you get that info from

lsblk

or

sudo fdisk -l

Copy your file(s) to the mounted device and then transfer to a computer that does have a graphical environment and a working internet connection to share here.

@deano_ferrari:

OK, thanks for that series of commands and the link to the how to . . . . I ran the commands . . . have to delete the contents on a usb flash drive . . . which will take some time . . . . It isn’t a whole lot of data that shows up, but I would need a “hint” on the command to “copy” the two files over to the usb drive . . . is that a “sudo nano cp out.txt out2.txt usb_flash_drive” type of deal?

The last four lines of each of those commands both show red letter

Failed to start X Display Manager
unit entered failed state
Triggering OnFailure=dependencies
Failed with result 'exit-code'

It could be that only this is needed. Xorg for a pure FOSS installation normally is configured automagically on each startup. /etc/X11/xorg.conf* created by NVidia installation blocks some of the needed automagic that enables a FOSS DDX to function.

@mrmazda:

OK, since I am walking down this DDX road with you thus far why not a step further . . . so possibly I can run “sudo zypper rm /etc/X11/xorg.conf*” and/or the other option you posted, and then try a reboot and see how that goes?

I’m about to get to Sat night festivities, so I won’t be running it just yet, but I could get to tomorrow and give it a run . . . but I would want your detailed commands so that “pilot error” will be minimized on it.

No NO don’t use zypper that is for packages not files. Just remove (rm command) the mentioned files as root. (note be very careful with rm command as root since if you do it wrong you can zap the whole system. Be very sure of the parameters before pressing enter


/etc/X11/xorg.conf or /etc/X11/xorg.conf.d/*

Hi
Just check down in there for a xorg.conf file that may have been created, I see none of that these days unless running the nvidia-xconfig application.

By default Wayland is used these days… maybe there is some sort of conflict, are wayland bits installed? What does the output from (p)inxi say?

Yes, you can use the cp command. You can get the device path via ‘lsblk’ or ‘mount’ commands. There are lots of tutorials online for basic stuff like this. Good to learn basic Linux CLI skills for situations like this.

OP should take this opportunity to try midnight commander, mc on the cmdline. If it isn’t already installed:

sudo zypper in mc

It’s a text mode swiss army knife, a member of a class of programs called orthodox file managers. With it you can navigate, find, view, copy, move/rename, edit, delete, extract and much, much, much, much, much more, all without leaving a shell prompt. I use it in Konsole as well.

Any time I have to work without MC available it’s like trying to walk with one leg, write with one finger, or read a book at night with only a candle 3 meters away for lighting.

/etc/X11/xorg.conf.d/ for 15.2 should look pretty much as follows:

# ls -l /etc/X11/xorg.conf.d/
-rw-r--r-- 1 root root  232 Dec 12  2016 00-keyboard.conf
-rw-r--r-- 1 root root 1099 Jul 23 09:23 10-evdev.conf
-rw-r--r-- 1 root root 1350 Jul 23 07:24 10-quirks.conf
-rw-r--r-- 1 root root  484 Jul 23 09:23 11-evdev.conf
-rw-r--r-- 1 root root  975 Jul 23 13:34 40-libinput.conf
-rw-r--r-- 1 root root  529 Jul  1  2011 50-device.conf
-rw-r--r-- 1 root root  199 Jul 23 09:23 50-elotouch.conf
-rw-r--r-- 1 root root  264 Jul 23 07:24 50-extensions.conf
-rw-r--r-- 1 root root  527 Jul  1  2011 50-monitor.conf
-rw-r--r-- 1 root root  491 Jul  1  2011 50-screen.conf

If there’s a material difference (other than keyboard), good chance it’s something NVidia installation left or modified there, and needs removal, if not by deletion then by renaming to not end in .conf.

@et al:

Thanks gents for the follow-up . . . I’ll check back into this tomorrow . . . and post back with the latest . . . good or bad. : -)

@mrmazda, et al:

Failure once again . . . continues to be the theme . . . ran the rm /etc/X11/xorg.conf and it said, “no such file” . . . for some reason I couldn’t find the post that showed what the contents were supposed to look like, so I just ran the rm /etc/X11/xorg.conf.d/* and that paused for a half second and then returned . . . so I assumed that was done. I rebooted and . . . nuttin’ . . . back to the TTY.

I shut the computer down for a few hours, when I came back I tried a cold boot . . . same deal . . . then I tried to run what we used to have to do in PPC linux to get an Xorg.conf “created” which is essentially “sudo Xorg --configure” after trying to “stop lightdm service” . . . anyway, none of those commands were recognized or done.

Tried to run an zypper ref && zypper dup . . . and it said “2 packages are locked and will not be changed xf86-video-nouveau xorg-x11-driver-video nothing to do.”

Don’t have the time to fiddle with mounting a usb flash drive in the cli right now . . . but, any other thoughts on how to get an xorg.conf file created I could give it a try??

# ll /etc/X11/xorg.conf
ls: cannot access '/etc/X11/xorg.conf': No such file or directory
# ll /etc/X11/xorg.conf.d/*vidia*
ls: cannot access '/etc/X11/xorg.conf.d/*vidia*': No such file or directory
# rpm -qa | grep nel-def
kernel-default-4.12.14-lp151.28.20.1.x86_64
kernel-default-5.3.1-lp152.1.4.x86_64
# inxi -V | head -n1
inxi 3.0.36-00 (2019-08-14)
# inxi -GxxS
System:    Host: p5bse Kernel: 5.3.1-lp152.1-default x86_64 bits: 64 compiler: gcc v: 7.4.1 Desktop: KDE 3 wm: kwin dm: startx
           Distro: openSUSE Leap 15.2 Alpha
Graphics:  Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0
           chip ID: 10de:107d
           Display: server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
           resolution: 1920x1200~60Hz
           OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.2 compat-v: 3.1 direct render: Yes

90 minutes ago the system the above is from was 15.1. The result shown is from zypper dup. It’s my 3rd 15.2 using an old NVidia GPU. All run on the modesetting DDX.

Probably it’s time for for OP to try a fresh installation instead of trying to figure out what went wrong because of having had proprietary software installed in 15.1.

@mrmazda:

Interesting that your install also shows “no such file” for the xorg.conf file . . . but, does seem like the fresh install is probably the best “solution” to this series of problems . . . . Thanks for the directions to everyone who posted here . . . .

Not at all. /etc/X11/xorg.conf is an optional file that is not often of any value, unless needed by a proprietary driver installation to override system defaults or automagic, or other need to override.