Using old laptop with dumb frame buffer and external display

nouveau.modeset=0 can serve two unrelated purposes:

1-troubleshooting (e.g. enabling an otherwise failing installation process)
2-enabling proprietary X driver (e.g. NVidia)

It (same as nomodeset) doesn’t belong in a Grub stanza unless a proprietary video driver installation instruction says it’s required. Disabling KMS (as both nomodeset and nouveau.modeset=0 do) is incompatible with all major (AMD/ATI, Intel, NVidia) currently competent FOSS X drivers (ati, amdgpu, intel, modesetting, nouveau).

New attempt, should be available 1 week …

http://susepaste.org/97051767

The first crucial point is, how to get access to machine when the laptop panel is blown, and nothing is readable on the display (distorted color bands rolling over the screen)??

If there is no access to the Grub menu I suppose you’d need to remove the HD, attach it elsewhere to edit the Grub menu, then reinstall the HD to try again.

The solution was easier than I thought. HP laptops do switch between displays by entering the keys Fn+F4, which switched the video output to the local VGA connected monitor in my case. Still with the same visible stripes and glitches, 1280x1024 resolution filled on a 16:9 widescreen, but yet well readable. Does this redirected and still distorted video output tell something more about the graphics failure?

As Leap15 startup still freezes at the green router logo, I reinstalled a planned Leap42.3 on an available partition used earlier for multiboot setup. This also confirmed that the installation early ran into a black display and possibly freeze in behind, and I had to start again and use ‘nouveau.modeset=0’. Then the installation ran further.

So now I’m on a running Leap 42.3 both with the local VGA connected display, and after local login and wifi connection, also connect with my remote “ssh -X hp_ipadr”. The Fn+f4 switch has to be entered for each startup. AFAIK Leap 42.3/Gnome uses Xorg as default, and not Wayland as default like Leap15 does. This also generated a ‘/var/log/Xorg.0.log’ which is available here: http://susepaste.org/88215420

Where and how to edit back the Leap15 grub2 kernel parameters so that that it is possible to start it to go further next, possibly after testing with 42.3/Xorg first. The main purpose is to keep the Gnome desktop to run a few Gnome application (in-house).

http://susepaste.org/74090457

From the log:

Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.155-68-default root=UUID=96042c70-b57d-466e-be0b-9ec9110dab4b nouveau.modeset=0 resume=/dev/disk/by-uuid/d7172da6-bb44-4fc4-a594-cf925c34e63e splash=silent quiet showopts

Normal operation without a proprietary NVidia driver requires it be modified. I suggest:

BOOT_IMAGE=/boot/vmlinuz-4.4.155-68-default root=UUID=96042c70-b57d-466e-be0b-9ec9110dab4b resume=/dev/disk/by-uuid/d7172da6-bb44-4fc4-a594-cf925c34e63e

as a starting point. This can be done either by editing /etc/default/grub, followed by regenerating grub.cfg with grub2-mkconfig, or from YaST2 -> Bootloader. This should allow nouveau or modesetting to load and thus GDM and Gnome to run, albeit still with screen corruption.

The corruption on the external display points to hardware failure. Given the laptop’s age, it’s marginally possible to fix yourself if you are R&R capable, by re-seating components, including RAM modules. Bad capacitors are a possibility, usually identified by leaking or swelling, replaceable by following instructions on http://badcaps.net.

The above is for the working Leap 42.3 installation. I want preferably to start to re-establish the unworking Leap 15, which freezes at startup after ‘nouveau.modeset=0’ was removed from its kernel command line. I’m afraid that the same will happend with Leap 42.3.

Therefore I’ve mounted Leap15’s root file system on 42.3’s /leap15:

cat /leap15/etc/default/grub

# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-label/swap"
GRUB_CMDLINE_LINUX=""

# Uncomment to automatically save last booted menu entry in GRUB2 environment

# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#Uncomment to enable BadRAM filtering, modify to suit your needs

# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
# GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
#Uncomment to disable graphical terminal (grub-pc only)

GRUB_TERMINAL="gfxterm"
# The resolution used on graphical terminal
#note that you can use only modes which your graphic card supports via VBE

# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="auto"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
# GRUB_DISABLE_LINUX_UUID=true
#Uncomment to disable generation of recovery mode menu entries

# GRUB_DISABLE_LINUX_RECOVERY="true"
#Uncomment to get a beep at grub start

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"

How should this file be edited (from 42.3) and how might possibly the corresponding grub.cfg be regenerated so that Leap15 is able to boot again?

(At the same time, if possible:
Is the above ‘grub2-mkconfig’ command suse specific, because when I tried on XPS-13/Ubuntu18 (where I’ve add-installed Leap15 as dual-boot) it didn’t work on Ubuntu? That is when the Ubuntu kernel is updated there, Leap15 disappear from the grub2 dual-boot menu, and I have to update Leap also to get it back)

Ok, I re-installed also Leap 15 which boots now. I still had to use 'nouveau.modeset=0" and this time I un-selected the software pattern Gnome (Wayland).

Boots how now? Is the screen corruption gone? What does ‘inxi -Gxx’ in an Xterm report now?

There should be no difference other than the kernel version number. Again, nouveau.modeset=0 is for one of two things: 1-temporary, for troubleshooting or making the installer work, or; 2-permanent, required by unsupported proprietary software that requires it, such as NVidia’s drivers. The installer has a misfeature in that when nouveau.modeset=0 is used to make installation work it includes it “permanently” in config written to disk, which it shouldn’t do, but doesn’t know to do differently. If you get a black screen by keeping it, and you haven’t installed anything that requires it, then the cause of the need to keep needs to be discovered and fixed. No one using NVidia gfx hardware is going to get X to perform competently with nouveau.modeset=0 on the kernel cmdline without installing NVidia’s proprietary software. The rest of the world needs it removed so that one of the FOSS drivers that depend on its absence can be used. This is no different in 15.0 than it was in 42.3.

I’m afraid that the same will happend with Leap 42.3.
This is why one uses the e key at the grub menu to test a contemplated change. Once you know what works or not is time enough to edit any files on disk.

So, to make 15.0 work, without proprietary NVidia software, and without a black screen or keyboard lockup, remove nouveau.modeset=0, remove quiet, remove splash=silent, add plymouth.enable=0, all at the grub startup menu (temporary change), and see what happens. If good, make the change permanent by editing /etc/default/grub file and running grub2-mkconfig. If not good, more investigation is required.

Grub in openSUSE is Grub 0.97.x. Grub in buntu is v1.98+. 1.98+ in openSUSE co-exists with 0.97, so its filename(s) can’t be grub, thus grub2-mkconfig in openSUSE equates to grub-mkconfig in *buntu (also aliased to update-grub).

The boot usurpation issue on the XPS-13 needs its own thread.

Leap15 is not better - the same screen corruption exists on the VGA connected monitor, but with hardly ‘readable content’ (Before Fn+F4 switching, the laptop panel as mentioned not longer displays any reasonable content but stupid color bands or sections rolling over the whole display).

xterm output on the vga monitor (a Gnome terminal gives the same result):

inxi -Gxx
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
Graphics:  Card: NVIDIA G92GLM [Quadro FX 3600M]
           bus-ID: 01:00.0 chip-ID: 10de:061c
           Display Server: x11 (X.org 1.19.6 ) driver: N/A tty size: 80x24
xrandr --prop
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1280 x 1024, current 1280 x 1024, maximum 1280 x 1024
default connected primary 1280x1024+0+0 0mm x 0mm
        _MUTTER_PRESENTATION_OUTPUT: 0 
   1280x1024     77.00* 

And there is not any new Xorg.*.log available elsewhere.

http://susepaste.org/view/raw/74090457 says you were booting with nouveau.modeset=0. This apparently continues in 15.0’s above inxi report saying “driver: N/A”. You need to try editing (“e” key) at the grub menu, removing (backspace key) the following:

nouveau.modeset=0 splash=silent quiet showopts

and adding the following:

plymouth.enable=0

What happens?

Yes, I had to add ‘nouveau.modeset=0’ at the boot line during the Leap15 installation (from DVD), else it freezes with black screen a bit later in the installation. And so far, the ‘nouveau.modeset=0’ has seemed necessary to be kept in grub to avoid freeze also during boot of the final Leap installations.

Edited (removed and added) the code you suggest (tried ‘plymouth.enable=0’ both the place where ‘nouveau.modeset=0’ was before, and next time also at the end of this line).

Continued afterwards with F10. A lot of console text scrolled over the (switched to VGA) monitor, until after a while the text scroll switched automatic to the laptop panel and lastly displayed in parallell on both the monitor and the laptop panel before final Freeze each time after these lines:


[OK] Created slice User Slice of gdm
[OK] Started OpenSSH Daemon
[OK] Started Session c1 of user gdm
        Starting User Manager for UID 462
[OK] Starting User Manager for UID 462

That is freeze before any visible graphics or login menu.
(possibly continue to-morrow, late now)

This freeze is occurring much later than I understood, apparently triggered by GDM (or SSH?). So, next should be to eliminate GDM, and keep nouveau.modeset=0 eliminated. Your decade old hardware may have aged too much to be supported by GDM/GTK3/Gnome. Simplest next step should be at the grub menu to remove nouveau.modeset=0, and add 3, so that GDM does not try to start. Do you still get a freeze, or do vtty[1-6] all present usable shell prompts? If working prompts instead of freeze, next try ‘zypper rm gdm; zypper in lightdm’ or ‘zypper in sddm’, and try to login and start an IceWM session. Do this all locally, not via remote.

With ‘nouveau.modeset=0’ and graphics displayed, the recent time graphics failure and freeze has arised at the Leap15 splash screen (green router logo).

For the sake of curiosity, this hp8710w was a top-configured, high-end laptop/workstation model at its time, and with later SSD replacement disk included, it has indeed booted faster than many newer machines. It was delivered with Windows but certified for SLED10, and has run most openSUSE versions in dual-triple boot with Windows. I don’t remember when ‘nouveau.modeset=0’ first time was suggested for the installation. https://support.hp.com/ee-en/document/c01093115

Simplest next step should be at the grub menu to remove nouveau.modeset=0, and add 3, so that GDM does not try to start. Do you still get a freeze, or do vtty[1-6] all present usable shell prompts? If working prompts instead of freeze, next try ‘zypper rm gdm; zypper in lightdm’ or ‘zypper in sddm’, and try to login and start an IceWM session. Do this all locally, not via remote.

Got a useable shell prompt, removed gdm and lightdm was already installed (did not install sddm, as this would require 300 new packages), and tried this after login and su to root:

icewm
...........x must be running
startx
Xorg X Server 1.19.6
...
(==) Using config directory: "/etc/X11/xorg.conf"
(==) Using system config directory: "/usr/share/xorg.conf.d"

Display and KB freeze after this was displayed
(could still release the Bluray burner device).

Did also test a boot without removing the nouveau.modeset=0 from grub
Booted to LightDM (I guess), tried to select most sessions, no DE content (empty green display) of any Gnome sessions
Could login to IceWM with DE content.

Not quite sure where we are now with gdm removed or what is achieved. No X running yet or (?)

Your last reply is hard to understand. Were you able to get to a LightDM login screen both with and without nouveau.modeset=0 and plymouth.enable=0 used to boot? With 3 appended to kernel cmdline, did you try, as previously directed, ‘WINDOWMANAGER=/usr/bin/icewm startx’? IceWM runs both with and without without nouveau.modeset=0 and plymouth.enable=0 on cmdline? You can’t expect Gnome to work while nouveau.modeset=0 is used, unless an NVidia X driver is installed and operational. If X even tried to start after removing GDM there should be at least one fresh Xorg.#.log to help us figure this out. If there are no traces of NVidia driver installed, without nouveau.modeset=0 and with plymouth.enable=0 on cmdline we should be able to get at least an IceWM session running either with startx, or via the lightdm greeter. For startx to work might require logging in as root (as a troubleshooting step). Without without nouveau.modeset=0 or quiet or splash=silent, and with plymouth.enable=0, does icewm fail? If yes, are there any clues in the journal or dmesg? Is there still corruption on both local displays?

So far I get LightDM only with ‘nouveau.modeset=0’ kept. From there I can select and log into a IceWm session that works.

Else, removing ‘nouveau.modeset=0’ (or also ‘quiet’ and ‘splash=silent’) and adding ‘plymouth.enable=0’ cause freeze with a mostly black display.

With 3 appended to kernel cmdline, did you try, as previously directed, ‘WINDOWMANAGER=/usr/bin/icewm startx’? IceWM runs both with and without without nouveau.modeset=0 and plymouth.enable=0 on cmdline?

Replaced ‘nouveau.modeset=0’ with ‘plymouth.enable=0’ and added 3:

Got a CLI login prompt
Logged in as root

WINDOWMANAGER=/usr/bin/icewm startx

Caused freeze after the following three lines (without any graphics displayed)


Xorg X Server 1.19.6
...
Logfile /var/log/Xorg.0.log
(==) Using config directory: "/etc/X11/xorg.conf"
(==) Using system config directory: "/usr/share/xorg.conf.d"

The fresh Xorg.0.log is pasted here:

SUSE Paste
SUSE Paste

If X even tried to start after removing GDM there should be at least one fresh Xorg.#.log to help us figure this out. If there are no traces of NVidia driver installed, without nouveau.modeset=0 and with plymouth.enable=0 on cmdline we should be able to get at least an IceWM session running either with startx, or via the lightdm greeter. For startx to work might require logging in as root (as a troubleshooting step).

Without without nouveau.modeset=0 or quiet or splash=silent, and with plymouth.enable=0, does icewm fail? If yes, are there any clues in the journal or dmesg? Is there still corruption on both local displays?

Beyond Xorg.0.log, I’m not sure what to possibly search (grep) for in dmesg or journal ?

From that log I see this:

Kernel command line: ... nouveau.modeset=0 ... splash=silent quiet showopts  13.599] Build Date: 17 April 2018 12:00:00PM

Thus it’s not a log from booting as requested, and unhelpful. We need an indication what is going wrong when KMS is not disabled.

Beyond Xorg.0.log, I’m not sure what to possibly search (grep) for in dmesg or journal ?

dmesg | grep -i failed
journalctl -b | grep -i failed

would be starting points.

Is /etc/modeprobe.d/50-blacklist.conf 5009 bytes dated 11 June?