LinuxQuestions.org - All Things KDE5/Plasma for Slackware Users.

- 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/)

I don't feel comfortable with this "solution". We would stop and start to think. Instead of running blindly forward. But now it does not really matters as patch is officially added to KDE source.

But is worse part of it. This situation raised question for me: how really stable will be 15.0? Things happens which should not. What does it mean?

Edit: My own solution would be to remove for time being libmount dependency. KDE worked well without libmount - and to my understanding this addition using libmount offers no real benefit. As the author claims idea is imported from Gnome. So as well it can be dropped in future.

Quote:

Originally Posted by igadoter (Post 6268697)

This situation raised question for me: how really stable will be 15.0?

IMO, we can't say something is unstable because 1% of users encounter an issue

Quote:

Originally Posted by ZhaoLin1457 (Post 6268667)

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.

How did you apply the patch? Did you just replace LuckyCyborg's solid-5.84.0.diff with the one from the developer? Looking at it, it appears to be missing some of the intro lines. ( I know how to apply most patches, but I'm not an expert at reading them ).

Has anyone else applied the developer patch, and if so, did you basically follow LuckyCyborg's instructions?

Idiot's guide needed! ;)

--
Pete

Quote:

Originally Posted by pchristy (Post 6268706)

Download as (last button, near: Check out branch) -> Plain diff

For your convenience:

Code:

diff --git a/src/solid/devices/backends/udisks2/udisksstorageaccess.cpp b/src/solid/devices/backends/udisks2/udisksstorageaccess.cpp

index 15667872075a28d5ae682f2e5613790969510f19..35d1aa8a6452dbe741e60d0a21b362a0a3da52f2 100644

--- a/src/solid/devices/backends/udisks2/udisksstorageaccess.cpp

+++ b/src/solid/devices/backends/udisks2/udisksstorageaccess.cpp

@@ -92,9 +92,9 @@ static QString baseMountPoint(const QByteArray &dev)

            const QByteArray devicePath = dev.endsWith('\x00') ? dev.chopped(1) : dev;

 

            while (mnt_table_next_fs(table, itr, &fs) == 0) {

-                if (mnt_fs_get_srcpath(fs) == devicePath

-                    // Base mount point will have "/" as root fs

-                    && (strcmp(mnt_fs_get_root(fs), "/") == 0)) {

+                if (mnt_fs_get_srcpath(fs) == devicePath //

+                    && (qstrcmp(mnt_fs_get_root(fs), "/") == 0) // Base mount point will have "/" as root fs

+                ) {

                    mountPoint = QFile::decodeName(mnt_fs_get_target(fs));

                    break;

                }

Replace into solid-5.84.0.diff then do just like you did while using my own patch.

Many thanks!

--
Pete

Quote:

Originally Posted by igadoter (Post 6268697)

I don't feel comfortable with this "solution". We would stop and start to think. Instead of running blindly forward. But now it does not really matters as patch is officially added to KDE source.

Well, what the KDE developer did is to add a safety check on data returned by a function from libmount. And my (programmer) friend says that absolutely correct, because you cannot rely on suppositions about what data is returned with the risk of crash - of Solid daemon in this case.

BUT, my friend say that the context is much worse than that, because looks like the Slackware invented the Schrödinger's Cat Mountpoint.

Let me explain...

This is what the end of /proc/self/mountinfo looks on openSUSE Tumbleweed with an USB drive mounted via Dolphin:

Code:

724 29 0:43 / /run/user/0 rw,nosuid,nodev,relatime shared:371 - tmpfs tmpfs rw,size=1630728k,nr_inodes=407682,mode=700,inode64

808 724 0:45 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:434 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0

842 29 8:49 / /run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:461 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

This is what the end of /proc/self/mountinfo looks on Slackware-current with an USB drive mounted via Dolphin:

Code:

53 24 0:44 / /run/user/0 rw,nosuid,nodev,relatime shared:2 - tmpfs tmpfs rw,size=1632440k,nr_inodes=408110,mode=700,inode64

54 49 0:44 / /var/run/user/0 rw,nosuid,nodev,relatime shared:2 - tmpfs tmpfs rw,size=1632440k,nr_inodes=408110,mode=700,inode64

55 53 0:45 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:3 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0

56 54 0:45 / /var/run/user/0/gvfs rw,nosuid,nodev,relatime shared:3 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0

68 24 8:49 / /run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:4 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

69 49 8:49 / /var/run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:4 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

So, on openSUSE the USB drive is mounted on /run/media/root/ADATA\040UFD while on Slackware is "mounted" on /run/media/root/ADATA\040UFD and /var/run/media/root/ADATA\040UFD

I said "mounted" because nobody intended to mount it on /var/run and Dolphin/Solid/USDISKS2 intended to mount it on /run.

However, when Solid's baseMountPoint() do its run, it will scan the data in reverse order. So, it's first found the mountpoint: /var/run/media/root/ADATA\040UFD and reported back to Plasma5 applications.

That means that when you enter on this drive and paste some files, Dolphin will go on /var/run/media/root/ADATA\040UFD which is a flagrant infringement of FHS rules, which says that that an application should use exclusively either /run or /var/run and it uses both - the poor Plasma5 ends doing FHS infringements because we "we dare to be different" ... :p

Another issues is that /var/run/media/root/ADATA\040UFD is a "fake" mountpoint and libmount shall dismiss it's line every time and return NULL on its mnt_fs_get_root()

Unfortunately, looks like it succeeds to fail only on 1% of tries. Yeah, apparently the NORMAL is to get a fine crash on Slackware, without my patch or that upstream patch.

BUT, where we should stop? Looks like even the kernel has a leg on this business. ;)

So, even we found and fixed an safety check issue on Solid, but probably we shall patch also the other KDE programs, udisks2, util-linux, kernel and God knows what other packages to adapt them to our very unique duet of /run and /var/run bonded together via shared bind mount.

Honestly, I think it's way more simple to just respect FHS and make /var/run a symlink to /run, like everyone do.

Quote:

Originally Posted by LuckyCyborg (Post 6268719)

Code:

724 29 0:43 / /run/user/0 rw,nosuid,nodev,relatime shared:371 - tmpfs tmpfs rw,size=1630728k,nr_inodes=407682,mode=700,inode64

808 724 0:45 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:434 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0

842 29 8:49 / /run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:461 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

This is what the end of /proc/self/mountinfo looks on Slackware-current with an USB drive mounted via Dolphin:

Code:

53 24 0:44 / /run/user/0 rw,nosuid,nodev,relatime shared:2 - tmpfs tmpfs rw,size=1632440k,nr_inodes=408110,mode=700,inode64

54 49 0:44 / /var/run/user/0 rw,nosuid,nodev,relatime shared:2 - tmpfs tmpfs rw,size=1632440k,nr_inodes=408110,mode=700,inode64

55 53 0:45 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:3 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0

56 54 0:45 / /var/run/user/0/gvfs rw,nosuid,nodev,relatime shared:3 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0

68 24 8:49 / /run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:4 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

69 49 8:49 / /var/run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:4 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

Code:

5.13.2. Requirements



In general, the requirements for /run shall also apply to /var/run. 

It is valid to implement /var/run as a symlink to /run.



The utmp file, which stores information about who is currently using the system, 

is located in this directory.



Programs should not access both /var/run and /run directly, 

except to access /var/run/utmp

https://refspecs.linuxfoundation.org...s/ch05s13.html

Quote:

Originally Posted by LuckyCyborg (Post 6268719)

Another issues is that /var/run/media/root/ADATA\040UFD is a "fake" mountpoint and libmount shall dismiss it's line every time and return NULL on its mnt_fs_get_root()

I think you oversimplifying here. You just have two mount points to the same file system. Do you see /var/run/media/root/ADATA\040UFD as a link to /run/media/root/ADAT\040UFD ? Perhaps it is good time to stop and understand difference between linking ln -s and mount --bind. Say what if you lose mount point for target file system? For sure link became useless. What about mount --bind? It is partially question to myself to answer.

Quote:

Originally Posted by igadoter (Post 6268727)

Well, absolutely no program mounted something on /var/run/media/root/ADATA\040UFD but on /run/media/root/ADATA\040UFD

The bind mounting is done at al lower level on the trees, /var/run -> /run BUT because it's used the option "shared" the mounted directories from /run reflects on /var/run and viceversa.

The mountpoint /var/run/media/root/ADATA\040UFD is NOT a bind of whatever else mountpoint, but basically a reflection of /run/media/root/ADATA\040UFD.

It exists, but not really exists - like I said, it's a Schrödinger's Cat Mountpoint

Has anyone notified Patrick of any of this - including the various patches? Surely this is something he should be involved in since (to me!) it appears to address fundamental Slackware practices.

I know he does keep an eye on this forum, but this problem is "hidden" under a thread name that does not flag up its importance.

If no-one else wishes to, I will contact him, but it would be better coming from someone like LuckyCyborg, as he seems to have his finger well and truly on the pulse of this, as well as having found a solution to the problem.

Just my 2p worth!

--
Pete

Quote:

Originally Posted by marav (Post 6268722)

Code:

Programs should not access both /var/run and /run directly, 

except to access /var/run/utmp

Can someone explain this? Say I can access directly /run, I can access directly /var/run - but not both!? Or perhaps this means program has to use interface to access /run and /var/run?

Quote:

Originally Posted by LuckyCyborg (Post 6268730)

It exists, but not really exists - like I said, it's a Schrödinger's Cat Mountpoint

I would say Schroedinger Cat's Explanation. It exists and does not - in the same time.

Quote:

Originally Posted by pchristy (Post 6268731)

Has anyone notified Patrick of any of this - including the various patches? Surely this is something he should be involved in since (to me!) it appears to address fundamental Slackware practices.

If build is automatic problem disappeared already. Just new update of KDE will contain fix strcmp -> qstrcmp. The only general question is about /var/run. To create it as symbolic link or keep as it is now. For this better to start new thread. Pro- and contra.

Quote:

Originally Posted by igadoter (Post 6268741)

My thought:
Only Mr. Volkerding will decide how he will handle /run and /var/run

You can put information about this patch in Solid in 14.2 -> 15.0 thread.