Hi Douglas,
The instructions given are quick guidelines needing interpretation, as you did.

For the download URL, my mistake, the URL needs to start http instead of https.

Ok that you identified as /dev/sda2 and mounted the rootfs partition.

Next, the glibc recovery procedure (using rpm -r .. where -r is the option to specify the target rootfs path) was needed because I've assumed that during the upgrade in the previous post glibc broke and so all the system broke. This indeed is contradictory with the fact that you have been able to chroot to that rootfs with success and without fixing glibc before.

There are currently two different problems I would put the attention on:

1) glibc upgrade with migration from /lib64 to /usr/lib64 causes severe problems if it fails (i.e. the system is unbootable, and the kernel panics altough it's not kernel's fault);

2) sddm, the KDE Plasma login manager, fails to start the graphical desktop. This is the situation where the system enters graphical mode, you have the mouse pointer available on screen, but you get no more than a black screen. You can btw switch to a console by pressing CTRL-ALT-F2.

My previous post was about fixing the issue 1), it explains the guidelines for a "almost disaster" recovery procedure and is intended to be performed by a quite expert and conscious user. I'm not sure any longer that this applies to your last situation reported.

For the issue 2) I haven't found a certain solution yet. There is a sddm upgrade which I'm testing and suggest to try to apply first (please note that I mean sddm, not sddm-kcm), while a workaround seems to be removing the file .Xauthority for user home and restart sddm:

rm -f ~/.Xauthority
systemctl restart sddm

By using the most recent livecd ISO the glibc upgrade problem is bypassed, but the sddm issue remains to fix.

Silvan,
Thank you for your continued attention and patience, I will try and implement your suggestions today.

Douglas

Silvan,
Good day...So I was able to boot normally from my initial install and I ran update, (sudo dnf update), from command line and it completed and installed appropriately.
Upon reboot though, and I had to add nomodeset to the linux loader line, the boot up process would not complete. I would never see the black desktop and mouse pointer, like you mentioned.
Thinking the issue was with SDDM like you mentioned, I switched to tty2 and ran, "systemctl stop SDDM" and then, "systemctl disable SDDM".
Upon reboot, the boot process completed by going to a login prompt. So it seemed SDDM was failing and stopping the boot process.
I tried running startx from command line and just received the following:
"[KMS} drm report modesetting isn't supported"
"xinit: unable to connect to X server: Connection refused".

I assume the modesetting error is from my adding nomodeset to the kernel load line.
Is it possible to use lightdm instead of SDDM?

Douglas

Hi Douglas,
you say you could install the system and it was working until you did a system upgrade and reboot. So what ISO release did you install from, in order for me to limit which are the updates that caused the problem?

The nomodeset is an argument that is only used to support non-KMS drivers, like NVIDIA proprietary drivers (well, to be correct this is also not true anymore with recent drivers). In this case you use it as a workaround to get to a console but the system is not expected to start correctly in graphical mode with this option (it should with fb or vesa drivers but maybe not on UEFI btw we are not interested in starting the system with this option). So if the kernel fails to boot in default mode it should be started without the quiet splash arguments (and maybe also adding debug but this may cause excessive flooding of messages) and what appears on screen when it stops (a screenshot?) could be useful for debugging.

As for the startx command, as I told there is not interest in booting with nomodeset because the desktop is not expected to work correctly at all with standard video drivers.

Of course you can try to install other login managers but openmamba is designed to work (and did for years) with SDDM like any other KDE Plasma based distribution. BTW there is no lightdm package in openmamba, there is lxdm (which is used by openmamba-light flavour with LXQt).

As yours and other reports suggest I will try to package a kernel update, although I have three systems correctly running with this kernel (with Intel and AMD gpus) so I think the problem is elsewhere.

Silvan,

I used the openmamba-diskimg-livecd-en-snapshot-20210630.x86_64.img
And I used gnome-disks to restore the image to an 8gb usb stick. It would then boot up efi.
As the attachment shows, boot stops with the line at the bottom, when I removed quiet and splash from the linux load line.
If I remove quiet and add nomodeset, then it boots to a prompt.
(If you remember, I disabled SDDM with the systemctl disable SDDM command).
I have configured and compiled new kernels on other distros...is that an option with openmamba, or is it hardcoded by you?

Douglas