[SOLVED] /var/run/media instead of /run/media after last update in 64-Current

LuckyCyborg · 07-23-2021, 02:32 PM

Quote:

Originally Posted by igadoter

Just mount device and call df. df is using libmount in contrary to say cat. So parsing /proc/self/mountinfo with cat does not provide correct information about mounts.

Please provide proof regarding that the information on /proc/self/mountinfo is incorrect!

Because you just claimed that on the Linux kernel exists a really huge issue, which was not observed yet by anybody, including there Mr. Torvalds.

igadoter · 07-23-2021, 02:44 PM

Quote:

Originally Posted by LuckyCyborg

Long story short, IF you want to fix this double mounting of your pendrive, this is the way: make /var/run a symlink to /run like openSUSE, Ubuntu or Fedora do.
You will need to modify your /etc/rc.d/rc.S too.

You are just misguiding people here. There are no double mounts. We started this issue due to bug in KDE. Before that everything worked fine. You are just bringing here your ideas from that thread. bassmadrigal explained situation about making /var/run as symbolic link.

Don't go into this again due to KDE programmer bug. That programmer seems incorrectly parsing /proc/self/mountinfo with help of libmount. IMO better to drop libmount as Solid dependency. It was recently introduced seems for no reason. I mean reason is because Gnome guys did something similar.

If you want to bring attention to this of our BDFL just post it in 14.2 -> 15.0. The story of appearance of libmount dependency and the fact that it is automatically added if libmount is detected. And the fact that it breaks KDE. Was. Because it is a past as due to intervention code was changed. Now instead of clean code we have dirty workaround. Drop libmount from KDE and let us keep things as they are. We are running Slackware - not K(DE)lackware.

PS. Please don't use comrade in your posts. Next time you will address me this way I'll report this. And try to explain reason. Not in public because this could be taken as political discussion which is forbidden here.

ZhaoLin1457 · 07-23-2021, 02:52 PM

Quote:

Originally Posted by igadoter

You are just misguiding people here. There are no double mounts. We started this issue due to bug in KDE. Before that everything worked fine. You are just bringing here your ideas from that thread. bassmadrigal explained situation about making /var/run as symbolic link.

If there wasn't multiple mounts, we will never had that issue on Plasma5 with solid-5.84, because the problematic code path with is executed only when a device is multiple times mounted.

And how you explain the experiences of this thread OP? See the bellow quote.

Quote:

Originally Posted by gauchao

This is the tail of mount output. I don't see bind in it.

Code:

/dev/sdc1 on /run/media/removeabledrive/SANDISK64 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdc1 on /var/run/media/removeabledrive/SANDISK64 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)

bassmadrigal · 07-23-2021, 02:54 PM

Quote:

Originally Posted by gauchao

This is the tail of mount output. I don't see bind in it.

Maybe I am using wrong nomenclature about bind mount... sorry. However, inspecting from the command line, I see my removeabledrive is being mounted both under /var/run/media and /run/media, which I learned from Marav that comes from the "--make-shared" option in /etc/rc.d/rc.S. And Dolphin began to display the drive under /var/run/media today whereas yesterday it used to show the drive under /run/media. Both are the same.

I wouldn't expect you'd see bind in this output, because this device isn't bind mounted.

It's the parent directory that *should* be bind mounted per rc.S.

So, you can actually see the mount in both /var/run/media, and /run/media?

Quote:

Originally Posted by LuckyCyborg

Welcome to Wonderful World of Shared Bind Mounting, which confuses both the users and the programs!

BTW, in the Plasma5 thread I explained that Solid (then Doplhin, Krusader, Konqueror, etc) may chose the mountpoint from /var/run/media instead of the one from /run/media even the application itself mounts the device on /run/media .

You know, I posted dumps from /proc/self/mountinfo of Slackware and openSUSE to explain WHY.

Ugh, you and tooting your own horn. Get some humility. You didn't even answer my question with this pompous response.

Turns out, based on further postings from OP that the device is seen in both /var/run and /run, so my previous assumption was correct.

Quote:

Originally Posted by marav

I too, until recently, thought that by doing mount you would see :
/dir1 /media/dir1 ....... (rw,.... ,bind)

Based on a previous post by OP, it seems that their directory did show up in both locations, so it seems our assessments were accurate.

igadoter · 07-23-2021, 03:00 PM

Quote:

Originally Posted by LuckyCyborg

Please provide proof regarding that the information on /proc/self/mountinfo is incorrect!

Because you just claimed that on the Linux kernel exists a really huge issue, which was not observed yet by anybody, including there Mr. Torvalds.

It seems you don't have df installed. Let us see output of df command on your computer.

ZhaoLin1457 · 07-23-2021, 03:04 PM

Quote:

Originally Posted by igadoter

It seems you don't have df installed. Let us see output of df command on your computer.

This df program interprets some data which I suspect that it gets from /proc/self/mountinfo then show the parsed information.

How the df could contradict the kernel information?

BTW, if you like to know, I am member of Communist Party of PRC since 1987, so I will not become angry if you call me comrade.

igadoter · 07-23-2021, 03:06 PM

Quote:

Originally Posted by ZhaoLin1457

If there wasn't multiple mounts, we will never had that issue on Plasma5 with solid-5.84, because the problematic code path with is executed only when a device is multiple times mounted.

Issue was caused by programmer from KDE. Which was resolved by dirty workaround. Because programmer has no idea what's is happening. Some people here blame Slackware. I blame programmer. Let don't use this failure of that programmer as excuse to changing system settings. To makes KDE works. We need really solid (nomen omen) reasons to do that.

marav · 07-23-2021, 03:10 PM

Funny btw

https://git.savannah.gnu.org/cgit/co...15158f5abe4ecc

igadoter · 07-23-2021, 03:11 PM

Quote:

Originally Posted by ZhaoLin1457

BTW, if you like to know, I am member of Communist Party of PRC since 1987, so I will not become angry if you call me comrade.

Lucky for us no one here openly claim its membership in neo-nazi party in Germany. It is joke as your own of course.

igadoter · 07-23-2021, 03:16 PM

Quote:

Originally Posted by marav

Funny btw

https://git.savannah.gnu.org/cgit/co...15158f5abe4ecc

The bug fix address different issue. It is related to bind mounts of nfs - remote file system.

ZhaoLin1457 · 07-23-2021, 03:19 PM

@igadoter

I am Chinese, living since my birth on PR of China. And I am a modest Japanese teacher, if you like to know.

BTW, in our country, the far-right ideologies are forbidden.

igadoter · 07-23-2021, 03:24 PM

I can tell you that: we stopped to like communism in my country. That's resolves issue because well people change their preferences. Often for no reason.

ZhaoLin1457 · 07-23-2021, 03:28 PM

Quote:

Originally Posted by igadoter

Issue was caused by programmer from KDE. Which was resolved by dirty workaround. Because programmer has no idea what's is happening. Some people here blame Slackware. I blame programmer. Let don't use this failure of that programmer as excuse to changing system settings. To makes KDE works. We need really solid (nomen omen) reasons to do that.

Yes, there was an omission made by this programmer from KDE.

Thought, I believe that am not qualified to call what he did "a dirty workaround" or not. I seen that's also called "a necessary safety check"

However, our issues will never will happened if there was a single mount point like you claim, at least according with my friends. They explained me something:

Code:

QString StorageAccess::filePath() const
{
    if (isLuksDevice()) { // encrypted (and unlocked) device
        const QString path = clearTextPath();
        if (path.isEmpty() || path == "/") {
            return QString();
        }
        Device holderDevice(path);
        const auto mntPoints = qdbus_cast<QByteArrayList>(holderDevice.prop("MountPoints"));
        if (!mntPoints.isEmpty()) {
            return QFile::decodeName(mntPoints.first()); // FIXME Solid doesn't support multiple mount points
        } else {
            return QString();
        }
    }

    const auto mntPoints = qdbus_cast<QByteArrayList>(m_device->prop("MountPoints"));
    if (mntPoints.isEmpty()) {
        return {};
    }

    const QString potentialMountPoint = QFile::decodeName(mntPoints.first());
    if (mntPoints.size() == 1) {
        return potentialMountPoint; <-- here should have been the exit if we we had a single mountpoint for device.
    }
                    
    // Device has bind mounts?
    const QString basePoint = baseMountPoint(m_device->prop("Device").toByteArray()); <-- here comes the crash!
        
    return !basePoint.isEmpty() ? basePoint : potentialMountPoint;

gauchao · 07-23-2021, 03:49 PM

Quote:

I wouldn't expect you'd see bind in this output, because this device isn't bind mounted.

It's the parent directory that *should* be bind mounted per rc.S.

So, you can actually see the mount in both /var/run/media, and /run/media?

Yes, bassmadrigal. I see the mount in both /var/run/media and /run/media. They both work.

bassmadrigal · 07-23-2021, 04:04 PM

Not sure why this went all political...

Quote:

Originally Posted by gauchao

Yes, bassmadrigal. I see the mount in both /var/run/media and /run/media. They both work.

Then your issue is due to what's been discussed on the KDE thread. Solid introduced a function where it gets mounts from libmount. This happened in the last version added in -current. There is a patch in the KDE thread that fixes crashes. It'd be interesting to see if it fixes your issue as well.

If you want to try it, here's the instructions:

First, you'll want to mirror the source/kde/kde directory from your favorite mirror. From within the kde/ directory:

Save this file as patch/solid/solid-qstrcmp.diff

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;
                 }

Then save the following as /patch/solid.patch

Code:

cat $CWD/patch/solid/solid-qstrcmp.diff | patch -p1 --verbose || { touch ${SLACK_KDE_BUILD_DIR}/${PKGNAME}.failed ; continue ; }

Then build solid:

Code:

sh kde.SlackBuild frameworks:solid

This should automatically install the updated version, but if not, you can run upgradepkg --reinstall automatically on the solid package in /tmp/.