[Silvan]

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]

Hi Douglas,
this means that the glibc-2.34-4mamba upgrade, which would make /lib[64] a symlink to /usr/lib[64], was a failure. The linux loader /lib64/ld-linux-x86-64.so.2 would disappear and no executable can be run, it is not a problem with the kernel, which will panic because it won’t be able to run /sbin/init after switching to the rootfs.

The fix is to either start from the most recent ISO livecd image or do a manual recovery by booting a live system and perform a series of terminal command such as:

wget https://cdn.openmamba.org/pub/openmamba/devel/RPMS.x86_64/glibc-2.34-4mamba.x86_64.rpm
sudo su
mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1
mount -o bind /dev /mnt/sda1/dev
mount -o bind /proc /mnt/sda1/proc
mount -o bind /sys /mnt/sda1/sys
rpm -r /mnt/sda1 -u glibc-2.34-4mamba.x86_64.rpm
chroot /mnt/sda1
dnf update

This would fix the main issue although repairing of any of the packages which were part of the upgrade may be needed as well.

• This reply was modified 2 years, 7 months ago by Silvan.
• This reply was modified 2 years, 7 months ago by Silvan.

[Silvan]

Hi Douglas,
I’m glad that you could boot openmamba ISO and install it in CSM mode.

You could now try to create a USB pendrive from a ISO using the provided openmamba tool you find in the start menu by typing USB, then ideally boot in EFI mode from this pendrive and install (the calamares installer supports EFI boot).

My doubt is if it is possible (and whether other distribution do) to distribute a ISO image which you can write with dd into a pendrive and which can be booted in UEFI, but I don’t think so.

For this reason there is the openmamba diskimg download, an image that you already tried which contains the EFI ESP partition and should boot. But I think that in EFI boot mode there might be, as previously noticed, KMS video driver problems that should be investigated further…

[Silvan]

Hi Douglas,
by looking at the report you sent it seems that Xorg is unable to start because the kernel is started with the “nomodeset” option, so it would skip AMD/ATI drivers and try VESA/Framebuffer modes which fail too probably because VESA/Framebuffer modes are not available too. So for this part of the problem I would suggest to boot without the “nomodeset” option, then if you are able to access a console a report in this situation would be more interesting to see. If you can’t get to a console the boot could be blocking with some relevant message on screen instead (assuming that you are not booting with the bootsplash enabled, so without the ‘quiet splash’ kernel command line arguments.

Using the diskimg is a good idea to perform a EFI boot. The bootx64.efi from grub 2.04 has been the same for a long time and it works where I have tested it, BTW I’m working on Grub 2.06 update. The boot file has just to be inside a FAT partition and the PC has to be configured to support boot from the external device (i.e. things like secure boot need to be disabled). BTW I recently had a similar problem on a x86_64 tablet where bootx64.efi is no longer detected so I will be able to further investigate on this problem.

• This reply was modified 2 years, 7 months ago by Silvan.

[Silvan]

According to another report received today I’m not sure that the lastest ISOs will fix the problem and I will do better checks for this problem in the next days.

openmamba provides a standard system layout and libraries so installing third-party distributed applications like Chrome and Slack should not be a problem. Should you have any dubt or problem you can of course open a specific topic in this forum.

[Silvan]

Hi,
thanks for reporting the issue with much detail.

I will check for adding a UEFI boot option to the live ISOs in the next days. Currently you may create a UEFI bootable pendrive by using the “Install openmamba on USB” tool but of course you need to have a working openmamba desktop installation to be able to run this tool.

As for the SDDM startup error, recently this issue was caused by a missing /lib/systemd symlink pointing to /usr/lib/systemd, you may want to check if the link is missing and if so creating the symlink should fix the problem. I thought the problem would be fixed with the latest ISOs but I will check and eventually do a fix for this problem.

[Silvan]

I’m sorry it didn’t work.
When I can get the necessary information I always try to find a solution.
The distribution is undergoing the migration to the flat /usr filesystem in rolling updates modes and the issue here (specially when using a former livecd version) could be that a /lib/systemd symlink is missing, this in short can be fixed by logging into a console (CTRL-ALT-F2) and entering the command:
sudo ln -s ../usr/lib/systemd /lib/systemd.

[Silvan]

Hi, from our server side networking seems good but there may be issues due to international routing.

You may want to try changing the download URL from cdn.openmamba.org to hetzner3.openmambaorg, e.g. the current livecd URL would be:
http://hetzner3.openmamba.org/pub/openmamba/media/devel/livecd/en/openmamba-livecd-en-snapshot-20210828.x86_64.iso

The default download is from Italy, the alternative URL is from Germany, so there might be differences in download speed from your location.

[Silvan]

Hi ouaille_aime_scier,

you can set kernel command line options at the boot menu, if I remember correctly by pressing [TAB], but I don’t know if the option you want to add will be sufficient to boot with AMD instead of NVidia.

I’ve found this upstream issue for your card with Nouveau driver which suggests to use nouveau.config=NvChipset=0x167 instead. Btw this thread also says that this should be fixed since kernel 5.3+, so I’m not sure about what is happening considering that the current livecd ISO provides a 5.10 kernel. Please, make sure you are using the latest livecd ISO, not the livedvd because there have been fixes on the Mesa side for NVidia cards.

If you are able to boot the ISO (i.e. with the nomodeset boot option which should boot with VESA modes) and want to install it on your PC, then for optimal (but proprietary) driver support you may install the latest 465.31 driver with this command:
sudo dnf install xorg-drv-video-nvidia.

• This reply was modified 2 years, 10 months ago by Silvan.

[Silvan]

Hi Usuha,
sorry for the delay.

An update of ibus will be available in the next hours but this is probably an optional requirement to fix your issue.

The most important thing is that I noticed that ibus-daemon just needs to be started before the desktop session. To accomplish this you may want to try to create a file ~/.xprofile with the following content:

export QT_IM_MODULE=ibus
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
ibus-daemon -drx

Then you may remove the lines you added to .bashrc and reboot.

With this configuration I get a ibus tray icon on the bar where I can change the input method and this now seems to work in KDE Plasma applications.

• This reply was modified 3 years, 4 months ago by Silvan.

[Silvan]

Hi Rob.
Yes, the rolling release is maintained and for desktop usage provides the latest KDE Plasma release with a lot of software packages.
Please, feel free to try and see if you like it!

[Silvan]

Hi,
good, thanks for finding and sharing the solution to this problem.

[Silvan]

Hi,
for the sound card problem I’ve looked for the different solutions proposed on the web and wonder if you have tried this:

sudo su
echo "options snd-intel-dspcfg dsp_driver=1" > /etc/modprobe.d/snd_intel_dspcfg.conf

(then reboot).

About the french language, a method would have been to start by using the livedvd ISO image which provides support for french by selecting the language at boot.

Instead, switching language on a system installed from livecd requires some manual changes:

1) make sure that the system-wide LANG environment is set to french, this can be done by editing as root the file /etc/locale.conf and replace the existing line with:

LANG=fr_FR.UTF-8

2) install the french langpack:

sudo dnf install langpacks-fr

3) configure the rpm %install_langs macro in file /etc/rpm/macros.lang:

%_install_langs en:fr:fr_FR

4) packages need to be updated or reinstalled so that translation files for the languages specified in 3) will be kept on local installation

• This reply was modified 3 years, 5 months ago by Silvan.
• This reply was modified 3 years, 5 months ago by Silvan.

[Silvan]

Hi,
thanks for the information provided.

It seems that the NetworkManager package is missing in recent livecd ISOs.

If you are just running the live system I suggest waiting for a new release which I’m scheduling for tomorrow.

If you have the system installed the problem might be fixed by manually configuring networking and running sudo dnf install NetworkManager or manually downloading and installing the NetworkManager package and its dependencies using an external storage device, e.g. a USB pendrive. Feel free to ask more details if you need more details in this case.

[Silvan]

Hi,
can you please provide the output of the dmesg and/or openmamba-makereport commands from terminal?

`
dmesg > ~/Desktop/dmesg.txt
sudo openmamba-makereport
`

The generated files can be sent to us via Support -> Send a report or attached to a post in this thread.

[Author]

Posts