LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   All Things KDE5/Plasma for Slackware Users. (https://www.linuxquestions.org/questions/slackware-14/all-things-kde5-plasma-for-slackware-users-4175670109/)

pchristy 07-20-2021 06:00 AM

One further thought: I see a comment about 5.84 being linked against more of the system than before (libmount was mentioned).

Could this be related to the way Slackware works around systemd? Does 5.84 require systemd and is less tolerant of work-arounds?

I would guess that the majority of distros would not see any issues if this is the case. It may also be that those who are NOT experiencing any issues have some rules in place that suppress the error.

(Clutching at straws here!)

--
Pete

marav 07-20-2021 06:08 AM

Hi Pete

I also think, indeed, that the problem is very particular to Slackware. As LuckyCyborg also said
In any case, we must not forget the fact that obviously few people are impacted
Considering a global problem seems to me complicated

plus the fact that those who are not concern, are unable to reproduce it (for now)

j12i 07-20-2021 06:10 AM

We (the affected users) should totally take this to the KDE bugtracker, as suggested my marav here:
Quote:

Originally Posted by marav (Post 6267569)
If anyone who has had the dolphin/usb problem can report it to :

https://bugs.kde.org/buglist.cgi?com...resolution=---

I just don't have the spoons right now.

marav 07-20-2021 06:15 AM

Quote:

Originally Posted by j12i (Post 6267965)
We (the affected users) should totally take this to the KDE bugtracker, as suggested my marav here:I just don't have the spoons right now.

Unfortunately, I think that we can't report it to the KDE bugtracker, as long as the bug is not clearly identifyed

EDIT :
I highly doubt that Pat would have left solid 5.84 if it was the culprit

LuckyCyborg 07-20-2021 06:19 AM

Quote:

Originally Posted by pchristy (Post 6267960)
One further thought: I see a comment about 5.84 being linked against more of the system than before (libmount was mentioned).

Could this be related to the way Slackware works around systemd? Does 5.84 require systemd and is less tolerant of work-arounds?

I would guess that the majority of distros would not see any issues if this is the case. It may also be that those who are NOT experiencing any issues have some rules in place that suppress the error.

(Clutching at straws here!)

--
Pete

This libmount is part of util-linux - it has nothing to do with systemd.

https://git.kernel.org/pub/scm/utils...util-linux.git

Maybe the way we build util-linux affects this solid-5.84 ? How?

pchristy 07-20-2021 06:24 AM

Yes, I wasn't suggesting that libmount was part of systemd, merely that if 5.84 is linking against more system elements, then perhaps Slackware's "work-around" for systemd was involved. Perhaps I should have written that better! Sorry for any confusion.

BTW, have you read my comment at the bottom of P.45? The comment at the top of P.46 was an addendum to that.

(I'm getting a bit above my pay grade here! :) )

--
Pete

LuckyCyborg 07-20-2021 06:31 AM

Quote:

Originally Posted by pchristy (Post 6267970)
Yes, I wasn't suggesting that libmount was part of systemd, merely that if 5.84 is linking against more system elements, then perhaps Slackware's "work-around" for systemd was involved. Perhaps I should have written that better! Sorry for any confusion.

BTW, have you read my comment at the bottom of P.45? The comment at the top of P.46 was an addendum to that.

(I'm getting a bit above my pay grade here! :) )

--
Pete

Of course i read also your previous post.

Man, there we need a C/C++ programmer with Qt5/KDE skills... That probably means bug reporting to them.

Honestly, I started to believe that us being non-systemd distribution, we use a less tested code path on this Solid. I bet that others uses the systemd services for doing those things, that's why nobody else yells.

igadoter 07-20-2021 06:41 AM

You guys are so in love with KDE (whatever) to point to stop to think. But love is blind as they say. Who in nowadays is adding path to dynamic storage in fstab? KDE lovers.
So for those not in love there are other solutions
Code:

$ lsblk -f
$ udisksctl mount -b /dev/sdb3 # post correct path here

if you will now see mounted device in Dolphin or whatever - simple conclusion. It is applet bug. Best regards.

Edit: One more point. To my knowledge KDE (s..Plasma) mounts under /media but Slackware udisksctl command mounts under /run/media. Does /media on your system has correct privileges?

Edit: My personal view about mounting dynamically devices is that Slackware should ship with simple graphical frontend for udisksctl command. Due to lack of full systemd. In my opinion autmounters shipped with desktops are rather poor. Say have no idea do they even have option power-off. Say when you eject device inside thunar - it does not matter really because device is still being listed by lsusb.

marav 07-20-2021 06:58 AM

Quote:

Originally Posted by igadoter (Post 6267973)
You guys are so in love with KDE (whatever) to point to stop to think. But love is blind as they say. Who in nowadays is adding path to dynamic storage in fstab? KDE lovers.
So for those not in love there are other solutions
Code:

$ lsblk -f
$ udisksctl mount -b /dev/sdb3 # post correct path here

if you will now see mounted device in Dolphin or whatever - simple conclusion. It is applet bug. Best regards.

Edit: One more point. To my knowledge KDE (s..Plasma) mounts under /media but Slackware udisksctl command mounts under /run/media. Does /media on your system has correct privileges?

Edit: My personal view about mounting dynamically devices is that Slackware should ship with simple graphical frontend for udisksctl command. Due to lack of full systemd. In my opinion autmounters shipped with desktops are rather poor. Say have no idea do they even have option power-off. Say when you eject device inside thunar - it does not matter really because device is still being listed by lsusb.


I've just done a fresh install ( 2 days old ISO, without updates, kernel huge 5.13.2)
No issue ...

In booth case ( dolphin mount / udiskctl ) the usb key is mounted under /run/media/$USER/<UUID>
With :
/run/media/$USER is still owned by root
/run/media/$USER/<UUID> is owned by $USER

EDIT:
I am not a KDE fanboy
I've always been on XFCE/Openbox/dwm/i3, I gave Plasma a chance when it first came to the repositories, and I've stayed with it ever since :-)

igadoter 07-20-2021 07:08 AM

So this must be particular to Slackware. By the way about adding device to fstab. I rethink the option. Probably adding device by UUID has some sense. If you use fixed set of storage devices. The same pendrives, sd cards etc. But it was long time ago I used directly fstab - so you probably need option - auto? And beside device has to be mounted somewhere else than /run.

igadoter 07-20-2021 07:11 AM

Quote:

Originally Posted by marav (Post 6267976)
In booth case ( dolphin mount / udiskctl ) the usb key is mounted under /run/media/$USER/<UUID>
With :
/run/media/$USER is still owned by root
/run/media/$USER/<UUID> is owned by $USER

And what is under /media? Perhaps there are links pointing to /run/media.

Edit: or vice versa /run/media/$USER contains links to /media?

marav 07-20-2021 07:16 AM

Quote:

Originally Posted by igadoter (Post 6267984)
And what is under /media? Perhaps there are links pointing to /run/media.

Edit: or vice versa /run/media/$USER contains links to /media?

Nothing

The key is mounted in both /var/run/media and /run/media

EDIT : they are not symlinked

Toutatis 07-20-2021 08:34 AM

In my case the newest things in /media are links (of july 2016). The date of files and directory is 2006. The same for /mnt.

atelszewski 07-20-2021 09:04 AM

Hi,

I've narrowed down (or at least I'm strongly convinced so) the culprit:
Code:

$ gdb /usr/bin/krusader
GNU gdb (GDB) 10.2
(..)

Thread 1 "krusader" received signal SIGSEGV, Segmentation fault.
0x00007ffff7dfdc5f in baseMountPoint (dev=...)
    at /tmp/kde_build/frameworks/solid-5.84.0/src/solid/devices/backends/udisks2/udisksstorageaccess.cpp:97
97                          && (strcmp(mnt_fs_get_root(fs), "/") == 0)) {

My educated guess is that mnt_fs_get_root() returns NULL.
But strcmp() is not designed to handle NULL arguments.

Maybe someone can take it from here or I'll come back to it at some later time.

(BTW, I recompiled solid with debug info to be able to, well, debug. ;-))

--
Best regards,
Andrzej Telszewski

igadoter 07-20-2021 09:12 AM

Is there no difference between c++ and c strcmp() implemantation? So the patch would be to test for non-NULL argument.


All times are GMT -5. The time now is 03:16 AM.