Value too long for type character varying(128)

Support
1

Brief description of the problem

Web interface errors when trying to scan for disks.

Detailed step by step instructions to reproduce the problem

Browse to disk section and no disks are displayed. Click rescan button and received error

Web-UI screenshot

image
image1372×553 52.5 KB

Error Traceback provided on the Web-UI

Traceback (most recent call last): File "/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py", line 41, in _handle_exception yield File "/opt/rockstor/src/rockstor/storageadmin/views/disk.py", line 383, in post return self._update_disk_state() File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/utils/decorators.py", line 145, in inner return func(*args, **kwargs) File "/opt/rockstor/src/rockstor/storageadmin/views/disk.py", line 322, in _update_disk_state p.disk_set.add(dob) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/related.py", line 750, in add obj.save() File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py", line 734, in save force_update=force_update, update_fields=update_fields) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py", line 762, in save_base updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py", line 846, in _save_table result = self._do_insert(cls._base_manager, using, fields, update_pk, raw) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py", line 885, in _do_insert using=using, raw=raw) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/manager.py", line 127, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py", line 920, in _insert return query.get_compiler(using=using).execute_sql(return_id) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/compiler.py", line 974, in execute_sql cursor.execute(sql, params) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/utils.py", line 98, in __exit__ six.reraise(dj_exc_type, dj_exc_value, traceback) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) DataError: value too long for type character varying(128)
2

@Squeakz Welcome to the Rockstor community.

We haven’t had a Disk model limitation error of this sort for quite some time now. And the only field that has a limit as indicated in your error reported:

i.e. 128 characters; is the name field:

to help with assessing if this is the issue could you supply the output of the following command run as root:

ls -la /dev/disk/by-id/

I suspect it will have some by-id device names that are longer than 128 characters. This is really very unusual and is the first report of exceeding this name limit that we have had. Could you also give us any information about the system on which you have Rockstor installed. It may be obvious from these names if it turns out that is the problem.

Your options are to either remove the ‘problem name’ device from the system, if that turns out to be the cause, or alter that 128 in the above referenced code and rebuild your instance of Rockstor. This is non trivial and will delete your configuration but then this is most likely a fresh install anyway. And if you are to go to the lengths of doing a source build you may as well use the most up to date code. Setting up a development build of Rockstor (a build from source install) is covered in the following:

Contributing to Rockstor - Overview

But that is really a last resort as we should first prove this is the actual fault. Lets start with the output of the above ls command and we can take it from there. It may just be that there is a removable device that is not required, or if you are running in a virtual machine, the possibility to rename the problematic device.

Also confirming your Rockstor install version would also be helpfull, ie:

yum info rockstor

But later versions have had not reason to expand this value so if it is the name field in the disk model then any updates wont help, at least until we fix this; once we have narrowed it down and recognised it as a needed fix. It may just be a rogue device that can be removed, at least for the time being.

Thanks for your report. I look forward to the output of that command in the hope that it narrows down the cause of hitting that 128 char limit in the disk model. Quite a curiosity.

3

Here is the output. It looks like it is the USB flash drive that the OS is installed to.

[root@scu-san-01 ~]# ls -la /dev/disk/by-id/
total 0
drwxr-xr-x 2 root root 360 Mar 15 19:54 .
drwxr-xr-x 6 root root 120 Mar 15 19:53 …
lrwxrwxrwx 1 root root 9 Mar 15 19:54 scsi-35000a7203006bd33 -> …/…/sdc
lrwxrwxrwx 1 root root 9 Mar 15 19:54 scsi-35000a7203006bd35 -> …/…/sdb
lrwxrwxrwx 1 root root 9 Mar 15 19:54 scsi-35000cca04e093e5c -> …/…/sdd
lrwxrwxrwx 1 root root 9 Mar 15 19:54 scsi-35000cca04e09c214 -> …/…/sde
lrwxrwxrwx 1 root root 9 Mar 15 19:54 scsi-35000cca04e491244 -> …/…/sdg
lrwxrwxrwx 1 root root 9 Mar 15 19:54 scsi-35000cca04e49198c -> …/…/sdf
lrwxrwxrwx 1 root root 9 Mar 15 19:54 usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0 -> …/…/sda
lrwxrwxrwx 1 root root 10 Mar 15 19:54 usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0-part1 -> …/…/sda1
lrwxrwxrwx 1 root root 10 Mar 15 19:54 usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0-part2 -> …/…/sda2
lrwxrwxrwx 1 root root 10 Mar 15 19:54 usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0-part3 -> …/…/sda3
lrwxrwxrwx 1 root root 9 Mar 15 19:54 wwn-0x5000a7203006bd33 -> …/…/sdc
lrwxrwxrwx 1 root root 9 Mar 15 19:54 wwn-0x5000a7203006bd35 -> …/…/sdb
lrwxrwxrwx 1 root root 9 Mar 15 19:54 wwn-0x5000cca04e093e5c -> …/…/sdd
lrwxrwxrwx 1 root root 9 Mar 15 19:54 wwn-0x5000cca04e09c214 -> …/…/sde
lrwxrwxrwx 1 root root 9 Mar 15 19:54 wwn-0x5000cca04e491244 -> …/…/sdg
lrwxrwxrwx 1 root root 9 Mar 15 19:54 wwn-0x5000cca04e49198c -> …/…/sdf

4

Here is the Rockstor version
[root@scu-san-01 ~]# yum info rockstor
Loaded plugins: changelog, fastestmirror
Loading mirror speeds from cached hostfile

5

Here is the udev information on the drive if it helps.
[root@scu-san-01 ~]# udevadm info --name=/dev/sda --query=property
DEVLINKS=/dev/disk/by-id/usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0
DEVNAME=/dev/sda
DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/host7/target7:0:0/7:0:0:0/block/sda
DEVTYPE=disk
ID_BUS=usb
ID_INSTANCE=0:0
ID_MODEL=Ultra_Fit
ID_MODEL_ENC=Ultra\x20Fit\x20\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=5583
ID_PART_TABLE_TYPE=dos
ID_PATH=pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_1d_7-usb-0_2_1_0-scsi-0_0_0_0
ID_REVISION=1.00
ID_SERIAL=SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0
ID_SERIAL_SHORT=01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e
ID_TYPE=disk
ID_USB_DRIVER=usb-storage
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=SanDisk
ID_VENDOR_ENC=SanDisk\x20
ID_VENDOR_ID=0781
MAJOR=8
MINOR=0
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=844444

6

@Squeakz OK, this is all good info and as you say it looks like your SanDisk Ultra Fit is the culprit.

base by-id device name of:

usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0

looks to be 146 chars long which is already too long four our 128 character database field.

And the partition names are of course even longer:

usb-SanDisk_Ultra_Fit_01016e4266c0428a0f3d6112e8601dca97338db1da5fdd3914c0314da7cd9fd52bb100000000000000000000ae976af7ff0fb700835581079ba4b94e-0:0-part3

looks like 152 chars long.

Those are some long device names.

Interestingly our prior record was also a Sandisk device:

A SanDisk Extreme USB 3.0 at 50 characters long. But I’ve just had a look at an older Cruzer Blade I have here (too slow for Rockstor system disk use though) and it’s 55 characters with partition. So we have had previously a factor of > 2 safety margin.

So thanks, this does explain the error your seeing. Options:

  1. Building from source with that ‘128’ changed to say ‘192’ prior to doing a fresh build, after first uninstalling your current rockstor rpm and wiping the /opt/rockstor dir of course. I.e. building in /opt/rockstor-dev from current GitHub master.
  2. Use another device with a shorter name!

So (2) is the easier option. Can’t give you a hot fix for this really as the device name is pretty low level and it’s too risky to do a quick hack. You might be able to fathom a udev hack that provides a shorter name for this device but that’s a little risky too.

I’ve created the following GitHub issue as a result of this thread:

The fix for this won’t take long, just needs to be put in line with our existing db migrations in pending pull requests, but I’m currently busy working on a self service app for stable subscribers to edit their own appliance id’s for use during re-install.

I’d suggest going with a different USB stick for the time being and hopefully we can have this sorted soon. I was thinking of trying one of these newer devices out myself so your report is quite timely.

Thanks for your time and effort on reporting this issue and helping to get to the cause. At least we know what’s tripping it now.

7

@Squeakz Hello again. I’m afraid your reported device hasn’t yet been accommodated for but re:

I have just had the occasion to try out a:
SanDisk Ultra Fit 64GB USB 3.1
which I got to replicate your issue locally, plus I like these more compact designs and was trying to find one with adequate speed, and hopefully durability, for Rockstor system drive use. Don’t yet know if it suites but reporting on name issue first. However the one I got did not have a really long by-id name, slightly longer that our prior record but still well within our current code limit. And so works as intended in that regard.

Just to let you know, I suspect yours is the usb 3.0 variant. To help others avoid this problematic device for the time being could you report on it’s inscription code.

Is it by chance a:
SDCZ43

Mine is a 64GB variant and inscribed thus:
SDCZ430-064G
and is all black rather than the usb 3.0’s black and silver look.

I have updated the GitHub issue we have open for this with these details.

Hope that helps.

8

Mine is a SDCZ430-064G and is all black.

9

@Squeakz Re:

Just to let you know that this issue has now sorted as of Stable Channel updates release 3.9.2-53:

Apologies for it taking so very long to get around to this and thanks again for your original report that brought this issue to light. It only affected a very few devices but at least those few should be good to go now.

1 Like
10

As I have just found out I am affected by this instance too with installation being on SanDisk_Ultra_Fit 32 Gb. I figured I’ll give it a spin on a flash drive before slapping it on an SSD, but it failed. So my options are to either subscribe to Stable from Testing or reinstall on SSD. 3.9.1.16 is too outdated I guess?

11

@Volkodav Welcome to the Rockstor community.
With regards to:

You could also build your own installer for our release candidate stage Rockstor 4 ‘Built on openSUSE’ variant:

Which is the future of Rockstor anyway. You will then have the required fix baked in as the installer currently uses Rockstor testing version 4.0.4 which is years newer than the now deprecated 3.9.1-16 CentOS based testing channel offering. And once installed it can be subscribed to either channel using a new or existing Stable subscription of you can leave it at it’s default of 4.0.4 and just installed upstream updates. The ‘Built on openSUSE’ variant testing channel is currently at 4.0.5:

Hope the helps and thanks for the feedback here.

12

Phil thanks for your prompt reply - I do have 3.9.1-16 up and running from SSD but I will go with your advice and try to build the installer. RC6 seems to be really close to a Release - when do you expect that to happen anyway?

13

@Volkodav

Good luck with the DIY installer build method. And do remember to ask here on the forum if you have any issues as we are actively working on the documentation for this method and a number of forum members have already successfully build their own Rockstor 4 installer via this method. But the method does depend on a number of moving parts (actively maintained dependencies) so it’s entirely possible our docs get out of sync from time to time.

That’s a tough one to answer I’m afraid. It would have been already out but we had some late feedback here on the forum about broken AD/LDAP functionality and our remit is stated as releasing 4 only once it has feature parity with our prior 3 variant and with broken AD it did not. This set us back quite a bit as AD is tricky and upon fixing that we ended up with a few more paper-cuts. And so the story continues. But as a rough guide as to what is left to do we have the following continually updated GitHub milestone:

https://github.com/rockstor/rockstor-core/milestone/18
“First 4 Stable (ISO)”

Apologies for not being able to give a time frame but as a re-release of the project we have, and have had quite the task on our hands. But all doable, and in the process of being done.

But yes, I think we are fairly close. And once I’ve got my own next pull request submitted and reviewed and I or someone else has reviewed @Flox 's pending pr I’m hoping to do another release candidate.

Hope that helps, and the more folks we have testing the 4 variant and reporting their findings the faster we are likely to pin down any outstanding show stoppers.

2 Likes