USB drives with identical serial numbers (again!)

[BreakingSiam]

I am trying to resolve a situation with udisks2 and inserting multiple USB disks with identical serial numbers. I am not using udev.

I have written my own daemon which creates a GDBusObjectManager and uses g_signal_connect(manager,"object-added",...) to receive events directly via dbus.

Now consider the following situation:

I have a number of USB ports, and I plug in microSD to USB adapters into each port. Every adapter has an identical serial number, and they all map to the same identifier:

/org/freedesktop/UDisks2/drives/Generic__SD_2fMMC_2009081519810

The problem is I never see a drive event when plugging in a second USB drive with an identical serial number. I get disk events (the sd? block device being added/removed), but not drive events. These are subtly different things which I am tracking at different places for different purposes, and my code relies on being able to match them one for one.

So I am left with a challenge. How do I get the kernel to tell me about duplicate drives being inserted/removed? I understand from reading previous issues dealing with this topic that the issue is with multipath. I don't need multipath for my application, and would prefer to figure out how to disable it entirely on the USB bus. In any case, I am stuck right now because the event is never even reported to me. Is there something I can configure to change how this is handled?

Alternatively, can anyone explain exactly how udisks/dbus/systemd actually receives events from the linux kernel, and what sources I will need to patch in order to get object_added/object_removed events for every USB drive inserted (not only the creation of the block devices), even if they all have identical serial numbers?

I apologize if this is not the appropriate venue for this question. I have tried to understand the source code but genuinely don't know where to begin. Any advice is appreciated.

[tbzatek]

I am not using udev.

UDisks relies on udev to receive and process uevents, perform additional probing, before the information get to UDisks. What do you mean by not using udev?

I have a number of USB ports, and I plug in microSD to USB adapters into each port. Every adapter has an identical serial number, and they all map to the same identifier:

/org/freedesktop/UDisks2/drives/Generic__SD_2fMMC_2009081519810

That's likely another occurrence of #1225 - multiple block devices treated as multipath or, rather, the calculated VPD ID being equal. The rest of your questions only point to this single bug. This is a bug that needs to be fixed.

[BreakingSiam]

Thank you for your response. I'm not really sure how everything works, so please forgive me for being unclear. What I mean to say is that I am not using any udev rules. udev doesn't mount the drives on this system. I'm simply using udisks and listening for DBUS events. I was unaware udev played any part in this. I thought udev was simply a parallel/alternate interface for receiving DBUS events and running scripts in a more convenient way for users. I would really like to understand the complete sequence an event takes. From the XHCI driver in the kernel being notified that a drive has been plugged in, until udisks finally notifies me about it. Are you saying that the kernel reports this event first to udev, udev processes it, and that it is udev (not the kernel) that actually sends the event out on DBUS for udisks to read? I thought udisks/DBUS received events directly from the kernel? Can you point me to any documentation which explains the details of how this works?

…

On Thu, May 2, 2024 at 10:37 PM Tomáš Bžatek ***@***.***> wrote: I am not using udev. UDisks relies on udev to receive and process uevents, perform additional probing, before the information get to UDisks. What do you mean by not using udev? I have a number of USB ports, and I plug in microSD to USB adapters into each port. Every adapter has an identical serial number, and they all map to the same identifier: /org/freedesktop/UDisks2/drives/Generic__SD_2fMMC_2009081519810 That's likely another occurrence of #1225 <#1225> - multiple block devices treated as multipath or, rather, the calculated VPD ID being equal. The rest of your questions only point to this single bug. This is a bug that needs to be fixed. — Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIGEWL3UQD7B3OWNP37MFNDZAJMTHAVCNFSM6AAAAABGRFQ6F2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQHAZDONZQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>