Invalid literal for int() with base 10: '---'

[Please complete the below template with details of the problem reported on your Web-UI. Be as detailed as possible. Community members, including developers, shall try and help. Thanks for your time in reporting this issue! We recommend purchasing commercial support for expedited support directly from the developers.]

Brief description of the problem

S.M.A.R.T error on newly added disk drive

Detailed step by step instructions to reproduce the problem

I added a new drive and reboot. The new drive gets /dev/sda (something else was sda before), possibly due to shuffling of the sata cables.
The Refresh the smart details gave the errors as shown in stack trace below

Web-UI screenshot

[Drag and drop the image here]

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_smart.py", line 116, in post return self._info(disk) 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_smart.py", line 74, in _info sa.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 973, in execute_sql for sql, params in self.as_sql(): File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/compiler.py", line 931, in as_sql for obj in self.query.objs File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/__init__.py", line 710, in get_db_prep_save prepared=False) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/__init__.py", line 702, in get_db_prep_value value = self.get_prep_value(value) File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/__init__.py", line 1869, in get_prep_value return int(value) ValueError: invalid literal for int() with base 10: '---'

@amtuannguyen Welcome to the Rockstor community and thanks for your report.

Given that this issue is most likely caused by a peculiarity in the output of your drive’s S.M.A.R.T data is it necessary to gain the same output so that someone can have a go at sorting what’s causing this. As it goes there is included in Rockstor a shell script to grab and zip up the same outputs from smartctl as are used internally and we have a flag that means we can test submitted output.:

sh /opt/rockstor-dev/src/rockstor/scripts/dump-smart.sh 

Please supply a single device name using the /dev/sdX or /dev/disk/by-id reference
N.B. Use the base device - not a partition reference.
eg /opt/rockstor-dev/src/rockstor/scripts/dump-smart.sh /dev/disk/by-id/ata-ST3160021AS_5JS1HNX9

So if you could execute that same program only substituting your newly added and smart parsing problem drive name instead of the example “ata-ST3160021AS_5JS1HNX9” drive name given (TAB key for auto complete may help) then you should end up with a file in your /root directory:

/root/smart-issue-report.tar.gz

if you could attach that file to this forum thread then someone can take a look at the problem, although it may take some time of course.

Please note that the serial number of your drive will be included in this output, just so you know.

Let us know if there is a problem with this procedure and we can take it from there. I know previously we were unable to attach such files but I think this has now been sorted in the forum config.

Hi Philip

Thank you for your help. I tried uploading the file but the forum won’t allow it. I have uploaded to Google Drive though.

https://drive.google.com/open?id=0B8xkO4sbDXbxMTdxUlgzQXROajg

@amtuannguyen Thanks for submitting the smart data. I had a quick look earlier and was able to reproduce the error here using your SMART data. It seems the issue is that your drive model is reporting “—” for every attribute threshold which is not something that has been reported or seen before. Anyway I’ve opened an issue for it:

And have submitted a fix / work around by way of a pull request against that issue:

If you are in a rush, or curios, you could make the changes indicated in that pull request to your own copy:

/opt/rockstor/src/rockstor/system/smart.py

otherwise you can just wait to see if those changes pass review and get merged. Nano is pre-installed and easy to use. No need to add the lines beginning with ‘#’ as they are just comments and if you do go the route of self patching then be very careful to make only these changes exactly as they are in that pr: including exact indentation. Probably best to take a copy of the file first, just in case, but don’t leave it in the Rockstor src tree; ie put it in /root as a backup for example.

Thanks again for reporting this. So at least our SMART parsing shouldn’t fall over in that way again, assuming it get merged that is.

Note that if you do make those changes by hand you will need to restart the rockstor service, or just reboot, for the changes to take effect.

Hope that helps and thanks again for assisting with this fix.

Thank you so much, Philip. This works!

@amtuannguyen Your welcome and thanks for the fix / work around confirmation. Bit odd that there are no threshold values. It may be that this changes in the future but at least we catch the situation for now.