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?