[Silvan]

Thanks for the information. Can you also post the output of:
locale -a

and if ar_DZ.UTF-8 is in the output, see if issuing the following command fixes the problem:
sudo locale-gen

[Silvan]

Hi,
please let me understand the flow.
You started the live O.S. from the latest livecd or livedvd ISO? Then you run the calamares installer, selected Arabic language and installed. Then the system was in Arabic since first boot into the installed system? Next you updated the system and lost the Arabic language?
There are no relevant updates in the last days which might cause the problem of removing a configured language, unless what you report is instead a problem with Plasma desktop, which has been updated very recently.
What is the output of:

grep -v "^#" /etc/locale.gen
cat /etc/locale.conf

System locale is configured in /etc/locale.gen and compiled with sudo locale-gen and this should have been done at installion time.

This said, what exactly happened here is not clear, maybe I can reproduce it by repeating your installation flow but I first try to retrieve some more information as described above because the option of trying to reproduce it myself requires more time.

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

[Silvan]

Hi, it should be fixed now.

[Silvan]

The issue has been identified as caused by dolphin build order against baloo-widgets when updating the release of KDE Applications. The upcoming dolphin update shall fix this.
Thanks for reporting.

[Silvan]

I confirm that the kernel update with the fix (version 6.18.16-1mamba) is available for all users. The livecd snapshot generated tonight also provides the fix.

The fastfetch package is now available in openmamba as well.

[Silvan]

Hi, thank you for reporting the problem.

I have been wondering about this problem and now I have found that openmamba kernel has a wrong configuration which is limiting to 8 the maximum number of supported CPUs. A kernel update will be released tomorrow which fixes this limit, providing kernel support for up to 256 CPUs.

• This reply was modified 3 months ago by Silvan.
• This reply was modified 3 months ago by Silvan.
• This reply was modified 3 months ago by Silvan.

[Silvan]

Hi, I’ve received a report which seems related to the problem in this post.
The report shows a crash of a /usr/bin/kwalletmanager5 process but unfortunately due to drkonqi crashing as well the coredump information for kwallemanager5 is missing.
In order to possibly find useful information on why kwalletmanager5 is crashing I would suggest to provide the output of the following command:
coredumpctl dump /usr/bin/kwalletmanager5

• This reply was modified 5 months ago by Silvan.

[Silvan]

Hi,
this is a known problem with rpm unshare plugin failing in a container.
I suggest to use the same workaround which I applied in the openmamba-docker-buildvm project, i.e. before running dnf install a file to the pathname /etc/rpm/macros.transaction_unshare with this content:

%__transaction_unshare %{nil}

[Silvan]

The new received report is about a Intel Core 3 CPU based hardware. The log shows a series of crashed which would suggest investigation:

Nov 10 08:52:26 lptp drkonqi-coredump-processor[5184]: "/usr/bin/gpg-agent" 6821 ""
Nov 10 08:52:26 lptp drkonqi-coredump-processor[5184]: "/usr/bin/gpg-agent" 6922 ""
Nov 10 08:52:26 lptp drkonqi-coredump-processor[5184]: "/usr/bin/gpg-agent" 7134 ""
Nov 10 08:52:26 lptp drkonqi-coredump-processor[5184]: "/usr/bin/kwalletmanager5" 9204 "/var/lib/systemd/coredump/core.kwalletmanager5.1000.2c0861e734744eaca96288c02f4e69c1.9204.1756379708000000.zst"
Nov 10 08:52:26 lptp drkonqi-coredump-processor[5184]: "/usr/libexec64/drkonqi" 9252 "/var/lib/systemd/coredump/core.drkonqi.1000.2c0861e734744eaca96288c02f4e69c1.9252.1756379709000000.zst"
Nov 10 08:52:26 lptp drkonqi-coredump-processor[5184]: "/usr/libexec64/drkonqi" 9251 "/var/lib/systemd/coredump/core.drkonqi.1000.2c0861e734744eaca96288c02f4e69c1.9251.1756379709000000.zst"

A useful backtrace for these coredumps would be necessary. Unfortunately
– the packages installation log shows that the last package was updated on October 20, in order to try to install the needed debug packages they should be aligned with current repositories, so the system should be updated first
– drkonqi itself is crashing so no crash helper would be available on the desktop

I suggest to update the system, try to install some debug package like:
sudo dnf install gnupg2-debug kwalletmanager-debug qt6-qtbase-debug

reboot, reproduce the problem and generate a new report. By having the system up-do-date the more recent coredumps can be shared in order to try to obtain a useful stack trace.
The more useful would be the one related to gpg-agent as is it probably the cause of the subsequent kwalletmanager5 crash, but first it has to be confirmed that after the system upgrade it gets these same processes to crash.

• This reply was modified 6 months, 4 weeks ago by Silvan.
• This reply was modified 6 months, 4 weeks ago by Silvan.

[Silvan]

While the nvidia-470 installation may have a history of its own, I suppose the Ryzen PC is running with standard drivers and you are reporting the kwallet problem as present on both. By the way it seems you only sent reports of the nvidia-470 PC. A report from the Ryzen PC might be useful to try to make a diagnosis of the problem.

[Silvan]

I’ve tried today’s livecd, installed the system on VirtualBox, rebooted, logged in, run firefox and did not get any kde wallet password request. I also tried logging in with plasma-x11 and did not reproduce the problem either.

[Silvan]

Additionaly, code can be installed by following the same instructions for RPM based distributions on this page . A Microsoft dnf repository is set and will provide the updates, this is the way Skype could be used until it was dismissed.

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\nautorefresh=1\ntype=rpm-md\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" | sudo tee /etc/yum.repos.d/vscode.repo > /dev/null
sudo dnf install code

You may need to remove visual-studio-code-bin before to avoid conflicts.

Edge is currently only distributed in .deb format so the above mechanism is not applicable.

[Silvan]

openmamba has already a project called netsrpms which provides support for local download and RPM packaging of components which cannot be distributed. Adding support for vscode and edge is now in my TODO list.

[Silvan]

By doing a quick check the license might not allow binary distribution of vscode either, although other official sources like this page seem to be permissive when citing some distributions.
While I need to do further checks when I have time I have removed the visual-studio-package from openmamba repository as a precaution.

[Silvan]

I will do an installation test with the latest livecd ISO image. Did you set automatic login on your installations?

[Author]

Posts