[Silvan]

Hi,
the problem affects systems which have been updated between 1st and 2nd of July and should be fixed manually by issuing the following command from a terminal:

sudo rpm -U https://openmamba.org/pub/openmamba/base/RPMS.x86_64/librepo-1.18.0-1mamba.x86_64.rpm

• This reply was modified 5 months, 2 weeks ago by Silvan.

[Silvan]

Hi,
I’m very happy that you managed to solve the problem and appreciated openmamba in its live execution.

Here are the replies to your questions:

1) openmamba uses rpm packages and the low-level install/update manager is dnf. Both have been for years maintained as distribution indipendent projects and are used in Fedora and other distros. I know that there are sources reporting that it uses apt but this has changed over a decade ago 🙂

2) the recommended desktop experience with openmamba is with Plasma 6 desktop which offers discover to install and update packages. For the LXQt lightweight desktop alternative I’ve provided dnfdragora.

[Silvan]

Hello,
when I receive this kind of reports soon after autogenerated monthly live media are released I’m urged to check that there has not been a regression which would prevent any or most user to install openmamba in the way and on the targets it worked before. According to what I verified this is not the case and there does not seem to be such a general problem. I will write next what I’ve done for the interest of your specific case.

1) I’ve downloaded the currently available livecd ISO image (openmamba-livecd-en-snapshot-20240501.x86_64.iso)
2) yesterday I’ve run it in a VM using both libvirt (which emulates a BIOS but) and VirtualBox (configured to emulate EFI boot), in both case I was able to correctly boot the system
3) today I’ve prepared an USB pendrive using the dd command as per the instructions that are in the downloads page, i.e. with such a command issued from a Linux console:
sudo dd if=openmamba-livecd-en-snapshot-20240501.x86_64.iso of=/dev/sdx bs=32M
(as you say you have experience on Linux so I skip here details on preventing and checking that the procedure has not resulted into errors, which would be displayed on the console after the dd command).
4) I’ve booted the system from the pendrive on a laptop with EFI boot and all worked as expected: Grub menu appeared, the O.S. booted, the KDE Plasma desktop opened and the Calamares installation tool started.

Because you say that you tried the medium on three different PCs with same results, and because I have tested that there are no specific problem, my first guess would be that the USB pendrive + the ISO image written on it are causing the problem. Because you tried the 3 different ISOs (livecd, livedvd, livecd-light) probably it is not a download problem where an MD5 checksum check would be useful, so the other possibility would be that the pendrive has been not correctly prepared or produces read errors in the early boot of the system. Another guess it that you may have some settings on all PCs, like secure boot enabled and/or related settings, that might cause the difference from my results. Third guess, of course when you see the black screen with the messags you reported, you should wait for some tenth of seconds before decreeing that the system does not boot.

When everything suggested above fails, I would go for trying to get more detailed boot messages, you say you already tried to start with debug boot option in grub, evidently with no more useful messages displayed, maybe we might try to enable initramfs debug options, which I will search, if necessary, in a next replay.

Finally, yes, I am italian and openmamba is too. You may find an italian flag towards the top right corner of this page, by clicking there you will find this forum in italian language. If you manage to fix the problem, will have other questions about openmamba and like to write italian, you may want to write in the italian forum next time 🙂

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

[Silvan]

Hi,
I suppose you get these messages, then the live system won’t boot.

By doing a first search there are two recent posts discussing these boot messages:
https://forums.debian.net/viewtopic.php?p=792227
https://forums.gentoo.org/viewtopic-t-1167043-start-0.html

The appearance of these messages might be due to the combination of recent Kernel and Grub releases, but they might not be the real cause of the kernel not booting.

If this is the case it would be useful to see the boot kernel messages by booting with debug grub entry, but probably you already tried this and did not get any more useful message, maybe because the problem happens before the kernel has initialized the framebuffer to display messages on video. What kind hardware have you tried to boot it on?

I will go on checking if I can sort out or reproduce any new problems since latest distribution updates.

[Silvan]

Hello,
the nVidia driver will soon be updated to major version 550 after successful tests, I hope the upgrade will be smooth for you too.

As for the dual GPU + display support, I don’t know how to provide a out-of-the-box solution working with proprietary drivers and every situation. By the way documentation on configuring Optimus and PRIME support might be helpful. openmamba provides packages like bumblebee and envycontrol which might be helpful. I see now there is a tool called optimus-manager which maight be worth packaging.

References:

https://wiki.archlinux.org/title/PRIME

https://github.com/Askannz/optimus-manager

[Silvan]

Thanks for the test and the configuration provided. There will be a package update which will provide a default configuration with

permit persistent :sysadmin

By the way for the moment sudo commands remains the sudo tool in openmamba.

[Silvan]

Hi,
the package micro and opendoas are now available for installation in openmamba. The latter needs creating the configuration file /etc/doas.conf and maybe some testing.

[Silvan]

The nvidia driver might be missing in the latest kernel initramfs so I would suggest to try:
sudo /usr/sbini/mkinitrd -H -f /boot/initramfs-6.6.10-1mamba-x86_64.img 6.6.10-1mamba-x86_64

if network is available this shorter command might also work:
sudo dnf reinstall kernel-mamba-x86_64-6.6.10

[Silvan]

Hello,
since the installation I think you should have received at least one kernel update, so you might want to try booting with another kernel by selecting “Advanced” boot options in the Grub menu, then going down three choices should point you to the previous kernel.

Once you are able to boot openmamba without reinstalling we can further investigate the problem, but the first thing to see would be checking if dkms has built the nvidia driver for the last kernel releases. This can be checked with the following command line command:
sudo dkms status

[Silvan]

Hello Roderick,
thank you for your feedback and happy holidays!

[Silvan]

Hi,
I’ve released the package update filesystem-2.3-10mamba as an attempt to fix the problem you are reporting.
Thanks for letting me know if it works or not.

[Silvan]

Hi @ouaille_aime_scier,
I think this was a transient problem while releasing the up-to-date KDE frameworks packages. It should work now after refreshing the packages list with sudo dnf refresh or using the mambatray icon entry.
Thanks for reporting.

[Silvan]

Hello Roderick,
the issue seems to be caused by gnupg blocking due to pre-existing files in /root/.gnupg folder.
I would suggest to run the following commands from a konsole:

su
[Blocking -> Press CTRL-C and you are root]
killall -9 gpg-agent
rm -rf /root/.gnupg

Then the next su or sudo su call should regenerate a clean and correct content of the gnupg folder and fix the problem.

I hope this helps. Thanks for reporting and appreciating openmamba.
Silvan

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

[Silvan]

Hello Roderick,
you are saying that neither the su command not sudo passwd root are working correctly and that you get no prompt in response?
I currently don’t reproduce the problem, maybe I need to check if the new installation media have such problem. It might also be a problem related to network name resolution.
I will investigate more and thanks if you have some more info to provide.
Silvan

[Silvan]

Hi,
you are welcome.

About kdeconnect:
openmamba default firewall is ufw so the rules needed for kdeconnect are the ones described in the official documentation:
`
sudo ufw allow 1714:1764/udp
sudo ufw allow 1714:1764/tcp
sudo ufw reload
`
I will add these rules to ufw applications set as you suggest.

[Author]

Posts