Open Suse suddenly won't boot on a dual boot PC

Almost six months ago I installed Open Suse on my dual boot PC with windows already installed on a separate ssd drive. When I tried to startup my PC today it wouldn’t boot into Open Suse. I ran into a black screen with some ACPI error messages (see picture below). These kind of error messages show up every time I boot into Open Suse Leap 15 and wouldn’t do any harm according to another thread on these particular error messages on startup. However this time it wouldn’t boot up anymore; it just freezed at this screen. I can still boot into windows 10 though, which is installed on another harddrive. Last thing I remember doing is updating trough the terminal by typing

sudo zypper up

I have tried several options to get it to boot again. First I tried to update my HP computers BIOS. (I have had some issues with HP ‘Sure start’ before, hence the BIOS update) This only resulted into getting stuck into a sure start screen with the HP logo, instead of the error message screen I mentioned before. So I decided to revert back to the previous BIOS version. Then I managed to log in terminal mode and ran the update command again; OS wouldn’t boot!:frown: Finally, I tried to boot into Open Suse using an older kernel version. This alsoo didn’t solve the problem. If only somebody could solve this problem, I would be ever grateful for your support! https://forum.xda-developers.com/picture.php?albumid=14669&pictureid=58330

I meant this post, by the way. Any help or suggestion on getting my OS to boot up again would be most appreciated!

On the Ubuntu forums I found out that I am not the the only one not being able to boot into the the graphical user interface of a linux distribution. Actually someone encoutered the same problems as I had and managed to fix the problem, as so to speak from reading this post. I have tried to enter several boot parameters like: ‘acpi=off, acpi=strict and pci=noacpi’ which didn’t solve the problem yet, unfotunately. Interesting though is that I received some different acpi error messages for example in the last case:

    4.342388) 1801_smbus 9000:00:1f.4: SMBus base address uninitialized, upgrad 
e BIOS
    4.4083171 ACPI Error: Meeded (Buffer/String/Package), found [Integer) 000088884dd8d69a (28188818/exresop-568) 
[    4.408363) ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index) (28188818/dsuexec-477) 
[    4.408402) ACPI Error: Method parse/Execution failed SB.WMIV.WUPO, AE AML_OPERAND TYPE (28188818/psparse-516) 
[    4.408443) ACPI Error: Method parse/execution failed VSB.WMIV.WMPU, AE AML_OPERAND TYPE (28188818/psparse-516) 
[    4.4164061 ACPI Error: Needed [Buffer/String/Packagel, found [Integer) 008008d8a78ck3ec (28188818/exresop-568) 
[    4.416459) ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index) (28188818/dSLEXEC-427) 
[    4.416510) ACPI Error: Method parse/execution failed SB.WMIV.WUPO, AE AML_OPERAND TYPE (28188818/psparse-516) 
[    4.416559) ACPI Error: Method parse/execution failed SB.WMIV.WPU, AE AML OPERAND TYPE (28188818/psparse-516) 
[    4.418834) ACPI Error: Meeded (Buffer/String/Package), found [Integer) 000008886bd54571 (28186818/exesop-568) 
[    4.418889) ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (28189818/dsuexec-427) 
    4.418123) ACPI Error: Method parse/execution failed VSB.WMIV.WPO, AE_AML_OPERAND_TYPE (28188818/psparse-516) 
    4.4181761 ACPI Error: Method parse/execution failed VSB.WMIV.WMPU, AE AML_OPERAND_TYPE (28188818/psparse-516) 
    4.4875451 ACPI Error: Attempt to CreateField of length zero (28180818/dsopcode-134) 
    4.4875921 ACPI Error: Method parse/execution failed VSB.WMIV.WUPI, AE AML_OPERAND_VALUE (28188818/psparse-516) 
    4.4876471 ACPI Error: Method parse/execution failed VSB.WMIV.WMPU, AE AML_OPERAND_VALUE (28188818/psparse-516)

Also interesting is that I am still able to enter in the command line interface of OpenSuse Leap 15, sadly the GUI still will not be able to boot. I am hoping someone with superior insights, I haven’t got a clue yet, will be able to see what’s at play here and offer a possible solution.

Normally boot problems are video related. So Video card and driver please???

In fact you have booted, but your GUI is broken. As gogalthorp indicated, we need more information in order to help. At the login prompt, login as root and execute the following:

zypper in inxi susepaste; inxi -Gxx > inxiGoutput.txt; susepaste -n Median -e 10080 inxiGoutput.txt; susepaste -n Median -e 10080 /var/log/Xorg.0.log

and post the URLs given by susepaste.

The video card: Intel(R) HD Graphics 630.
The Windows 10 driver: Intel Graphics Driver RS3-15.60- 64 bit. Probably you’ll need to know the driver version of the OpenSuse Leap 15 installation. If I could be able to get it by typing a command in the terminal, would you let me know how, please?

inxi -Gxx would have done it.

Likely we already know because of the 630. In a terminal, do

zypper rm xf86-video-intel

then reboot and likely it will be fixed. This became a common problem in recent days.

The URLs are:
http://susepaste.org/60092251
http://paste.opensuse.org/60092251

Apparently there are multiple deficiencies in the old version of inxi in 15.0, e.g. including ansi codes in redirected output, and inability to reproduce all the expected information when not run from X. Nevertheless, I still believe my instruction to remove xf86-video-intel likely to be the ultimate solution.

A night and some time being busy passed by, then I tried to remove xf86-video-intel. It seems like it wasn’t there in the first place:

linux-nrgm:~ # zypper rm xf86-video-intel
loading repository data...
Warning: No repositories defined. Operating only with the installed resolvables.
Nothing can be installed.
Reading installed packages...
'xf86-video-intel' not found in package names. Trying capabilities.
No provider of 'xf86-video-intel' found.
Resolving package dependencies...

Nothing to do.

It started to dawn on me that the particular problem we’re talking about is that after doing an update I’m unable boot into the graphical display of the login screen. There is actually a topic on this subject in the official OpenSuse Leap 15 documentation. This suggests that there are either problems with the choice of the default systemd target or the configuration of the X Window System.

So I ran the command:

sudo systemctl get-default

It returned ‘graphical.target’, so this rules out the first problem. This leads me to the conclusion that the desktop or X Window software is probably misconfigured or corrupted (I would like to mention that I use Wayland as a window system). To figure out what’s causing the problem one should have to examine the output of:

journalctl

It’s a rather large logfile and would like to apeal to the expertise of an experienced linux user. I left a logfile in this pastebin.

Some hints:
Line 287 refers to a firmware bug, lines 1030-1043 refer to ERROR messages and line 1413 is also suspicious.

Again your insights and helpful comments would be greatly appreciated.

I’m not seeing anything obvious there.

Some hints:
Line 287 refers to a firmware bug, lines 1030-1043 refer to ERROR messages and line 1413 is also suspicious.

Much of that is ACPI messages. There are different kinds of ACPI support, and the kernel tries what it can to see what works. Those are some of the messy reports. But I don’t think they are a concern.

Line 1413 is a “assert” failure from “gdm”. Those are often for debugging. It does not seem to be a fatal error. After that, “gdm” goes on to report what appears to be successful start of a Wayland session.

That does not match what you are otherwise reporting, since you don’t seem to be getting a graphic session.

You appear to be set for auto-login. I’m wondering whether that is hiding evidence that we need. I suggest you turn off auto-login for the present.

You should be able (as root) to edit “/etc/sysconfig/displaymanager” and look for the line

DISPLAYMANAGER_AUTOLOGIN="user"

where that “user” would be you. Try deleting the user part, so that there are just empty quotes. Then reboot.

I’m interested in whether you then see the GDM login screen. And if you do see it, maybe you could try to login to “Icewm” and see if that works.

First off all, thank you for your support! I did, as you suggested, edit the displaymanager file and remove the user part. Then I rebooted and there was … unfortunately still no graphical login screen. Checked to see that the particular line from the displaymanager file was indeed changed to “”.

Made new journalctl file, it’s over here and discovered that there is indeed a case of a fatal ERROR in the lines 1512 - 1517.

Yes, you are right. It does look as if “gdm” is failing, and then being restarted.

Is “lightdm” available on your system. Maybe check with:

ls /usr/sbin/lightdm

If it is present, you might try switching to that. At a root command line:

update-alternatives --config default-displaymanager

If “lightdm” is not installed, you might try installing it, either with yast in a commandline session, or with

zypper install lightdm

And then see if you can login with lightdm.

That did the trick. There were actually 4 display managers to choose from, then selected lightdm, rebooted the system and the login screen was there.

Wow, you don’t know how glad I am to finally be able to login to the graphical interface again, thank you very much!

Guess that means that the GDM display manager is corrupted? Should I uninstall GDM and reinstall it again? Just wondering.

At this stage, there seem to be two possibilities.

1: GDM is, as you say corrupted.

2: Wayland is broken, at least on your hardware.

GDM runs under Wayland, and was starting your Gnome session under Wayland. But “lightdm” is running under X11, and is probably starting your Gnome session under X11. You can try:

echo $XDG_SESSION_TYPE

in a terminal to check if you are using X11 or Wayland.

I’m guessing that this is actually a Wayland problem. So I’ll suggest reporting it as a bug. You can use

openSUSE: Submitting bug reports

to report. Choose Gnome as to component against which you are filing the report. Provide a link to this forum post. And maybe attach those log reports that I looked at – or at least provide the pastebin links in the bug report, so that they don’t have to search through the thread to find them.

That’s interesting, it’s using X11 indeed! Thanks again and I’ll report the bug to link you provided.

Wow so there’s a fix for this, I hope I posted this first when I encountered this last month but fortunately this only happened on my test machine and I just reinstalled it. Might happened again so it’s better to know this in the first place.