[SOLVED] Disk monitor mount request

rnturn · 04-03-2020, 10:46 AM

Last night I got a popup requesting the root password for a mount request on my desktop system. I was working on my laptop when this request popped up so I didn't see it until this morning. I've attached an image of the dialog box. (See below.)

The PIDs listed in the dialog box correspond to:

Code:

$ ps -ef | grep -v grep |  grep -E '2662|2039'
root      2039     1  0 Apr01 ?        00:02:03 /usr/lib/udisks2/udisksd
rnturn    2662  2074  0 Apr01 ?        00:00:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor

Those processes appear to have been running since the last system reboot (following patching). There are no entries under /etc/udisks2 at all let alone something referring to /dev/sdd2. There is a mention of /dev/sdd2 in /etc/lvm/cache/.cache which I find odd since I'm not using LVM for any defined storage on the system.

There are messages in /var/log/messages that indicate that the authentication request came :

Code:

2020-04-02T21:30:43.662640-05:00 kadath polkit-kde-authentication-agent-1[2359]: Listener adapter polkit_qt_listener_initiate_authentication
2020-04-02T21:30:43.662923-05:00 kadath polkit-kde-authentication-agent-1[2359]: GSimpleAsyncResult: 0x5584a6ed4ce0
2020-04-02T21:30:43.663088-05:00 kadath polkit-kde-authentication-agent-1[2359]: polkit_qt_listener_initiate_authentication callback for  0x5584a64b84e0
2020-04-02T21:30:43.675526-05:00 kadath polkit-kde-authentication-agent-1[2359]: Initiating authentication
2020-04-02T21:30:43.824415-05:00 kadath polkit-kde-authentication-agent-1[2359]: Message of action:  "Authentication is required to mount ST500DM002-1BD142 (/dev/sdd2)"
2020-04-02T21:30:44.312501-05:00 kadath polkit-kde-authentication-agent-1[2359]: Action description has been found
2020-04-02T21:30:44.379458-05:00 kadath polkit-kde-authentication-agent-1[2359]: WinId of the dialog is  31457300 31457300
2020-04-02T21:30:44.398340-05:00 kadath polkit-kde-authentication-agent-1[2359]: WinId of the shown dialog is  31457300 31457300
2020-04-02T21:30:44.398554-05:00 kadath polkit-kde-authentication-agent-1[2359]: Trying again
2020-04-02T21:30:44.884540-05:00 kadath polkit-kde-authentication-agent-1[2359]: REQUEST
2020-04-02T21:30:44.884739-05:00 kadath polkit-kde-authentication-agent-1[2359]: Request:  "Password: "
2020-04-02T21:30:44.884872-05:00 kadath polkit-kde-authentication-agent-1[2359]: "Password: "

The filesystem that's trying to be mounted is the old partition where openSUSE 13.2 resides. It hasn't been listed in /etc/fstab since the upgrade to Leap 15.1.

I have an old copy of /etc/fstab -- saved as fstab.13.2 -- that contains a reference to that partition. Back in the 13.2 days, /dev/sdd2 was a swap partition along with /dev/sdf2. Those same swap partitions are still in used by Leap 15.1 though the disks are now known as /dev/sda and /dev/sdg. "swapon -s" tells me that all the swap partitions are accounted for so it surely can't be some attempt to add more swap space for me.

I located a few files under my home directory, under $HOME/.local, that contain references to that partition. Several of them seem to be akonadi-related (another reason for me to dislike that bit of software) but I have no idea what they're for:

Code:

.local/share/xorg/Xorg.0.log
.local/share/akonadi/db_data/akonadi/parttable.ibd
.local/share/akonadi/db_data/ib_logfile0
.local/share/akonadi/search_db/email/postlist.glass
.local/share/user-places.xbel

Most of these appear to be databases associated with emails (Shees... there are emails dating back to at least 2008... maybe older) so I cannot imagine that these have anything to do with last night's mount request/attempt. (And the references to "sdd2" appear to all be part of unique strings generated for the email process and not to actual disk partitions, i.e., "bh=oyQ2C/E80vNrKfY0hkmfzxzScto=; b=b2wsdd23mV6+4sJ7eeJQ4fO".)

Q1: Any ideas as to what could be trying to mount that filesystem?

Q2: And why? I don't need any monitoring of that filesystem. It won't be used again until the next OS upgrade/installation.

Q3: Is there a config file that I've missed that might contain a reference to this old partition? I found an old note that I'd migrated into my RedNotebook journal that refers to /dev/sdd2. It was part of /dev/md1 back in 2014. (Ancient history)

TIA...

mrmazda · 04-03-2020, 05:59 PM

Plasma/KDE5's config files getting splattered into the ~/.config/ tree instead of ~/.kde4/ was an abomination, a recipe for confusion and corruption. I think the guestimation that Akonadi's responsible for an interrogation that lead to the udisks2/polkit mount attempt is a good one. As sdd2 is not needed, I'd either wipe it, and/or make a noauto fstab entry for it, to prevent any further automagic access attempts. As to Q3, I suppose a question directed to the Akonadi developers would be the place to start looking for an answer.

rnturn · 04-04-2020, 12:00 PM

Quote:

Originally Posted by mrmazda

Plasma/KDE5's config files getting splattered into the ~/.config/ tree instead of ~/.kde4/ was an abomination, a recipe for confusion and corruption.

Oh how I wish there could be at least a little coordination amongst the desktop development teams for stuff like this. I'd love to see a tree where all applications could stash their thumbnails, say ".local/thumbnails/app1ication1, etc. It'd make keeping them out of backups, rsyncs, etc. so much easier.

Quote:

I think the guestimation that Akonadi's responsible for an interrogation that lead to the udisks2/polkit mount attempt is a good one. As sdd2 is not needed, I'd either wipe it, and/or make a noauto fstab entry for it, to prevent any further automagic access attempts. As to Q3, I suppose a question directed to the Akonadi developers would be the place to start looking for an answer.

I'm not convinced that Akonadi had much to do with the recent event since all the akonadi-related places where I found that device/partition mentioned turned out to be not device names. The disk/partition isn't even listed in /etc/fstab any more. So I'm wondering if this wasn't some automated scan of all devices/partitions that located it and tried to mount it. The question remains: what initiated that?

I usually leave the previous version's root partition (and, sometimes, /usr) around for a time after an upgrade just in case there's a old configuration file I need to refer to for a special setting. In this case, it's been going on a year so I think I can now wipe that partition and ready it for 15.2. (According to the roadmap, I may also have to update my LQ profile when it's released. :^D )

Cheers...

I'm going to mark this as "Solved" even though nothing definitive has been found to have been the cause of the mount request.