I’ve tried booting the read-only images, but the problem is, even when there are 8 of them, like pre zypper, post zypper, none of those are bootable, and the system doesn’t just keep bootable snapshots. I had trouble getting running the install/boot usb, because the system would hang and I would have to power off the system by holding down the power button, because ctrl-alt-del wouldn’t work. I opened a ticket on bugzilla, and got the advice to use “nomodeset”, which I put at the end of the linux line, and then it booted into the graphical user interface. When I then updated my system using that installer, it replaced my snapshots with other ones. And none of those are bootable. When I booted my system after the upgrade, I got a lot of “DEPEND” errors during boot, and boot broke, and I was asked to login and fix the system. When I put “nomodeset” at the end of the linux line, I didin’t get “DEPEND” errors, but the system gets stuck on something like the postfix mail transport system with no more error messages, just waiting and waiting, and boot never finishes.
Sometimes when there are boot errors it looks like boot hasn’t finished, and sometimes it hasn’t, completely into an expected GUI. Sometimes, if you strike Alt-F3 or Alt-F4 or various other Alt-Fs you may find shell login prompts. If you do, that means you have a booted system, just one without a working GUI, and with errors to be found and corrected.
ok, I can press those alt combinations… but what can I do to get an actual working system?
If there are shell prompts there, you can login as root, and peruse logs to hunt down the failures and try to fix them. To view logs that don’t have built-in viewers, I recommend you zypper in mc, if zypper isn’t broken, and use mc for file manager-type navigation, and the viewer built into it for log viewing. Does /var/log/Xorg.0.log exist and contain lines with (EE)? If yes, share them via susepaste /var/log/Xorg.0.log and paste here the resulting URL. In /var/log/, is there a file gdm.log, sddm.log or lightdm.log? If yes, to use see clues in them? You can scan the journal for errors with journalctl -b, or pipe to susepaste thus journalctl -b -p3 | susepaste -e "10080" or journalctl -b | grep -E 'error|aile' | susepaste -e "10080" for selected subsets of the entire journal, or the whole thing journalctl -b | susepaste -e "10080". Instead of susepasting, you can redirect to a file: journalctl -b > somefile.txt for transfer elsewhere for convenient viewing and/or copy and paste. Susepaste can be used with dmesg as well: dmesg | grep -E 'aile|drm might be enough to turn up needed clues to susepaste or redirect to a file.
If an upgrade failed to finish, it might be enough to run zypper ref && zypper dup to finish it.
Someone else will have to chime in about trying to get a snapshot to work. I don’t use BTRFS or snapshotting.
Press Ctrl-Alt-F1 and log in.
Ok, I was going to say that alt-f2 etc just clears the screen and alt-f1 brings back the text. I do have it written down on paper what the output was for journalctl -B > yabba.txt. But it said that the file is corrupted, so it couldn’t output it.
But after I log in, I’m not sure what to do next. When I type “gnome” at the > prompt, it doesn’t execute but gives me an error message.
What error message is displayed? Also which openSUSE are you using (Tumbleweed or LEAP) or another?
This should be resolved in order to see the errors. Try without uppercase Buse lowercase b instead.
oh I did use lowercase b, but I wrote a big one here by accident.
I’m using tumbleweed. It says some message with “trap” in it when I try to run gnome with the command “gnome”. But I will give you more details shortly.
Trap means a program crashed.
If you can only login on vtt1, with only black screens elsewhere, then you won’t have any networking to facilitate troubleshooting or repair. But, shell command output can be redirected to a file on a USB to share from somewhere else.
Ctrl-Alt-F1 doesn’t do anything that I can see.
It doesn’t open up a login screen or anything like that.
I see [OK] started WPA Supplicant daemon
T1898 NET: Registered PF_PACKET protocol family
T68 BTRFS info (device dm-0): group scan completed (inconsistency flag cleared)
and this is on an external hard drive, and then the light stays on constantly for a long time, no flashing.
This is when I boot with nomodeset not there. Would it help if I booted in recovery mode? I can try also booting with nomodeset in there and see if there any other results.
Also when I type in “zypper in mc”, it says mc is not installed, and I don’t have internet connected. But even if I did have it, normally, the web browser would open and I’d have to accept the terms of internet usage in a public place. I know there’s a way I can do that through text.
Ok so this time I used nomodeset, and still ctrl-alt-f1 doesn’t do anything that I can see. I see:
[OK] Reached target Timer Units
Starting Postfix Mail Transport Agent
and then waiting, waiting, ctrl-alt-f1, nothing happening, light not blinking on my external hard drive…
I guess I could try downloading a later openSUSE Tumbleweed upgrade system and see if that helps anything, even though it’s only been 2 days. Or, go into recovery mode? At least in recovery mode, I can log in, and it’s using that mode that I can log in using my user account, which is successful, and then type “gnome” without the quotation marks and it gives me that trap message.
@as-muncher Does this command above have a positive effect or not?
So I boot into rescue mode, gives me password prompt, logged in as root, entered “gnome”, and the result is:
** (gnome-session:2044): ERROR **: 20:04:52.020: XDG_SESSION_TYPE= is unset!
[2461.807221][T2044] traps: gnome-session[2044] trap int3 ip:7fe128b535ab sp:7ffdcbcfb310 error:0 in libglib-2.0.so.0.8600.1 [6b5ab, 7fe128b0b000+a0000]
Trace/breakpoint trap (core dumped) gnome
When I tried journalctl -b > yabba.txt, the result is:
Journal file /var/log/journal/78947531984145909e695c41c42523fa/system@000641a0b3d96f4e-8f8abd7faeaf60dajournal~ is truncated, ignoring file.
So I can’t upload a journal file to pastebin
When I type “more Xorg.0.log” when I’m in the /var/log directory, I see in the file these 4 EE lines scattered, in this order:
(EE) Failed to load module “intel” (module does not exist, 0)
(EE) Failed to load module “nvidia” (module does not exist, 0)
(EE) Failed to load module “nouveau” (module does not exist, 0)
(EE) Filed to load module “nv” (module does not exist, 0)
When I entered the command “shutdown” at root, it shows me the localhost login information but does not shut down the computer even after a long time waiting
I will try zypper ref && zypper dup to see if I can finish upgrading the system, and still have to figure out how to do, by text, get through the web page prompting me to accept terms of internet usage
Ok, at the root prompt during bootup, I ran startx, and it allowed me to boot into KDE no problem, but I didn’t want to run as root, so I logged out, and logged in as a regular user, and tried running startx, but said the system is still booting, that I unprivileged users weren’t allowed to login yet, so I ran “init 5”, and there was some text output, and then I ran startx, and got into KDE. I logged out, logged back in as regular user, ran “gnome”, and still got that trap message, so I ran startx again, opened up my web browser, accepted terms of internet usage, and am running zypper right now. I will let you know if there are further problems. I think I will install lynx right now in case I need to access the web by text only.
So far, booting the recovery mode, running init 5, then startx is the only way I can get to a running operating system right now. I don’t know the commands for running xfce, so I’m not sure if that works. If I enter icewm at the command line, it spits out some error message that I haven’t set $DISPLAY or something like that, so that doesn’t run. But I did get a systemd-journal dump when I tried to boot regularly. I guess I’ll have to open a ticket in bugzilla? Every time I try to boot normally, the system just seems to hang - I don’t get a crash every time.
Does this happen with KDE? It sounds very promising, are you able to get into KDE then open an instance of Konsole and pass inxi -GSaz ? Then it may be easier to get video card sorted out allowing for correct boot process.
I am not sure about this but it is a problem of sorts.
It appears that there is some sort of module problem. Perhaps there is no module for graphics being loaded at all?
You are able to get a working internet connection I believe now so. I am going out on a limb here a bit so to say but these following notes may be of help with the module issue:
Explicitly include `nouveau` or remove `nvidia` modules from `initramfs`:
To exclude nvidia (so kernel boots without nvidia modules loaded early):
dracut --omit-drivers "nvidia nvidia_modeset nvidia_uvm nvidia_drm" --force
To include nouveau:
dracut --add-drivers "nouveau" --force
Purge all proprietary drivers and test nouveau or vesa
From chroot or working boot:
zypper rm -u '*nvidia*' '*NVIDIA*'
zypper in xf86-video-nouveau xf86-video-vesa
dracut --force
Was the zypper ref && zypper dup able to complete successfully?
Gnome cannot be started until X11 or Wayland has first been started, normally done via a file in /usr/share/xsessions/ for X11 sessions, or somewhere else for Wayland sessions.
This suggests the journaling system may be broken, or /var/ is located on a readonly filesystem. If you have functional networking, then you can upload it thus: journalctl -b | susepaste -e "10080" and share here the resulting URL.
Without knowing your GPU, a thorough response to this is tough, but basically X is trying to load 4 optional drivers, the last of which has been useless and obsolete for at least 15 years. If you have an AMD GPU, none would ever have been applicable. The nvidia module is not part of openSUSE, a proprietary optional driver. The intel is mainly for ancient GPUs that the preferred newer driver does not support. Nouveau is an “experimental”, reverse-engineered, optional driver for those who don’t use nvidia for their NVidia GPUs and for whatever reason use it instead of the preferred newer default modesetting driver. Absence of any more (EE) lines following the last above would tend to suggest X is not where your problem lies. If there are others you held back, they are what we need to see, but really the whole file.
shutdown is a symlink to /usr/bin/system, so better to use systemctl directly, and possibly get a more informative response. systemctl reboot is the official reboot command, and systemctl poweroff is for shutting down.
WINDOWMANAGER=/usr/bin/icewm startx is the command to start IceWM from a shell login prompt, which I keep in file /usr/local/bin/startice. Similar syntax works for KDE3 using startkde, and IIRC for Plasma 5 using startplasma-x11 or startplasma5, so similar may work for Plasma 6, and possibly even for Gnome.
What’s really needed is log showing why your DM won’t start. journalctl -b -p3 may provide a clue, or journalctl -b | grep gdm (or whichever dm is actually installed and enabled). update-alternatives --config default-displaymanager should show which are installed and which is enabled. If it’s kernel module related, then dmesg | grep drm output should be clueful.
Wow, so many great responses, pretty thorough. I would be willing to post all that you want, but I did find a working solution, after looking at: 1252311 – GDM and Gnome can not launch after upgrading from version 20250919
Comment 11 by [xiaoguang wang] helped me out:
Try this workaround [1250513 – [Build 20250924] Upgrades from 15.x seem to get the config for gdm / dynamic user generation wrong], Dominique Leuenberger giving a simple solution of deleting /etc/nsswitch.conf. Deleting that and rebooting got gdm working and gnome loading, even though systemd-journal still crashed and outputted a dump to the console. I should mention that I did, with difficulty, find the KDE Tumblweed live iso, wrote that to USB using DD mode, booted off of that, but there wasn’t any program that I could see in the menu that has an option of checking my offline system for bad sectors. I still have a bunch of .zst files for crashes for systemd-journal, gnome, and a bunch of other ones.