Registrations to Open-AudIT forums are now closed. To ask any new questions please visit Opmantek Community Questions.

Open-AudIT

What's on your network?
It is currently Thu Mar 28, 2024 11:05 pm

All times are UTC + 10 hours




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Dec 05, 2016 1:31 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
Tried to upgrade from 1.5.3 to 1.12.8.1 and all was well. Ran the first database upgrade, but the second one (where it says I am on 1.8.4) it fails with this error.

Error Number: 1146

Table 'openaudit.sys_hw_bios' doesn't exist

DELETE sys_hw_bios FROM sys_hw_bios LEFT JOIN system ON system.system_id = sys_hw_bios.system_id WHERE sys_hw_bios.timestamp <> system.timestamp

Filename: controllers/admin.php

Line Number: 4551

I have seen only a few posts with this error, but don't seem to point to a fix. any ideas?

Thanks in advance.


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 05, 2016 11:02 am 
Offline
Site Admin
User avatar

Joined: Mon Jun 07, 2004 11:48 am
Posts: 1964
Location: Brisbane, Australia
Make sure you grab the absolute latest released code. It should be version 1.12.8.2.1.

_________________
Support and Development hours available from [url=https://opmantek.com]Opmantek[/url].
Please consider a purchase to help make Open-AudIT better for everyone.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 1:51 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
Sorry Mark.

Restored my VM back to the working version. Ensured the upgrade was the version you stated. Upgrade ran fine. DB upgrade to 1.8.4 works, but when I select to upgrade the DB upgrade again, I get the same error.

any ideas?

Thanks.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 2:10 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
There should be only one upgrade to take you from 1.5.3 to current. Since it looks like it gets through the 1.8.4 upgrade something must be failing in the 1.10 upgrade code. I would roll back your snapshot and try the upgrade again. Review the upgrade output for any errors. We'll need to fix those first.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 2:24 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
Thanks jpa. I have done this process twice now, same results. Where do I get the output to examine where it is failing?


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 2:49 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
Can you see the upgrade SQL statements in the other/log_system.log file? If so, maybe the last one will give us a hint where it's failing.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 3:50 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
Here is the contents of that file (some of it truncated for privacy)

2700 5 U:- C:login F:index I:10.20.60.125 M:config::update_config called by
2700 5 U:- C:login F:index I:10.20.60.125 M:config::update_config called by
2702 5 U:- C:main F:list_groups I:10.20.60.125 M:nmis Active Directory failed verification (html request)
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:Upgrade database to 1.10 commenced
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_change_log
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_contact
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_location_org
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_asset_line
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_asset_order
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_device_col
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_device
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_graph
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS sys_sw_antivirus
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_switch_ports
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS sys_sw_share_perms
2699 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DELETE sys_hw_bios FROM sys_hw_bios LEFT JOIN system ON system.system_id = sys_hw_bios.system_id WHERE sys_hw_bios.timestamp <> system.timestamp


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 4:04 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
We need to see the contents of that file before it tries to do the 1.10 update. So roll back your VM, do the upgrade. For whatever reason it should fail partway through and say you're on 1.8.4 and need to upgrade again. Before doing that check the file. The last SQL statement should give us the statement that caused the upgrade to fail before getting all the way to 1.12.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 4:15 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
I was able to go back into the day before log and found this. So when I get the error that I originally posted, it seems to be a result of renaming a table when trying to upgrade the DB to 1.10.

31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:Upgrade database to 1.8.4 completed
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:Upgrade database to 1.10 commenced
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_change_log
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_contact
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_location_org
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_asset_line
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_asset_order
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_device_col
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_device
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_graph
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS sys_sw_antivirus
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS oa_switch_ports
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DROP TABLE IF EXISTS sys_sw_share_perms
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:DELETE sys_hw_bios FROM sys_hw_bios LEFT JOIN system ON system.system_id = sys_hw_bios.system_id WHERE sys_hw_bios.timestamp <> system.timestamp
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_id id int(10) unsigned NOT NULL AUTO_INCREMENT
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios ADD current enum('y','n') NOT NULL DEFAULT 'y' AFTER system_id
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE timestamp last_seen datetime NOT NULL DEFAULT '0000-00-00 00:00:00' AFTER current
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE first_timestamp first_seen datetime NOT NULL DEFAULT '0000-00-00 00:00:00' AFTER last_seen
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_manufacturer manufacturer varchar(200) NOT NULL DEFAULT '' AFTER first_seen
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_serial serial varchar(100) NOT NULL DEFAULT '' AFTER manufacturer
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_description description varchar(200) NOT NULL DEFAULT '' AFTER serial
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_smversion smversion varchar(100) NOT NULL DEFAULT '' AFTER description
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_version version varchar(100) NOT NULL DEFAULT '' AFTER smversion
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:ALTER TABLE sys_hw_bios CHANGE bios_asset_tag asset_tag varchar(100) NOT NULL DEFAULT '' AFTER version
31461 5 U:NMIS C:admin F:upgrade I:10.20.60.125 M:RENAME TABLE sys_hw_bios TO `bios`


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 4:30 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
Great. But we don't log enough about the failure there. So do you anything in the web server or php error logs that might help why exactly it's failing? I'm not sure why this rename is failing. An error message would help.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 4:34 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
I don't believe the rename is the problem. I do have a 'bios' table right now, but the error I get is when it goes to delete data from sys_hw_bios. that table does't exist since it was renamed.

My suspicion is I could rename that table and try again and see where it gets me.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 4:40 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
Starting with a 1.5.3 database the upgrade routine should be able to upgrade all the way to 1.12.8.1 (or whatever) in one pass. If it fails midway, the upgrade routine is going to break when it tries to upgrade again. So you need to start with a 1.5.3 database and do the upgrade. When it fails midway through you need to review the php_error log and log_system.log to see the last SQL statement that failed.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 5:03 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
Thanks. I have done this process twice with the same results. Can you tell me where the php error log is? I want to see what it has before I go through this process again.

I did rename that one table, and the next steps errors out because it cannot find the timestamp column.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 5:11 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
I don't know if the Windows OpenAudit creates a php_error log. I'm running on Windows but in my own Apache instance.

If you want the really hard way you can read through all the SQL statements and compare them against what you can see in the database. Phpmyadmin or some other db view tool needed.

I really think you should roll back to 1.5.3 then try the database upgrade. This will fail to properly upgrade the database to the latest version. Do not do anything after it fails. Look at the last SQL statement in the log_system.log file. This should tell us something.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 07, 2016 5:20 am 
Offline
Newbie

Joined: Sat Nov 22, 2014 7:25 am
Posts: 18
I am running CentOS 6.8. Will try this again, but would like to compare the SQL commands one by one, can you point me to where I can find that?

thank you for your assistance.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC + 10 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group