Bug 1572752 - Mounting a USB multi-volume mass-storage device no longer causes Thunar to offer mount points for all volumes
Summary: Mounting a USB multi-volume mass-storage device no longer causes Thunar to o...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 28
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-27 18:00 UTC by Martin Gregorie
Modified: 2019-09-14 19:12 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-04 13:25:01 UTC
Type: Bug


Attachments (Terms of Use)
Requested dmesg output (89.19 KB, text/plain)
2018-05-24 10:19 UTC, Martin Gregorie
no flags Details

Description Martin Gregorie 2018-04-27 18:00:54 UTC
Description of problem:
=======================
Under Fedora 26 mounting a multi-volume device, e.g a Medion S.3747 satellite navigation device, with both internal memory and a micro-SD card fitted used to cause Thunar to display two mountable icons, one for each storage device in the Medion. Under Fedora 27 only the internal storage is mountable despite the
Medion being able to access the micro-SD card and run programs on it.  

Version-Release number of selected component (if applicable):
=============================================================
Linux version 4.15.17-300.fc27.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) #1 SMP Thu Apr 12 18:19:17 UTC 2018

Thunar 1.6.15

How reproducible:
=================
Seems to happen every time I connect the satnav and try to access its micro-SD card. 

Steps to Reproduce:
===================
1. Make sure the PNA is charged and has an SD card in its SD card
   slot.

2. Plug the PNA into the Fedora system's USB port, boot it and 
   switch it into file transfer mode

Actual results:
===============
The F27 connects successfully to the PNA, starts Thunar but only one icon is shown, linked to the PNA's internal non-volatile storage.

Expected results:
=================
Thunar should start up and show two icons for storage in the PNA:
- one connected to the devices's internal non-volatile memory
- one for a micro-SD card in the PNA's micro-SD card slot. 

Clicking the one linked to the micro-SD card should mount the card and allow files to be transferred to and from it. 

Additional info:
================
Last year I was regularly doing this with Medion S.3747 PNA fitted with a micro-SD card and connecting it to a Lenovo T440 running Fedora 26.

This is a satnav I only use in summer: F26 was mounting both internal storage and the SD card in October 2017, but today I needed to update the SD-card but was unable to see it because only the satnav's internal storage was offered for mounting.

This should work with to any WinCE PNA with a USB connection and both internal
non-volatile menord plus an SD card slot provided that it has the ability to expose its internal and attached storage as mountable partitions.

Comment 1 Karsten Hopp 2018-05-02 07:47:39 UTC
storage-devices is not the correct component for this as it is a F27 module available only in the Boltron test release. Reassigning to Thunar for further review.

Comment 2 Kevin Fenzi 2018-05-03 03:22:41 UTC
Can you attach the output of 'lsblk' and 'sudo blkid' with the device attached?

Comment 3 Martin Gregorie 2018-05-03 07:31:42 UTC
I'm now seeing both the volumes I expected to see when my Medion S.3747 is connected. It was apparently fixed by the F27 update I ran about 6 hours after reporting this problem, but anyway, here are the attachments you asked for:

Comment 4 Martin Gregorie 2018-05-03 07:35:50 UTC
#
# sdb looks like the Medion's internal storage
# sdc looks like the SD card (1 2GB one) respectively
#
$ lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                          8:0    0 465.8G  0 disk  
├─sda1                                       8:1    0 390.1G  0 part  /home
├─sda2                                       8:2    0  48.8G  0 part  /
├─sda3                                       8:3    0  16.1G  0 part  [SWAP]
├─sda4                                       8:4    0     1K  0 part  
├─sda5                                       8:5    0   9.8G  0 part  
│ └─luks-b6b39070-edcd-4a4c-9c8b-6dff349e1ca9
│                                          253:0    0   9.8G  0 crypt /sensitive
└─sda6                                       8:6    0   999M  0 part  /boot
sdb                                          8:16   1   3.5G  0 disk  
sdc                                          8:32   1   1.9G  0 disk  


$ sudo blkid
[sudo] password for my_user: 
/dev/sda1: UUID="9bcff37c-ab24-42e3-90a6-6c47c80e19a0" TYPE="ext3" PARTUUID="ef54fdda-01"
/dev/sda2: UUID="10d42c1c-8733-45e5-9d27-76d659716011" TYPE="ext4" PARTUUID="ef54fdda-02"
/dev/sda3: UUID="bad5f287-f471-4d89-880a-998aaf6072a2" TYPE="swap" PARTUUID="ef54fdda-03"
/dev/sda5: UUID="b6b39070-edcd-4a4c-9c8b-6dff349e1ca9" TYPE="crypto_LUKS" PARTUUID="ef54fdda-05"
/dev/sda6: LABEL="/boot" UUID="f7ba3ac0-815c-4061-9b0e-8324b9c04444" TYPE="ext4" PARTUUID="ef54fdda-06"
/dev/mapper/luks-b6b39070-edcd-4a4c-9c8b-6dff349e1ca9: UUID="b7f726d6-be02-4001-940e-bfeb676d1fe5" TYPE="ext3"
/dev/sdb: LABEL="S3X47Device" UUID="081C-0007" TYPE="vfat"
/dev/sdc: SEC_TYPE="msdos" UUID="6E3D-429E" TYPE="vfat"

Comment 5 Kevin Fenzi 2018-05-03 16:20:10 UTC
Odd. It all looks ok there... shall we just close this now?

Please re-open if you see it again...

Comment 6 Martin Gregorie 2018-05-23 17:43:19 UTC
Please re-open this bug. I haven't needed to update my Medion S.3747 PNA until today. 

However now I need to update data files on it, but this bug has reappeared and is behaving exactly as I previously described: Thunar is only allowing its internal memory to be seen although WinCE is successfully accessing the microSD card.

This time to output of lsblk and blkid do not show any sign on the microSD card (last time it appeared as sdc). Here are the current outputs

$ lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                          8:0    0 465.8G  0 disk  
├─sda1                                       8:1    0 390.1G  0 part  /home
├─sda2                                       8:2    0  48.8G  0 part  /
├─sda3                                       8:3    0  16.1G  0 part  [SWAP]
├─sda4                                       8:4    0     1K  0 part  
├─sda5                                       8:5    0   9.8G  0 part  
│ └─luks-b6b39070-edcd-4a4c-9c8b-6dff349e1ca9
│                                          253:0    0   9.8G  0 crypt /sensitive
└─sda6                                       8:6    0   999M  0 part  /boot
sdb                                          8:16   1   3.5G  0 disk  
$ sudo blkid
[sudo] password for kiwi: 
/dev/sda1: UUID="9bcff37c-ab24-42e3-90a6-6c47c80e19a0" TYPE="ext3" PARTUUID="ef54fdda-01"
/dev/sda2: UUID="10d42c1c-8733-45e5-9d27-76d659716011" TYPE="ext4" PARTUUID="ef54fdda-02"
/dev/sda3: UUID="bad5f287-f471-4d89-880a-998aaf6072a2" TYPE="swap" PARTUUID="ef54fdda-03"
/dev/sda5: UUID="b6b39070-edcd-4a4c-9c8b-6dff349e1ca9" TYPE="crypto_LUKS" PARTUUID="ef54fdda-05"
/dev/sda6: LABEL="/boot" UUID="f7ba3ac0-815c-4061-9b0e-8324b9c04444" TYPE="ext4" PARTUUID="ef54fdda-06"
/dev/mapper/luks-b6b39070-edcd-4a4c-9c8b-6dff349e1ca9: UUID="b7f726d6-be02-4001-940e-bfeb676d1fe5" TYPE="ext3"
/dev/sdb: LABEL="S3X47Device" UUID="081C-0007" TYPE="vfat"
$

Comment 7 Kevin Fenzi 2018-05-24 01:25:57 UTC
Can you attach the output of 'dmesg' ?

Comment 8 Martin Gregorie 2018-05-24 10:19:24 UTC
Created attachment 1441024 [details]
Requested dmesg output

Comment 9 Martin Gregorie 2018-05-24 10:25:00 UTC
This dmesg output is from a reboot after the first couple of failure of Thunar to show the Medion's microSD card. I have not rebooted this laptop since then. The recent lsblk and blkid output was produced after that reboot.

Comment 10 Kevin Fenzi 2018-05-25 19:59:07 UTC
It looks like for some reason it detected it as mmcblk0p1

if you do a 'sudo mount /dev/mmcblk0p1 /mnt' does that show the files you were looking for? I have no idea what causes it to see something as a mmblk device vs a sd device. Moving to kernel folks... but it might be systemd-udevd.

Comment 11 Martin Gregorie 2018-05-25 21:39:22 UTC
No, that just says /dev/mmcblk0p1 doesn't exist:

$ sudo mount /dev/mmcblk0p1 /mnt
mount: /mnt: special device /dev/mmcblk0p1 does not exist.

It thinks sdb is this:
usb-General_Flash_Disk_Drive_Microsoft_USB_Mass_Storage_product-0:0

which would be right for the Medion internal flash. I can't see anything of else interest in /dev or /proc but I could have missed something.

Comment 12 Justin M. Forbes 2018-07-23 15:16:13 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 13 Martin Gregorie 2018-08-03 13:40:16 UTC
I am now running F28 (vmlinuz-4.17.4-200.fc28.x86_64), installed on 2018:07:13. 

This problem is still a current nuisance because it prevents data and programs on a microSD card on the Medion S.3747being updated via a USB connection because the bug prevents the SD card from being accessed. 

Background on why this is an issue for me
=========================================
The SD slot is under the Medion's removable battery, both being under a screwed-on backplate: both must be removed and the micro-SD card removed and inserted into an SD card adapter for direct updating on the laptop. The process must then be reversed after the card has been updated. 

While this prevents the card from being lost, and as is a GOOD THING, its is much slower and more fiddly than simply connecting the Marion via a USB cable, booting it and doing the update.

These uploads are a regular thing. I need to do it each time I go flying because it installs a file of airspace NOTAMS and, less frequently, a file of 'permanent' restricted airspace for use by navigation software running on the Medion. In the UK NOTAMS change on a daily bases and 'fixed airspace' is updated every month.

Comment 14 Laura Abbott 2018-10-01 21:21:46 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.18.10-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 28 or Fedora 29, and are still experiencing this issue, please change the version to Fedora 28 or 29.
 
If you experience different issues, please open a new bug report for those.

Comment 15 Martin Gregorie 2018-10-01 22:25:18 UTC
This problem still exists, but its somewhat flaky - somewhere around 30-40% of connection attempts succeed in allowing access to both the built-in storage device and the SD card in my Medion S.3747 - the rest only make the built-in storage visible.

Unfortunately, its the SD card in its inaccessible slot under the S.3747 battery that I need to upload map files to and download logs from.

Comment 16 Justin M. Forbes 2019-01-29 16:25:30 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.20.5-100.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.

If you experience different issues, please open a new bug report for those.

Comment 17 Martin Gregorie 2019-02-01 20:49:21 UTC
I've just checked the status of this bug and am happy to report that today, running 

Linux version 4.20.5-100.fc28.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 8.2.1 20181215 (Red Hat 8.2.1-6) (GCC)) #1 SMP Mon Jan 28 19:29:44 UTC 2019

following a "dnf upgrade" run this afternoon at about 1500 on 1 Feb 2019 followed by a reboot, I am now able to see and access files on both storage units (the built-in SSD storage and the SD-card in my Medion S3747 PNA. 

Good job. Thanks, folks.

Comment 18 Justin M. Forbes 2019-02-04 13:25:01 UTC
Thanks for letting us know

Comment 19 Martin Gregorie 2019-09-14 19:12:08 UTC
Please re=open this bug. It reappeared two days ago when I ran a dnf upgrade on 12 September 2019.

The recurrence makes Fedora 30 behave as though this bug has never been fixed. When a USB link to my Medion S3747 is established only the internal mass storage is visible to Thunar. The S3747 also has a micro-SD card installed which should also be visible to Thunar but is not now visible. The reason I made the connection was to update data for an application which is installed on the micro-SD card and stores application-specific data (maps, aviation-related restricted airspace and NOTAMs) on the micro-SD card.

This sudden invisiblity of the SD card is what caused bug 1572752 to be raised in 03April18.

It was closed 04Feb19 when a upgrade included a fix and both mass storage devices again became visible when the S3747 was connected to F29 by USB.

So, now its disapointing to see that this bug has reappeared with the upgrade I did on 12Sep19, only seven months later.


Note You need to log in before you can comment on or make changes to this bug.