@rockmar As @Flyer and @malcolmrmclean earlier in this thread mention, many updates depend on a reboot to ensure it’s the newer code you are running. Not sure but as you point out:
"storageadmin_networkdevice" does not exist
This looks like an expected db entry is no longer present. Between 3.8.12 and 3.8-15-11 there were many db changes, including in the network subsystem.
It would be useful to know if you can re-produce this error after a reboot, as it may be that the db changes specific to 3.8.15-11 have also affected you here as well as in your other forum post.
Why? Because 3.8.15-11 wouldn’t let me create a storage pool, so I went back to the version I had working previously to allow me to create them. Sorry for not being clear on the ‘migration’ steps, they are the ones referenced in Suman’s post on 31st May where it was suggested there is a fix, that did not work for me.
Yes, I have rebooted several times and still get the error.
For info I have rebooted many times, including after the update to 3.8.15-14 and still get the same error on every page. If I go to the users page then that page doesn’t load properly but the table is different:
ProgrammingError: relation “storageadmin_pincard” does not exist
LINE 1: SELECT COUNT(*) AS “__count” FROM “storageadmin_pincard” WHE…
That’s ok I was more of promting that there were related issues solved by reboot - which might indicate an upgrade that went wrong on your system (did not upgrade certain tables)
Hello @Tomasz_Kusmierz
I am getting the same error, after successful installation 3.8.15-10 and upgraded to -14 fine. I get mine in a different window though.
I did few reboots still pops up every now and then after few clicks on ok it disappears. Do you have any suggesting I can try? Thanks
I’m seeing this as well on the Storage > Samba page. Rockstor 3.8.15-14. No users have pincard setup. Output from /opt/rockstor/var/log/rockstor.log below. This begins when I access the Samba page and the follows to every page I navigate to afterwards. Rebooting multiple times has not resolved the issue for me.
[06/Dec/2016 15:44:41] ERROR [storageadmin.util:47] exception: relation “storageadmin_pincard” does not exist
LINE 1: SELECT COUNT() AS “__count” FROM “storageadmin_pincard” WHE…
^
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 40, in _handle_exception
yield
File “/opt/rockstor/src/rockstor/storageadmin/views/user.py”, line 105, in get_queryset
return combined_users()
File “/opt/rockstor/src/rockstor/storageadmin/views/ug_helpers.py”, line 69, in combined_users
temp_uo.pincard_allowed, temp_uo.has_pincard = pincard_states(temp_uo)
File “/opt/rockstor/src/rockstor/system/pinmanager.py”, line 136, in pincard_states
pincard_present = has_pincard(user)
File “/opt/rockstor/src/rockstor/system/pinmanager.py”, line 121, in has_pincard
pins = Pincard.objects.filter(user=int(uid_field)).count()
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 318, in count
return self.query.get_count(using=self.db)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 466, in get_count
number = obj.get_aggregation(using, [’__count’])[’__count’]
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 447, in get_aggregation
result = compiler.execute_sql(SINGLE)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/compiler.py”, line 840, 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)
ProgrammingError: relation “storageadmin_pincard” does not exist
LINE 1: SELECT COUNT() AS “__count” FROM “storageadmin_pincard” WHE…
@williams.tlr I was going to write the same exact thing I am doing my final reboot and will see how it will go.
Note: It also happens when you go to the disks page as well as the samba share page.
Hi all, finally had time to perform some tests, here my conclusions: @suman your help needed
Tests:
Pincard table cleaned -> All working fine
Pincard table dropped -> Getting same error
This mean 99% you didn’t have a Rockstor update since July (Pincard was added on june-july) and this Django migration from 1.6.* to 1.8.* raised your error (Django migration assumes all previous migrations already applied)
My suggestion: have a new Rockstor install and import your disks/configurations
I did this @Flyer I got a fresh install for 3.8.15 and updated to -14 and got the error for couple of days, however since I mentioned my last reboot I didn’t get the error message again. I am not sure it just fixed itself or it will pop up again. I will let you guys know.
Hi @Mahmoud87,
if you get users page and can create a Pincard you won’t get that error anymore (having users page rendering means it’s all ok, having a Pincard creation too confirms it again because if it doesn’t fail => Pincard table exists)
Reinstalling from a 3.8.15 .iso and updating from there resolved the issue for me. Before I had been installing from a 3.8.14 .iso previously. So pretty much exactly what @Flyer said.
with 2 fake migration (fake migration on Django = trace it, but don’t perform it)
So old Rockstors on 3.8.14 not already having Pincard table (and other tables too) currently moving to last Rockstor 3.8.15.x are without required tables.
We should patch with a conditional migration instead of a fake migration, but not updating Rockstor for a long time is not good (like not updating every system)
Hi @rockmar. It’s understandable why you wanted to start with 3.8-12, but could you install from 3.8.15 iso so that you get all necessary db schema changes the old way and then update to the latest? Any system being updated to 3.8.15-X should be updated from 3.8.15. When making django 1.8 migration I did think of the possibility of some users being on older versions. To provide a smooth upgrade path from <3.8.15 to latest would involve putting a lot of convoluted logic and then deprecating it later may introduce more problems as well. Or we could put out a stable update with the only change that enforces users to first update to 3.8.15 before updating further. But this won’t help users on testing channel, so we would need to put similar check for that code path too. This method also proved to be convoluted. So I decided to keep the code clean at the risk of breaking long updated paths.
I do want to offer an easy solution for those who are updating from <3.8.15 to latest, whether it’s stable channel or testing channel. For stable channel users, the solution is very simple, just update!
For testing channel users, update to 3.8.15-1 first with this one command yum update rockstor-3.8.15-1. Since there’s an updated kernel, you must reboot after the update. Then you can update to the latest from the UI. If you run into errors using this method, please report them.
I say we don’t bother with this @Flyer. I have experimented with possible solutions to do such thing and it’s not smooth at all. Testing channel users that are updating from an old(<3.8.15) version should just do the following
Update to 3.8.15-1 with yum update rockstor-3.8.15-1
I @suman, agree with you about that “it’s not smooth at all”, had some tests trying to have a conditional migration, found it’s possible with some hacks using migrations.RunPython(checkingfunc) where our checkingfunc actually runs something like this:
from django.db import connection
cursor = connection.cursor()
cursor.execute("select * from information_schema.tables where table_schema = 'public' and table_name ILIKE '%TABLE_TO_CHECK_EXISTS%'")
table_exists = True if len(cursor.fetchall()) > 0 else False
But this would require a rewrite for every migration.
Can we instead have an hack to force updates to be sequential? 3.8.15-1 will never update directly to 3.8.15-22, but will perform 3.8.15-2, 3.8-15-3, etc
This should grant users having all required steps on updates
This is a good idea and I’ve been thinking about implementing a generic enhancement to the update logic that’ll come in handy in the future. It would work as follows. Say we release an update x and we want to ensure that the system’s current version be at least p. Then update x fails if the system’s version is < p, with an appropriate error message. Our software update logic reads the error message and triggers another update to p. After a successful update to p, another update is triggered to bring the system to the latest version x.
Wouldn’t it be better for update just traverse through every versions on it’s way ?
Let’s say you’ve got a .14-3 and are going for newest version, system then will lookup for how to upgrade to .14-4 then update to .14-5 and so on …
That way difs between versions are kept to the minimum … and if upgrade craps out we will know exatly how to solve it because there will be a lot of people with same problem … solutions will be simple.
I am doing my final reboot and will see how it will go.
(like not updating every system)