iSCSI No longer working after upgrade

Status
Not open for further replies.

Dave Genton

Contributor
Joined
Feb 27, 2014
Messages
133
For some time had been using Nightly-201506270630 because it would bind with LDAP. After finding still LDAP mileage varies main box was updated back to stable release train. Any upgrade to any release iSCSI will not work. Sometimes it says the service is running in the GUI under Services but I dont think it ever is or does. I can revert back to Nightly and iSCSI is fine, with some stable versions I can make it start by copying a ctl.conf into /etc and starting service and it runs awhile then eventually crashes. Leaving box running latest stable and even the /etc/ctl.conf copy of backup file doesn't work, but it fails showing same error shown in all versions.

Selecting Sharing->iSCSI Menu never appears but error displayed is:
{"error": true, "events": [], "message": "Error: no such column: services_iscsitargetglobalconfiguration.iscsi_discoveryauthmethod"}

Searching the /var/log/debug.log shows:
[root@freenas] /var/log# more debug.log | grep iscsi
Jul 28 19:12:34 freenas manage.py: [freeadmin.navtree:12] OperationalError: no such column: services_iscsitarget.iscsi_target_serial
Jul 28 19:15:12 freenas manage.py: [middleware.notifier:224] Calling: start(iscsitarget)

Having both iSCSI block Storage Clients on the network for remote disks as well as VMware Hosts using iSCSI Storage for guests this is down unless running the Nightly image which was fine until recently when plugins started crashing and even LDAP stopped binding again with no changes anywhere in environment.

How may I restart iSCSI service with these errors shown keeping latest stable 9.3 release ?? I have two boxes here and same error on both boxes after upgrading from same Nightly image, both have iSCSI down on this error. Bug report 10773 opened and sent from freenas menu. ctl.conf never shows as service recreates each time, so usually doesn't exist.
 
D

dlavigne

Guest
For some time had been using Nightly-201506270630 because it would bind with LDAP. After finding still LDAP mileage varies main box was updated back to stable release train..

Yeah, don't do that as it ruins the config database.

Do you still have a BE from when you were on STABLE? If so, boot into that than upgrade to the latest from that version.
 
Status
Not open for further replies.
Top