Forum Replies Created
October 9, 2021 at 7:07 pm in reply to: dnf offers i586 packages to upgrade my x86-64 system #29036
the problem was indeed caused by a lockup of the tool which refreshes repository metadata and should be fixed now.October 9, 2021 at 3:34 pm in reply to: dnf offers i586 packages to upgrade my x86-64 system #29032
this is usually caused by the
dnfupdates manager which is unable to find an upgrade solution with x86_64 packages and also because I think
dnfhas some issues with bi-arch support since Fedora abandoned the x86 target.
If you can post the full output of the command
sudo dnf updateI think we may find and indication of the root cause of the problem and fix it.
Another viable solution is disabling the
x86repositories by setting
enabled = 0in the file
x86repository is needed on
x86_64only 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 7 months, 2 weeks ago by Silvan.
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.
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/kwinrcwhich would cause the window manager process
kwin_x11to run at 100% CPU and block the desktop startup. This only happens the first time a user logs in, because thereafter the file
kwinrcis read from the local home directory. So the fix for this is in the
desktop-base-kdeupdate 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
glibcupdate to the
/usrflat 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-livecdthat have been made available between yesterday and today with the more recent kernel and everything fixed from my point of view.
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
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.
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?
nomodesetis 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 splasharguments (and maybe also adding
debugbut 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
startxcommand, as I told there is not interest in booting with
nomodesetbecause 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.
The instructions given are quick guidelines needing interpretation, as you did.
For the download URL, my mistake, the URL needs to start
Ok that you identified as
/dev/sda2and mounted the rootfs partition.
glibcrecovery 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
glibcbroke 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
There are currently two different problems I would put the attention on:
glibcupgrade with migration from
/usr/lib64causes severe problems if it fails (i.e. the system is unbootable, and the kernel panics altough it’s not kernel’s fault);
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
sddmupgrade which I’m testing and suggest to try to apply first (please note that I mean
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
glibcupgrade problem is bypassed, but the
sddmissue remains to fix.
this means that the
glibc-2.34-4mambaupgrade, which would make /lib a symlink to
/usr/lib, was a failure. The linux loader
/lib64/ld-linux-x86-64.so.2would 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.
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
calamaresinstaller 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
ddinto a pendrive and which can be booted in UEFI, but I don’t think so.
For this reason there is the openmamba
diskimgdownload, 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…
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 8 months, 3 weeks ago by 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.
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/systemdsymlink 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.
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 filesystemin rolling updates modes and the issue here (specially when using a former livecd version) could be that a
/lib/systemdsymlink 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.
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
hetzner3.openmambaorg, e.g. the current livecd URL would be:
The default download is from Italy, the alternative URL is from Germany, so there might be differences in download speed from your location.