Can I avoid this error: Houston, we've had a problem. duplicate key value violates unique constraint "storageadmin_disk_name_key"

Troubleshooting
1

I want to connect 5 drive USB box. I end up with following error:
##### Houston, we’ve had a problem.
duplicate key value violates unique constraint “storageadmin_disk_name_key” DETAIL: Key (name)=(wwn-0x3001234567891234) already exists.

I see one issue with drives, box replace all serial numbers to SERIAL=“0123456789ABCDEF”

NAME=“sdb” MODEL=“Generic_DISK00” SERIAL=“0123456789ABCDEF” SIZE=“1.8T” TRAN="" VENDOR=“JMicron " HCTL=“0:0:0:1” TYPE=“disk” FSTYPE=”" LABEL="" UUID=""
NAME=“sdd” MODEL=“Generic_DISK01” SERIAL=“0123456789ABCDEF” SIZE=“1.8T” TRAN="" VENDOR=“JMicron " HCTL=“0:0:0:3” TYPE=“disk” FSTYPE=”" LABEL="" UUID=""
NAME=“sde” MODEL=“Generic_DISK02” SERIAL=“0123456789ABCDEF” SIZE=“3.6T” TRAN="" VENDOR=“JMicron " HCTL=“0:0:0:4” TYPE=“disk” FSTYPE=”" LABEL="" UUID=""
NAME=“sdf” MODEL=“Generic_DISK03” SERIAL=“0123456789ABCDEF” SIZE=“1.8T” TRAN="" VENDOR=“JMicron " HCTL=“0:0:0:5” TYPE=“disk” FSTYPE=”" LABEL="" UUID=""

Is there any workaround?

2 Likes
2

@Miyuki Hello again.

This one is a tricky one. If the external enclosure if obfuscating / miss-representing the serial numbers of the indivicual drives then we are in a not compatible hardware realm. Rockstor must absolutely have access to unique serial numbers as they are the only way to tell one drive from another. Enclosures that do this are in a sense broken by design.

Hope may be had if the enclosure has some settings via firmware or dip switches that can change this broken behaviour. They are in a very real sense trying to present all drives as one by mashing / re-writing their serial numbers into one. We have seen this before and have added a number of exclusions as a result to avoid the poor user experience.

Can you give us details of this enclosure and let us know if you can find any work-arounds via settings etc on or in the device?

These are the exceptions we have to date:

With the last update of this against this issue:
https://github.com/rockstor/rockstor-core/issues/2318
linking to the original issue:
https://github.com/rockstor/rockstor-core/issues/2316
and the changes were in pull request:
https://github.com/rockstor/rockstor-core/pull/2320

Details here as we may need to do the same for your enclosure. Not this simple indicates the enclosure as non usable, it doesn’t allow for it’s use as it’s essentially miss-representing the hardware. We need to see the individual drives for things to make sense. And we track them via their serial numbers.

The following technical wiki entry explains this in more detail and is aimed at developers really but my be of interest as to why we take this stance:

So thanks for the report and do let us know what device you are seeing this on and if you manage to ‘fix’ this behaviour via hardware configuration or what-ever. There is a chance that a custom udev rule could assign serials but would be they according to drive, or drive slot. This must be understood and this enclouse may obfoscate other elements of it’s hardware. All a little tricky.

Hope that helps at least from a perspective point of view.

1 Like
3

It is one of those “cheap” JMS567 based enclosures (Even when Orico one is pretty expensive)
I just passed drives alone to Rockstor VM so it might not be detested as one
It have no settings at all
I will move drives to internal SAS but I wanted this for testing as I have just 4 spare ports

3 Likes
4

@Miyuki Thanks for the info. I’ve created the following issue to add your serial findings to our code as per the last change associated with another JSM567 controller.

https://github.com/rockstor/rockstor-core/issues/2330

Thanks again for the report.

3 Likes