Leap 15.2 was running trouble-free and now will hang with a black screen at boot.

English Install/Boot/Login
1

I’m hoping someone can help with an interesting problem I’m having.

Background
I’ve been running various versions of opensuse on my desktop since 12.1, up to Leap 15.2, in a dual boot config. For the most part, it has been trouble free. The hardware is at least 5-6 years old, perhaps slightly older. I’m only sharing this to communicate that I’m not trying to get Leap to run with the latest and greatest.

I had to replace my monitor about a month ago so I decided to go with a dual monitor configuration. My video card is an Asus AMD/ATI chip card with dual DVI and dual Display Ports. With my old monitor, I just used a single DVI connection. The new monitors are connected to the graphics card using the display ports. I have not installed the proprietary graphics card drivers, rather I use the default ones provided with Linux.

When I made the monitor switch there were no issues. As of last week, the machine will boot to the grub menu where I can select Leap, and then the boot sequence hangs. The only way I can get past this is to boot with the kernel option “nomodeset”. I can make things work, but it has really reduced performance in this configuration. Additionally, I can boot into my the Windows partition with no issues so the hardware seems to be okay.

I’m assuming the issue with booting to Leap has to do with with getting the graphics drivers loaded appropriately, or something like that. I’m not sure how to troubleshoot the issue.

Would anyone have some suggestions on where to focus?

2

I wondered if potentially I had corrupted my install of 15.2 so I decided to go upgrade to 15.3 beta to see if it would make any difference. No change :(… 'm experiencing the exact same behavior. If I boot with nomodeset I can get to the plasma login screen, and login. Of course the graphics are **** in this config.

While trouble shooting a little more I pulled the following system information.

Executing the following:

inxi -Fxz

Provided this output:

System   Kernel: 5.3.18-56-default x86_64 bits: 64 compiler: gcc v: 7.5.0 Desktop: KDE Plasma 5.18.6 
           Distro: openSUSE Leap 15.3 
Machine:   Type: Desktop Mobo: ASUSTeK model: M4A88T-M v: Rev X.0x serial: <filter> BIOS: American Megatrends v: 2202 
           date: 06/25/2010 
CPU:       Topology: 6-Core model: AMD Phenom II X6 1090T bits: 64 type: MCP arch: K10 L2 cache: 3072 KiB 
           flags: lm nx pae sse sse2 sse3 sse4a svm bogomips: 38576 
           Speed: 804 MHz min/max: 800/3200 MHz Core speeds (MHz): 1: 804 2: 995 3: 804 4: 803 5: 3211 6: 804 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Barts XT [Radeon HD 6870] vendor: ASUSTeK driver: N/A 
           bus ID: 01:00.0 
           Display: x11 server: X.Org 1.20.3 driver: ati unloaded: fbdev,modesetting,radeon,vesa 
           resolution: 1400x1050~77Hz 
           OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 20.2.4 direct render: Yes 
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] SBx00 Azalia vendor: ASUSTeK M4A785TD driver: snd_hda_intel 
           v: kernel bus ID: 00:14.2 
           Device-2: AMD Barts HDMI Audio [Radeon HD 6790/6850/6870 / 7720 OEM] vendor: ASUSTeK driver: snd_hda_intel 
           v: kernel bus ID: 01:00.1 
           Sound Server: ALSA v: k5.3.18-56-default 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
           vendor: ASUSTeK P8P67 and other motherboards driver: r8169 v: kernel port: e800 bus ID: 02:00.0 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 1.36 TiB used: 397.21 GiB (28.4%) 
           ID-1: /dev/sda vendor: Seagate model: ST31500341AS size: 1.36 TiB 
Partition: ID-1: / size: 41.40 GiB used: 16.48 GiB (39.8%) fs: ext4 dev: /dev/sda7 
           ID-2: /home size: 904.02 GiB used: 362.68 GiB (40.1%) fs: ext4 dev: /dev/sda5 
Swap:      ID-1: swap-1 type: partition size: 11.68 GiB used: 0 KiB (0.0%) dev: /dev/sda6 
Sensors:   System Temperatures: cpu: 28.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 232 Uptime: N/A Memory: 7.76 GiB used: 1.21 GiB (15.6%) Init: systemd runlevel: 5 Compilers: 
           gcc: 7.5.0 Shell: bash v: 4.4.23 inxi: 3.1.00

Is the graphics driver N/A a function of booting nomodeset, or is the system really not loading a driver? Could that be my problem?

3

When “hung”, does Ctrl-Alt-F3 produce a login prompt?

Are your new displays greater than 1920x1200 resolution?

Does /etc/X11/xorg.conf exist? If yes, remove or rename it and restart without using nomodeset. Are there any *.conf files in /etc/X11/xorg.conf.d/ containing uncommented lines including the Sections: Device, Monitor or Screen? If yes, remove/rename them and restart without using nomodeset. Do also

sudo zypper rm xf86-video-ati

and restart without nomodeset. The Radeon DDX driver seems to have been acquiring regressions on older GPUs. The Modesetting DIX is newer technology that should automatically be loaded instead of the Radeon DDX in its absence may clear the problem, but only without booting with nomodeset. Both drivers depend on KMS, which nomodeset disables.

The driver that doesn’t get loaded is the radeon kernel driver, prevented from loading by nomodeset. Competent operation of your Radeon requires the Radeon kernel driver be loaded.

The Leap inxi version is a broken antique: driver: ati is wrong. Try running inxi -U to see if it upgrades from 3.0.1 to 3.3.04. If it does, which inxi -I will report, then try it this way:

# inxi -GISay
System:
  Host: gx78b Kernel: 5.3.18-lp152.41-default x86_64 bits: 64 compiler: gcc  v: 7.5.0
  parameters:...noresume mitigations=auto consoleblank=0
  Desktop: Trinity R14.0.9 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 vt: 7
  dm: TDM Distro: openSUSE Leap 15.2
Graphics:
  Device-1: AMD Caicos **Radeon HD 6450/7450/8450 / R5 230 OEM**] vendor: Dell
  driver: radeon v: kernel bus-ID: 01:00.0 chip-ID: 1002:6779 class-ID: 0300
  Display: server: X.Org 1.20.3 driver: **loaded: modesetting** display-ID: :0
  screens: 1
  Screen-1: 0 s-res: **2560x2520** s-dpi: 120 s-size: 541x533mm (21.3x21.0")
  s-diag: 759mm (29.9")
  Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
  diag: 686mm (27")
  Monitor-2: DVI-I-1 res: 2560x1080 hz: 60 dpi: 97
  size: 673x284mm (26.5x11.2") diag: 730mm (28.8")
  OpenGL:
  renderer: AMD CAICOS (DRM 2.50.0 / 5.3.18-lp152.41-default LLVM 9.0.1)
  v: 3.3 Mesa 19.3.4 compat-v: 3.1 direct render: Yes
Info:...Shell: Bash v: 4.4.23 running-in: konsole **inxi: 3.3.04**

It may or may not be very useful until rebooting without nomodeset.

Note I have plymouth not installed. It’s (weakly) possible you have plymouth interfering somehow. Try plymouth=0 or plymouth.enable=0 on Grub’s kernel command line to see if it matters or not.

4

Thanks for the suggestions. Here are my results so far.

This does not get a login prompt on this machine.

Are your new displays greater than 1920x1200 resolution?

The displays are 1920x1080. I’ve removed the cable from one to simplify things.

Does /etc/X11/xorg.conf exist? If yes, remove or rename it and restart without using nomodeset.

I renamed xorg.conf and restarted without using nomodeset and the login still hangs.

Are there any *.conf files in /etc/X11/xorg.conf.d/ containing uncommented lines including the Sections: Device, Monitor or Screen? If yes, remove/rename them and restart without using nomodeset.

I’m trying one thing at a time from this list with a restart in between. I’ll report the results.

5

I completed all of the previous suggested steps and there doesn’t seem to be any impact, however I have been able to get it where it will boot properly, one time. After one successful boot and shutdown, the system starts hanging. I’ll provide the results of the rest of the the originally suggested steps first though.

After renaming my existing xorg.conf.d directory and getting a successful boot without using nomodeset, the newly created xorg.conf.d directory only has the following file in it:

00-keyboard.conf

I executed the following code:

sudo zypper rm xf86-video-ati

and inxi -U to upgrade the inxi and now have the following output

  
inxi -GISay
System:
Host: Spitfire Kernel: 5.3.18-56-default x86_64 bits: 64 compiler: gcc 
  v: 7.5.0 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.3.18-56-default 
  root=UUID=b41a20ae-a631-4f44-a133-1df2dd988542 
  resume=/dev/disk/by-uuid/ata-ST31500341AS_9VS4RXE0-part6 showopts apm=off 
  acpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux 
  psmouse.proto=bare irqpoll pci=nommconf splash=silent 
  resume=/dev/disk/by-uuid/32042ace-a54c-4490-a11c-4d4f8175559d 
  mitigations=auto quiet 
  Desktop: KDE Plasma 5.18.6 tk: Qt 5.12.7 wm: kwin_x11 vt: 7 dm: SDDM 
  Distro: openSUSE Leap 15.3 
Graphics:
  Device-1: AMD Barts XT [Radeon HD 6870] vendor: ASUSTeK driver: radeon 
  v: kernel bus-ID: 01:00.0 chip-ID: 1002:6738 class-ID: 0300 
  Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: 
  loaded: modesetting unloaded: fbdev,vesa alternate: ati display-ID: :0 
  screens: 1 
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") 
  s-diag: 582mm (22.9") 
  Monitor-1: DP-1 res: 1920x1080 hz: 60 dpi: 82 size: 598x336mm (23.5x13.2") 
  diag: 686mm (27") 
  OpenGL: renderer: AMD BARTS (DRM 2.50.0 / 5.3.18-56-default LLVM 11.0.1) 
  v: 3.3 Mesa 20.2.4 compat-v: 3.1 direct render: Yes 
Info:
  Processes: 227 Uptime: N/A wakeups: 0 Memory: 7.76 GiB 
  used: 1.54 GiB (19.8%) Init: systemd v: 246 runlevel: 5 
  target: graphical.target tool: systemctl Compilers: gcc: 7.5.0 alt: 7 
  Packages: rpm: 3297 lib: 1478 flatpak: 0 Shell: Bash v: 4.4.23 
  running-in: konsole inxi: 3.3.04

A reboot at this point did not produce a successful boot.

I also tried setting plymouth=0 and plymouth.enable=0 as kernel options with no effect.

Here’s the interesting thing… I am repeatably able to get a single successful boot by doing the following:

After using “nomodeset” option to boot, I log in and I edit my grub file, (rename the old file so I revert back to it later) located in /etc/default/ by deleteing everyting in GRUB_CMDLINE_LINUX_DEFAULT and making it look like the following:

GRUB_CMDLINE_LINUX_DEFAULT="radeon.modeset=0"

I update the grub cfg file by:

grub2-mkconfig -o /boot/grub2/grub.cfg

On reboot, the system will boot successfully into terminal mode. From the terminal, I go back and restore my grub file to it’s previous version, update the grub cfg and reboot the machine. During the reboot, the machine will get to the grub screen and it will try to load Leap, but the system reboots on it’s own. On this second boot, the system will boot correctly.

I have been able to duplicate this method to get past whatever is causing it to hang. Does the new output from inxi provide any additional clues to anyone? Does this workaround I’ve described point to anything else to look try?

6

Indeed, everything I’ve bolded, except the italicized, is a workaround for something or other. It’s somehow been captured from a failsafe stanza into the default stanza. It doesn’t belong there.

Next up, at the Grub menu, strike the E key, remove everything I have bolded before proceeding to boot, and report back the result. Optionally, append plymouth=0, to ensure maximum boot messages.

Removing also splash=silent and quiet should produce more startup messages than you’re used to, any of which might be helpful. Showopts is a pointless holdover from Grub Legacy and Gfxboot that is inapplicable to Grub2. I always replace resume=yada with no resume, since I either shut it down, or use it. It’s simply not appropriate in a multiboot environment, as I always am. If you never resume, its just so much more cmdline bloat.

7

Focus on KISS:

**erlangen:~ #** grep CMDLINE /etc/default/grub 
GRUB_**CMDLINE**_LINUX_DEFAULT="splash=silent mitigations=auto quiet" 
GRUB_**CMDLINE**_LINUX="" 
**erlangen:~ #**

Graphics works out of the box:

**erlangen:~ #** inxi -zaG 
**Graphics:  Device-1:** AMD Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] **vendor:** Sapphire Limited **driver:** amdgpu  
           **v:** kernel **bus-ID:** 01:00.0 **chip-ID:** 1002:699f **class-ID:** 0300  
           **Display:****server:** X.Org 1.20.11 **compositor:** kwin_x11 **driver:****loaded:** amdgpu,ati **unloaded:** fbdev,modesetting,vesa  
           **display-ID:** :0 **screens:** 1  
           **Screen-1:** 0 **s-res:** 3840x2160 **s-dpi:** 144 **s-size:** 677x381mm (26.7x15.0") **s-diag:** 777mm (30.6")  
           **Monitor-1:** HDMI-A-0 **res:** 3840x2160 **hz:** 60 **dpi:** 154 **size:** 632x360mm (24.9x14.2") **diag:** 727mm (28.6")  
           **OpenGL:****renderer:** Radeon RX550/550 Series (POLARIS12 DRM 3.40.0 5.12.0-1-default LLVM 12.0.0) **v:** 4.6 Mesa 21.0.2  
           **direct render:** Yes  
**erlangen:~ #**
8

Combining the suggestions from mrmazda and karlmistelberger, at the Grub menu I selected E and was able to remove all of the extraneous kernel options. I did add plymouth=0 for good measure.

I did see a great deal of boot messages go across the screen, but the computer still hangs part way through the boot sequence. I saw a lot of green “OK” messages, but I didn’t see any failed. Perhaps I missed it though, the stuff is moving pretty quick across the screen. I rebooted the machine, using nomodeset and modified my grub default line to the following to keep it simple.

GRUB_CMDLINE_LINUX_DEFAULT="noresume"

This did not appear to have any effect.

I will show my ignorance with my next sentence… Where are the messages that are output to the screen stored? Are they stored for more than one boot cycle? I’m vaguely familiar with the log files stored in /var/log but I’m not sure the messages on the screen are stored there and their persistence. For example with the messages from a failed boot cycle still be stored when I use nomodeset to logon and then read those messages?

9

journalctl is a powerful utility: https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-journalctl.html#sec-journalctl-switches You may pipe its output to susepaste (see man susepaste):

journalctl -b | susepaste
10

It only takes effect when the grub menu is reconstructed from a kernel addition or removal, or by any competent running of grub2-mkconfig.

Where are the messages that are output to the screen stored? Are they stored for more than one boot cycle? I’m vaguely familiar with the log files stored in /var/log but I’m not sure the messages on the screen are stored there and their persistence. For example with the messages from a failed boot cycle still be stored when I use nomodeset to logon and then read those messages?
If a persistent log is enabled, then messages from a previous boot can be later accessed. e.g.:

sudo journalctl -b -1 | susepaste

will upload the whole journal from the previous boot to susepaste.org for perusal by others, once you reply here with the URL resulting from the susepaste command. To enable persistent journal, which is not an installation default, I’ve had no luck other than by creating directory /var/log/journal/, then rebooting. What command line options you add, remove or modify have no effect on logging. Whether all boot messages show up in the journal I can’t say. When I grep it for OK, only 4 MIT-MAGIC-COOKIE-1 lines result.

11

Hey guys, I appreciate the help. Here’s the report of my results.

I logged into my the machine using “nomodeset” as a kernel option and I was able to set the journalctl to be persistent, using the information in the documentation provided in the link. I edited the /etc/systemd/journald.conf file, by uncommenting the storage line and set it equal to persistent.

Storage=persistent

I saved the file and restarted the systemd-journald:

systemctl restart systemd-journald

I shut down the machine (20:59 noted below) and waited for about 10 minutes (~21:10) so that the log file would have a recognizable time stamp. The machine did hang in the boot process (of course >:(). I held the power button on the computer until the machine shut down. I waited another 10 minutes and started the machine, this time using nomodeset.

To list all of the available boots I executed the following code:

sudo journalctl --list-boots

Which output:

Spitfire:/var/log # journalctl --list-boots
-1 0a495fdab55340d1a10e9f2379b73d2a Sun 2021-05-02 13:03:05 PDT—Sun 2021-05-02 20:59:27 PDT
 0 e69f32a3540848f5a148aae40f55584d Sun 2021-05-02 **14:21:28** PDT—Sun 2021-05-02 **21:32:32 **PDT

Based on the timing of my the booting, I would have expected an entry at about 21:10 PDT, but there is nothing. Would that be normal for a boot that hangs?

Also, the timing on the boot entry is really weird. The file starts at 14:21, when it should have been 21:21. Maybe that’s nothing, but I know computers can be sensitive to timing so i wanted to point that out in case that raises any alarm bells.

12

I am not sure what “–list-boots” is doing, does is maybe only list successful boots?

Good idea to have some time between powering down and powering up but I would just have a look in the log.
Time is normally synced using NTP, so if you see strange “jumps” it can be that your internal clocks that is running while power down is off.

13

You’re in time zone -0700. That’s 7 hours, same as difference between 21 and 14. Is your BIOS clock set to local time?

14

I’ve been reflecting on the fact that I had a system that was operating normally and then one day it quit booting. At first thought I assumed software was the issue since I may have updated something and it caused issues. I’ve began thinking though that maybe I was having a hardware issue. Fast forward to this morning…

I booted my machine this morning and it booted normal… with no intervention. I wasn’t expecting that so I was caught off guard. I did a restart and I ended up with a black screen and no response… so that tells me that it is not likely software if you can go from working to not working. At least that’s my theory.

I opened up my computer case to make sure all the fans were working and all seemed to be in order. There was nothing obviously wrong so I decided to pull the video card out and then reinstall it. It never hurts right?

I only connected one monitor and started the computer and it booted normally!.. Success, well maybe… I figured I had better give that several more tries to make sure it wasn’t a one off event. I was able to boot normally, several more times.

I connected the second monitor and rebooted… BAM… it booted normally rotfl! I have successfully rebooted a number of times and each time it booted normally. I’m not going to say I didn’t need some tuneup in my configuration, because I have received several pointers about issues with the config of my machine. It is nice to have help getting things tuned up.

I seem to be back in business with a working machine after re-seating the card.

I’m grateful for the many folks who spend time on the forums and are able to help troubleshoot issues.