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.
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.
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?
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
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.
Last edited by LuckyCyborg; 07-22-2021 at 05:33 AM.
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:
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" ...
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.
Last edited by LuckyCyborg; 07-22-2021 at 05:47 AM.
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:
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" ...
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.
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
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.
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.
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
Last edited by LuckyCyborg; 07-22-2021 at 06:19 AM.
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.
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?
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.
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.
My thought:
Only Mr. Volkerding will decide how he will handle /run and /var/run
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.