[Silvan]

Hi,
thanks for reporting the issue providing details which hopefully helped to fix it.
I’ve updated to a more recent python version all the modules of the rpm/dnf/dnfdragora stack and finished the tests, so the fix will be soon made available with system updates.

[Silvan]

Hi,
I’ve looked into this problem and found that it can be solved if you can edit the file /etc/fstab and replace the option space_cache with space_cache=v2.
Thanks for reporting the problem, btrfs is not the default filesystem for rootfs so it hasn’t been tested for a while and an update of kernel or tools may have produced this problem. I will check and eventually fix the Calamares installer to prevent this issue from happen in the future live ISOs.

• This reply was modified 3 days, 17 hours ago by Silvan.

[Silvan]

Hi ouaille_aime_scier,

thanks for the feedback, I have just a final question: can you please tell me the exact model of your Nvidia equipment? If you don’t know, the output of the following command should provide this information:

lspci|grep -i nvidia

If the Nouveau driver is working fine I suspect that your Nvidia GPU is an old model supported by one of the Nvidia legacy drivers or else maybe it works because I recently disabled Nouveau acceleration support by default.

Thanks and good continuation with openmamba.

[Silvan]

Hi,
I’m going to retrieve one or two nvidia cards to do tests because it is not easy to make their current and legacy drivers to work, I’ve done this many times in the past 15-20 years but at some point something changes and meanwhile my only card got broken. Unfortunately Nvidia still gives poor support to packagers by only providing an autoinstalling script to be run by the user with root privileges.

By the way if you want to do a couple of further tests I suggest:

1) first let’s check if nvidia module is correctly available, such commands could confirm this:

sudo dkms status
sudo modprobe nvidia
dmesg | tail

2) create a file with path /etc/X11/xorg.conf.d/20-nvidia.conf with the following content:

Section "Files"
ModulePath   "/usr/lib64/nvidia/xorg"
ModulePath   "/usr/lib64/xorg/modules"
EndSection

Section "Device"
Identifier "Nvidia Card"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection

Section "ServerFlags"
Option "IgnoreABI" "1"
EndSection

and try a normal reboot.

3) try to boot selecting the second menu entry in the advanced submenu of the Grub boot loader (the option is described as “Proprietary video driver” and runs the kernel with nomodeset, which was the scenario with Nvidia drivers not supporting modesetting).

• This reply was modified 1 month, 1 week ago by Silvan.
• This reply was modified 1 month, 1 week ago by Silvan.

[Silvan]

Hi, if you still get errors related to nouveau you may need to recreate the initramfs with:
sudo mkinitrd -f

[Silvan]

Hi ouaille_aime_scier,

the nvidia.ko module from xorg-drv-video-nvidia is built and maintained by dkms for kernel updates.

The rpm also blacklists the nouveau driver providing the file /usr/lib/modprobe.d/nvidia.conf.

Unfortunately I don’t have a PC to test with nvidia as primary controller, so I’m not sure if it will work or require something else, like explicit module loading and a configuration fragment in /etc/X11/xorg.conf.d. Years ago nvidia driver needed to be run without “nomodeset”, current driver claims to support modesetting but this is a situation I could not test.

If you feel skilled enough to operate on the system even if you get black screen at boot you may want to test and in case of problems I can try to give you support to make it work for you and possibly future openmamba users. In case of black screen providing the content of the file /var/log/Xorg.0.log may help.

Thanks.

[Silvan]

Hi,
the problem was indeed caused by a lockup of the tool which refreshes repository metadata and should be fixed now.

[Silvan]

Hello,
this is usually caused by the dnf updates manager which is unable to find an upgrade solution with x86_64 packages and also because I think dnf has some issues with bi-arch support since Fedora abandoned the x86 target.

If you can post the full output of the command sudo dnf update I think we may find and indication of the root cause of the problem and fix it.

Another viable solution is disabling the x86 repositories by setting enabled = 0 in the file /etc/yum/repos.d/openmamba-rolling-i586.repo. Currently x86 repository is needed on x86_64 only if you use Wine for x86 or have other special needs and I might decide to disable it by default in future.

• This reply was modified 1 year, 5 months ago by Silvan.

[Silvan]

Hi Douglas,
I’m glad that you could finally have a working installation starting from the new downloadable image.
I can’t fully check the installation procedure every time new images are released and I did not receive any report before you so this was a problem that lasted for months and now I’m happy that it is resolved.
So thank you for your detailed reports and your patience.

[Silvan]

Hi Douglas,
thanks for reporting your attemps with openmamba.

Here are the news from my side: after deep research I identified the cause of Plasma Desktop not starting in the file /etc/xdg/kwinrc which would cause the window manager process kwin_x11 to run at 100% CPU and block the desktop startup. This only happens the first time a user logs in, because thereafter the file kwinrc is read from the local home directory. So the fix for this is in the desktop-base-kde update to version 5.0.

Other problems you may have after updating depend on the fact that you are starting from a three-months old live image and here the glibc update to the /usr flat filesystem is probably the cause of further problems, so I would suggest you to try the openmamba-diskimg-livecd (with EFI boot support) or openmamba-livecd that have been made available between yesterday and today with the more recent kernel and everything fixed from my point of view.

[Silvan]

Hi Douglas,
I’ve packaged a new kernel update which is under testing, if you want to test it against the problems you are having in your installation you may install it with the following command:

sudo dnf update kernel-mamba-x86_64 kernel-mamba-x86_64-headers --enablerepo=unstable-makedist

[Silvan]

Hi Douglas,
as you installed starting from a june snapshot you should still have the previous kernel installed (5.10.56) and available in the Grub advanced options submenu. Did you try that? According to other reports problems seems to happen since 5.10.57 update and this would explain why your system worked before updating.

The kernel is built from the kernel source rpm that you can find in the sources folder.

• This reply was modified 1 year, 6 months ago by Silvan.
• This reply was modified 1 year, 6 months ago by Silvan.

[Silvan]

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]

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 1 year, 6 months ago by Silvan.
• This reply was modified 1 year, 6 months ago by Silvan.

[Author]

Posts