I saw this issue yesterday. Apparently udisks mis-identifies the stick as an ISO-9660 volume.

Can you try pasting the output of udisksctl info -b <partition> ?

Created attachment 730531 [details]
Output of udisksctl info -b /dev/sdb1

Comment on attachment 730531 [details]
Output of udisksctl info -b /dev/sdb1

> IdType:                     iso9660

Looks like it's being mis-identified.

It looks to me like a possible issue with udisks, which is used by Solid to query for the capabilities of the disk. udisksctl mount in fact fails in the same way. 

Reassigning.

Most likely a problem in the partition table and formatting of the key see the duplicate here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1046096

*** Bug 1046096 has been marked as a duplicate of this bug. ***

(In reply to Luca Beltrame from comment #4)
> It looks to me like a possible issue with udisks,

The only way I can reproduce this behavior is when I do *NOT* create filesystem on partition. Then filesystem on this partition gets misidentified (due to udev properties inherited by partition from containing block device). If I create filesystem on partition, it is also correctly shown by udev. and udiskctl

Neither of these bugs reports contains actual instructions how to reproduce it. Please provide exact steps how to do it on command line showing exact commands (or better capturing the whole session).

Of course the problem of leaked properties should be fixed too. In particular it means partition inherits iso9660 label unless it is explicitly set in partition filesystem. But it still *is* mounted here on XFCE.

Andrei, what information is missing from #1046096 for you to reproduce? Gparted being a GUI, provide command lines is tricky as I don't know how to use parted in CLI... All the described steps are straightforward, but I can be more thorough if you want:
- by "remove partitions", I mean select each partition and click on "Delete the partition", until they are all removed
- by "create a new one", I mean click on "Partition" > "New" > Select "fat32" as the partition type and enter "MYLABEL" in the label text field, then click on OK
- after all that, apply the changes (click on "Apply all operations").

Incidentally, have you tried to reproduce on KDE Plasma? Both bugs are reported within KDE Plasma. Since the buggy USB drives can be mounted using a "mount" command, there is a way to mount them. Should XFCE uses such a "working" way, it would not be sensitive to the bug.

(In reply to Pierre Bonamy from comment #8)
> 
> Incidentally, have you tried to reproduce on KDE Plasma? Both bugs are
> reported within KDE Plasma. Since the buggy USB drives can be mounted using
> a "mount" command, there is a way to mount them. Should XFCE uses such a
> "working" way, it would not be sensitive to the bug.

AFAIK, udisks2 is taking filesystem information from udev.
Can you attach the udev information from your usb key, e.g. the output of:

udevadm info -e

for the device and its partitions?

Created attachment 731366 [details]
Output of udevadm info -e /dev/sdb

Created attachment 731367 [details]
Output of udevadm info -e /dev/sdb1

I've uploaded the output of udevadm info -e on the other bug report to keep things clear:
https://bugzilla.suse.com/show_bug.cgi?id=1046096

What is the output of

blkid
wipefs -n /dev/sdb
wipefs -n /dev/sdb1

For me:

> blkid
/dev/sda1: SEC_TYPE="msdos" UUID="307F-1D79" TYPE="vfat" PARTLABEL="primary" PARTUUID="4d69599c-ff06-4188-988e-44ca03f77865"
/dev/sda2: UUID="ddb6812e-a1b4-4032-af68-10a22f7b00a3" TYPE="swap" PARTLABEL="primary" PARTUUID="a0188e55-538f-4faf-b795-39672d790c03"
/dev/sda3: UUID="83d1803d-f689-4f8e-9e5a-9dafb7e922bd" UUID_SUB="602cd6bc-b828-4635-8f35-d5e716ab76d0" TYPE="btrfs" PARTLABEL="primary" PARTUUID="f5842396-62ac-467c-a9d6-7b379fc42be1"
/dev/sda4: UUID="4e4d64ab-7346-4e90-9148-f5746d833c8f" TYPE="ext4" PARTLABEL="primary" PARTUUID="2dbcc165-5027-449f-85b3-54181e4d04c3"
/dev/sda5: UUID="f93d5edc-5a08-47f6-8f29-0b083addd4f0" TYPE="ext4" PARTLABEL="primary" PARTUUID="0dc56eec-5efd-4701-9d44-9b130701ac60"
/dev/sdb1: LABEL="EMTEC" UUID="AB71-6E1E" TYPE="vfat" PARTUUID="5d2e2084-01"

> wipefs -n /dev/sdb
offset               type
----------------------------------------------------------------
0x1fe                dos   [table de partitions]

0x8001               iso9660   [filesystem]
                     LABEL: openSUSE-Leap-42.2-NET-x86_64028
                     UUID:  2016-11-09-10-10-35-00

> sudo wipefs -n /dev/sdb1
offset               type
----------------------------------------------------------------
0x52                 vfat   [filesystem]
                     LABEL: EMTEC
                     UUID:  AB71-6E1E

I suspect that we have some udev rule that imports parent properties *after* device was probed; so values are overridden. As I do not see this problem it may be installed by some additional package. Could you run "grep -i import /usr/lib/udev/rules.d /etc/udev/rules.d" and upload output?

(In reply to Andrei Borzenkov from comment #15)
>grep -i import

grep -ir import of course.

Created attachment 731396 [details]
Output of blkid

Created attachment 731397 [details]
Output of wipefs -n /dev/sdb

Created attachment 731398 [details]
Output of wipefs -n /dev/sdb1

Created attachment 731399 [details]
Output of grep

Well, /usr/lib/udev/rules.d/61-persistent-storage-compat.rules comes after rule that imports blkid properties. Which package it belongs? You can try to disable it with "touch /etc/udev/rules.d/1-persistent-storage-compat.rules" then "udevadm control --reload-rules" or simply reboot.

That made no difference. It is still identified as Kubuntu 15.04

I meant to add that it still only mounts manually.

(In reply to Lucifer Watson from comment #23)
> I meant to add that it still only mounts manually.

Did you reboot? What is the output of "udevadm info -q all -n /dev/sdb1"?

No. I just reloaded the rules. I'll attach the requested details but I can't reboot at the moment so I'll try that later

Created attachment 731408 [details]
Output of udevadm after reloading rules

(In reply to Lucifer Watson from comment #25)
> No. I just reloaded the rules.

But did you reinsert USB stick so they are applied again to new device?

> But did you reinsert USB stick so they are applied again to new device?

Yes.

(In reply to Andrei Borzenkov from comment #21)
> /usr/lib/udev/rules.d/61-persistent-storage-compat.rules

I reproduced it now and yes, commenting out

ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"

does fix it.

Of course, it still leaks label and probably some other stuff (I did not check exactly).

It really should be more careful and import only those properties it actually needs.

(In reply to Andrei Borzenkov from comment #29)
> 
> It really should be more careful and import only those properties it
> actually needs.

Actually why it needs to import *anytying* in the first place? Everything has just been imported in 60-persistent-storage.rules.

(In reply to Andrei Borzenkov from comment #29)
> commenting out
> 
> ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
> 
> does fix it.


Yes that fixed it after reloading the rules.

Commenting this line out fixes the following for me:
- Label is now seen correctly by KDE/Plasma
- The USB stick can be mounted in KDE/Plasma

It doesn't fix the following:
- Gparted still see the partitions as iso9660 with the old label

I can verify that this bug is also present in Leap 42.3. Leap 42.2 does not have this issue.

*** Bug 1051940 has been marked as a duplicate of this bug. ***

(In reply to Mark Hounschell from comment #33)
> I can verify that this bug is also present in Leap 42.3. Leap 42.2 does not
> have this issue.

Then its a DIFFERENCE in the rules between 42.2 and 42.3.

As such, I'm not sure that this constitutes a bug when it's a difference in the installed configuration.  Both rules make sense.

Yes, its an inconsistency, but it could be argued that 42.3 was correcting an error in 42.2.

I've looked at my  hard disk which is outside the rules and OBVIOUSLY I get different results if I run blkid on /dev/sda and /ded/sda1.

Which is as it should be.

Inconsistency between releases that constituent corrections are sometimes a matter of opinion.

Let me ask an awkward question.

My main drive that my system is installed on, the 1Terabyte SATA, has three partitions.   I could equally buy a 1T  USB drive and format that with three, or more, partitions.  When I plug that in that partition should the KDE popup select?  

Whichever one, it might not be the one I want and hence it is "misidentified by the device notifier".
In this case, recognizing the device makes sense.

I can also confirm that a recent update to Leap 42.2 has also created this problem on Leap 42.2.

Anton,

"Let me ask an awkward question.

My main drive that my system is installed on, the 1Terabyte SATA, has three partitions.   I could equally buy a 1T  USB drive and format that with three, or more, partitions.  When I plug that in that partition should the KDE popup select?"

It should show ALL of them (/dev/sdX#). No matter what /dev/sdX says.

(In reply to Anton Aylward from comment #35)
> Let me ask an awkward question.
> 
> My main drive that my system is installed on, the 1Terabyte SATA, has three
> partitions.   I could equally buy a 1T  USB drive and format that with
> three, or more, partitions.  When I plug that in that partition should the
> KDE popup select?  
> 
> Whichever one, it might not be the one I want and hence it is "misidentified
> by the device notifier".
> In this case, recognizing the device makes sense.

Let me ask you an awkward question:

Would you expect the 1T USB drive to be correctly identified and mounted or not?

(In reply to Lucifer Watson from comment #38)
> (In reply to Anton Aylward from comment #35)
> > Let me ask an awkward question.
> > 
> > My main drive that my system is installed on, the 1Terabyte SATA, has three
> > partitions.   I could equally buy a 1T  USB drive and format that with
> > three, or more, partitions.  When I plug that in that partition should the
> > KDE popup select?  
> > 
> > Whichever one, it might not be the one I want and hence it is "misidentified
> > by the device notifier".
> > In this case, recognizing the device makes sense.
> 
> Let me ask you an awkward question:
> 
> Would you expect the 1T USB drive to be correctly identified and mounted or
> not?

You don't mount a DRIVE, you mount a partition.

Let us assume that the rules identify it as a USB drive.
in order to mount a partition it has to determine the partition table entries, gpt or whatever.  if there is more than one partition then a selection of which partition to use has to be made.

I repeat, you don't mount a drive, you mount a partition.
(or, if you're using LVM a LV, but lets not make this more complicated than it has to be)

I think that this has already been answered, the popup offers the user a choice, its not an automated decision.

(In reply to Anton Aylward from comment #39)
> You don't mount a DRIVE, you mount a partition.

I don't think your comments are helpful here at all.

Of course you normally mount a partition.
But the problem in this bug report is that the device notifier doesn't show any partitions because the drive is misidentified as CD by udisks2.

(In reply to Anton Aylward from comment #39)
> (In reply to Lucifer Watson from comment #38)
> > (In reply to Anton Aylward from comment #35)
> > > Let me ask an awkward question.
> > > 
> > > My main drive that my system is installed on, the 1Terabyte SATA, has three
> > > partitions.   I could equally buy a 1T  USB drive and format that with
> > > three, or more, partitions.  When I plug that in that partition should the
> > > KDE popup select?  
> > > 
> > > Whichever one, it might not be the one I want and hence it is "misidentified
> > > by the device notifier".
> > > In this case, recognizing the device makes sense.
> > 
> > Let me ask you an awkward question:
> > 
> > Would you expect the 1T USB drive to be correctly identified and mounted or
> > not?
> 
> You don't mount a DRIVE, you mount a partition.
> 
> Let us assume that the rules identify it as a USB drive.
> in order to mount a partition it has to determine the partition table
> entries, gpt or whatever.  if there is more than one partition then a
> selection of which partition to use has to be made.
> 
> I repeat, you don't mount a drive, you mount a partition.
> (or, if you're using LVM a LV, but lets not make this more complicated than
> it has to be)
> 
> I think that this has already been answered, the popup offers the user a
> choice, its not an automated decision.

I plug in my USB key with the line <ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"> in the file /usr/lib/udev/rules.d/61-persistent-storage-compat.rules uncommented and the device is mis-identified and not mounted. See the image below.

https://i.imgur.com/5OTuz0f.png

I comment out that line and reload the rules then plug in the same key and voilà! it is recognised and mounted correctly. See the image below.

https://i.imgur.com/r8kIVrp.png

If a repeatable and consistent error doesn't match your definition of a bug, could you please explain what does.

(In reply to Wolfgang Bauer from comment #40)
> But the problem in this bug report is that the device notifier doesn't show
> any partitions because the drive is misidentified as CD by udisks2.

The udisks2 issue should be fixed by comment#29. Can you confirm?
But I doubt that udisks2 has any influnce on gparted.
The issue reported in comment#32 is most probably caused by udev.

(In reply to Thomas Blume from comment #42)
> (In reply to Wolfgang Bauer from comment #40)
> > But the problem in this bug report is that the device notifier doesn't show
> > any partitions because the drive is misidentified as CD by udisks2.
> 
> The udisks2 issue should be fixed by comment#29. Can you confirm?
> But I doubt that udisks2 has any influnce on gparted.
> The issue reported in comment#32 is most probably caused by udev.

Yes, you comment out the line and things work in my case. But it only works until an update replaces the file, thus I wouldn't consider it a fix, more a work-around

(In reply to Thomas Blume from comment #42)
> (In reply to Wolfgang Bauer from comment #40)
> > But the problem in this bug report is that the device notifier doesn't show
> > any partitions because the drive is misidentified as CD by udisks2.
> 
> The udisks2 issue should be fixed by comment#29. Can you confirm?

I can confirm that it fixes the issue on Leap 42.3 and a recently updated Leap 42.2 but I have no TW installation to test it on.

(In reply to Mark Hounschell from comment #44)
> (In reply to Thomas Blume from comment #42)
> > (In reply to Wolfgang Bauer from comment #40)
> > > But the problem in this bug report is that the device notifier doesn't show
> > > any partitions because the drive is misidentified as CD by udisks2.
> > 
> > The udisks2 issue should be fixed by comment#29. Can you confirm?
> 
> I can confirm that it fixes the issue on Leap 42.3 and a recently updated
> Leap 42.2 but I have no TW installation to test it on.


/usr/lib/udev/rules.d/61-persistent-storage-compat.rules

is shipped by the udev package and udev is part of systemd, reassigning accordingly.

*** Bug 1053169 has been marked as a duplicate of this bug. ***

*** Bug 1054629 has been marked as a duplicate of this bug. ***

*** Bug 1055887 has been marked as a duplicate of this bug. ***

(In reply to Andrei Borzenkov from comment #30)
> Actually why it needs to import *anytying* in the first place? Everything
> has just been imported in 60-persistent-storage.rules.

It's just wrong and boggus...

It was initially done because 61-persistent-storage-compat.rules had a different name and was applied before 60-persistent-storage.rules.

But once it switched to 61-persistent-storage-compat.rules filename, the rule should have been dropped.

Currently 61-persistent-storage-compat.rules only uses ID_BUS which is normally already set by 60-persistent-storage.rules. Therefore dropping the "import anything" rule like you suggested should be the correct fix.

I'll fix it and release a new update ASAP.

Thanks all for spotting and sorting this out.

*** Bug 1049760 has been marked as a duplicate of this bug. ***

The fix has been submitted to both Factory and SLE and should be released pretty quickly. therefore closing.

Again thanks all for spotting and finding the culprit and sorry for the troubles.

SUSE-RU-2017:2330-1: An update that has 5 recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1045384,1045987,1046268,1047379,1048605
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP3 (src):    systemd-228-150.15.2
SUSE Linux Enterprise Software Development Kit 12-SP2 (src):    systemd-228-150.15.2
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    systemd-228-150.15.2
SUSE Linux Enterprise Server 12-SP3 (src):    systemd-228-150.15.2
SUSE Linux Enterprise Server 12-SP2 (src):    systemd-228-150.15.2
SUSE Linux Enterprise Desktop 12-SP3 (src):    systemd-228-150.15.2
SUSE Linux Enterprise Desktop 12-SP2 (src):    systemd-228-150.15.2
SUSE Container as a Service Platform ALL (src):    systemd-228-150.15.2
OpenStack Cloud Magnum Orchestration 7 (src):    systemd-228-150.15.2

As far as I can see, no new version has appeared in opensuse 42.3 to solve this problem. Is this normal ?

(In reply to François Valenduc from comment #55)
> As far as I can see, no new version has appeared in opensuse 42.3 to solve
> this problem. Is this normal ?

Yes.
It needed to be released for SLE first, that's the normal workflow for packages coming from SLE.

An update for Leap is running now and should get released in the next days:
https://build.opensuse.org/project/show/openSUSE:Maintenance:7229

openSUSE-RU-2017:2365-1: An update that has 5 recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1045384,1045987,1046268,1047379,1048605
CVE References: 
Sources used:
openSUSE Leap 42.3 (src):    systemd-228-35.1, systemd-mini-228-35.1
openSUSE Leap 42.2 (src):    systemd-228-25.15.1, systemd-mini-228-25.15.1

SUSE-SU-2017:2470-1: An update that solves 18 vulnerabilities and has 46 fixes is now available.

Category: security (important)
Bug References: 1004995,1009745,1014471,1017420,1019637,1026825,1027079,1027688,1027908,1028281,1028723,1029523,1031756,1032706,1033236,1035062,1036659,1038132,1038444,1038984,1042392,1043218,1043333,1044095,1044107,1044175,1044840,1045384,1045735,1045987,1046268,1046417,1046659,1046853,1046858,1047008,1047236,1047240,1047310,1047379,1047785,1047964,1047965,1048315,1048483,1048605,1048679,1048715,1049344,1050396,1050484,1051626,1051643,1051644,1052030,1052759,1053409,874665,902364,938657,944903,954661,960820,963041
CVE References: CVE-2013-7459,CVE-2016-9063,CVE-2017-1000100,CVE-2017-1000101,CVE-2017-10684,CVE-2017-10685,CVE-2017-11112,CVE-2017-11113,CVE-2017-3308,CVE-2017-3309,CVE-2017-3453,CVE-2017-3456,CVE-2017-3464,CVE-2017-7435,CVE-2017-7436,CVE-2017-8872,CVE-2017-9233,CVE-2017-9269
Sources used:
SUSE Container as a Service Platform ALL (src):    caasp-container-manifests-0.0.0+git_r155_93e40ab-2.3.3, container-feeder-0.0.0+20170901.git_r55_17ecbd3-2.3.3, sles12-mariadb-docker-image-1.1.0-2.3.10, sles12-pause-docker-image-1.1.0-2.3.11, sles12-pv-recycler-node-docker-image-1.1.0-2.3.10, sles12-salt-api-docker-image-1.1.0-2.3.9, sles12-salt-master-docker-image-1.1.0-4.3.10, sles12-salt-minion-docker-image-1.1.0-2.3.8, sles12-velum-docker-image-1.1.0-4.3.9