Forum Replies Created
-
AuthorPosts
-
March 31, 2023 at 1:03 pm in reply to: logout shutdown and reboot don’t work with deconnection screen activated #29097
Silvan
KeymasterHi Silvan,
This is what appears in the terminal :mars 30 20:15:09 openmamba dbus-daemon[6819]: [session uid=1000 pid=6819] Successfully activated service 'org.kde.LogoutPrompt' mars 30 20:15:09 openmamba ksmserver-logout-greeter[8068]: kde.logout_greeter: Couldn't find a theme for the Shutdown dialog ""
Hi,
this seems like a theme problem. Are you using the default theme? If so, can you try to reapply it from the Appearance > Global theme page in the settings? It is not necessary to check the box for reapplying also the dispositions so that you won’t lose your customization.March 31, 2023 at 12:58 pm in reply to: files conflict between man-pages-fr and shadow packages #29096Silvan
KeymasterHi,
sorry, there was an error which I corrected inman-pages-fr-4.18.0-2mamba
which will be available as a new update in a few hours.March 30, 2023 at 12:32 pm in reply to: logout shutdown and reboot don’t work with deconnection screen activated #29092Silvan
KeymasterHello,
I don’t reproduce the problem, I’ve also tried both X11 and Wayland sessions and searched in KDE bugs.
Can you open a terminal and run:
journalctl -f
then try to logout to reproduce the problem and see if some useful message appears on the terminal?
March 30, 2023 at 12:10 pm in reply to: files conflict between man-pages-fr and shadow packages #29090Silvan
KeymasterHello,
I’ve released an update of man-pages-fr which fixes those conflicts. Thanks for reporting again in case you still have errors caused by other conflicting files.-
This reply was modified 2 years ago by
Silvan.
March 28, 2023 at 12:56 pm in reply to: logout shutdown and reboot don’t work with deconnection screen activated #29086Silvan
KeymasterHi,
it’s not clear to me what you mean with “When I activate the deconnection screen in the configuration”, this is normally activated by default and when you try to logout, reboot, shutdown etc., for instance from the bottom buttons in the application launcher menu, this screen appears for confirmation. So, you simply mean that you can never normally logout, reboot or shutdown from Plasma or are you describing a particular situation?If your case is the general issue this is not normally reproducible (those buttons are tested as working for me on many installations), so something bad may be happening on your particular installation and the cause might be reported in the user or system journal. You may want to check there or send a system report generated by the tools tyou may find in the applications menu.
If, on the contrary, the problem is reproducible in a particular case, can you please explain me better which configuration changes you have made and where you are clicking to ask for logout, reboot, etc. Thanks.
Silvan
KeymasterHi,
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
KeymasterHi,
I’ve looked into this problem and found that it can be solved if you can edit the file/etc/fstab
and replace the optionspace_cache
withspace_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 2 years ago by
Silvan.
Silvan
KeymasterHi 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
KeymasterHi,
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).
Silvan
KeymasterHi, if you still get errors related to nouveau you may need to recreate the initramfs with:
sudo mkinitrd -f
Silvan
KeymasterHi 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
KeymasterHi,
the problem was indeed caused by a lockup of the tool which refreshes repository metadata and should be fixed now.Silvan
KeymasterHello,
this is usually caused by thednf
updates manager which is unable to find an upgrade solution with x86_64 packages and also because I thinkdnf
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 settingenabled = 0
in the file/etc/yum/repos.d/openmamba-rolling-i586.repo
. Currentlyx86
repository is needed onx86_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 3 years, 5 months ago by
Silvan.
Silvan
KeymasterHi 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
KeymasterHi 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 processkwin_x11
to run at 100% CPU and block the desktop startup. This only happens the first time a user logs in, because thereafter the filekwinrc
is read from the local home directory. So the fix for this is in thedesktop-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 theopenmamba-diskimg-livecd
(with EFI boot support) oropenmamba-livecd
that have been made available between yesterday and today with the more recent kernel and everything fixed from my point of view. -
This reply was modified 2 years ago by
-
AuthorPosts