SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
but I am running Live Edition of AlienBob. Maybe AlienBob is using own builds of KDE in Live Edition. So at this point I am little out of discussion.
No, Alien Bob doesn't use a different version of KDE in this Slackware Live (at least not until he brings back ktown), you're just running an older version. We already knew the older version didn't have issues. You should probably use slackpkg to upgrade your system or refresh your install with the newer ISO generated on the 16th (the solid update was pushed on the 10th) using iso2ush.sh -r.
No, Alien Bob doesn't use a different version of KDE in this Slackware Live (at least not until he brings back ktown), you're just running an older version. We already knew the older version didn't have issues. You should probably use slackpkg to upgrade your system or refresh your install with the newer ISO generated on the 16th (the solid update was pushed on the 10th) using iso2ush.sh -r.
Thanks for explanations. You right I should update to new version. But for me six months period between upgrades is reasonably. Person of AlienBob is kind of warranty snapshot he took is stable enough. Direct update with recent -current can brake this stability. So upgrade Live with Live.
But on Slackware the /var/run is a bind mount of /run, then when we will mount a USB drive, it appears on both locations.
I knew already that this is a cause for the problem, as the code path with the crash is for exactly the case when the partition is mounted in multiple places.
What I didn't knoow is that other distributions do it differently. Also I assumed there's a good reason that Slackware does it this way. I'm going to ask about it in the requests thread. But I think the fault lies with KDE. The check should be there even if it is only needed on (FHS-) non-conforming systems.
I located the change introducing the offending code in KDE's GitLab and commented there about our issue. I think the commit/change author will be notified about my comment, and will wait for/if he has to something to say about this.
In my humble opinion, this is the real issue and that's why the code works for others and not for us sometimes: the way how we handle the /var/run which probably is specific to Slackware.
This is only workaround to solve this particular issue. We have no idea how this change influence others parts of system. To do such things you need to keep history all changes. In emergency you can rollback system to its previous state. That's beyond common Slackware user. We can do some small things. But in general rely on Slackware is evolving without revolutions. We can't keep track of that kind of development.
In the context of ZhaoLin1457 about binding /var/run this caught my attention from link above
Quote:
With bind mounts on Linux, UDisks returns a 'MountPoints' property that could
include several paths, try to get the actual mount point of the partition
and ignore bind mounts.
if I understand well ignore bind mounts would cause to ignore /var/run.
Edit: For me it looks like this function instead of /var/run returns /run - supposedly or ...nothing.
igadoter, a bind mount is not substantially different from any other mount (man mount may have more info). So if something is mounted with a bind mount (or multiple), those mount points are not in any way inferior to the original one, afaik. (Similar to a file with multiple hardlinks.) Thus, the solid code in question, as far as I can tell, isn't trying to decide which mount point is authoritative, but just tries to make one canonical for solid's sake.
I can't sleep. and Ahmad Samir of solid has already proposed a patch. I suspect it is equivalent to the one from LuckyCyborg's friend, but please test it everyone affected, for this will be in the next version of solid then.
I can't sleep. and Ahmad Samir of solid has already proposed a patch. I suspect it is equivalent to the one from LuckyCyborg's friend, but please test it everyone affected, for this will be in the next version of solid then.
I have tested Solid 5.84 built with the patch proposed by the Solid programmer and everything works fine.
The Plasma5 desktop is loaded properly without crashes and I tested also mounting an USB drive with Dolphin and systray widget.
Last edited by ZhaoLin1457; 07-22-2021 at 01:34 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
