First things first, make sure you are using the latest version in the 1.17.x series which is v1.17.2.
For the first error a table exists when it shouldn't. So restore from backup, delete the table, and re-run the upgrader.
For the second error you are missing a column so something went wrong during the upgrade.
Cheers.
Hello, yes, I'm using the latest 1.17.2, which I just downloaded today.
I cleared out a couple of tables that were interfering with it as mentioned, re-restored the database, and after the first failure, I look at the log file and there are 3 debug events, the last one says:
Upgrader - 9b5550da applied
Patch 8b923d61-9b5550da applied successfully (v1.14.0)
At this point, the "Migrate to osTicket v1.17.2" page is still accessible, listing the summary of patches to be applied at the bottom of the page. When I try to continue again however, I immediately get an error, and when I look at the logs again, I get this:
DB Error #1062
[INSERT INTO `soft_schedule` SET `id` = 1, `flags` = 1, `name` = 'Monday - Friday 8am - 5pm with U.S. Holidays', `created` = NOW(), `updated` = NOW()] Duplicate entry '1' for key 'PRIMARY'<br /> <br /> ---- Backtrace ----<br /> #0 (root)/include/mysqli.php(207): osTicket->logDBError('DB Error #1062', '[INSERT INTO `s...')<br /> #1 (root)/include/class.orm.php(3482): db_query('INSERT INTO `so...', true, true)<br /> #2 (root)/include/class.orm.php(658): MySqlExecutor->execute()<br /> #3 (root)/include/class.schedule.php(319): VerySimpleModel->save(false)<br /> #4 (root)/include/class.schedule.php(364): Schedule->save()<br /> #5 (root)/include/class.schedule.php(369): Schedule::create(Array)<br /> #6 (root)/include/upgrader/streams/core/00c949a6-8b923d61.task.php(9): Schedule::__create(Array)<br /> #7 (root)/include/class.upgrader.php(348): ScheduleCreator->run(30)<br /> #8 (root)/include/class.upgrader.php(121): StreamUpgrader->doTask()<br /> #9 (root)/scp/upgrade.php(39): Upgrader->__call('doTask', Array)<br /> #10 {main}
I see that it also says:
Upgrader - 9b5550da (task pending).
The ScheduleCreator task reports there is work to do
OK, I teased it along, and still found leftover artifacts from my first failed install attempt; when I restore the database, it overwrites exisiting stuff, but doesn't delete extraneous stuff, and apparently the upgrader is completely unable to deal with that. Trying to get back to a clean start to try one more time.
No matter what I've tried, this upgrade will not proceed.
Any help would be greatly appreciated.
It says "Upgrade Aborted" and the latest error is:
DB Error #1054
[SELECT A1.* FROM `soft_email_account` A1 WHERE A1.`type` = 'smtp' AND A1.`type` = 'smtp' AND A1.`email_id` = 5] Unknown column 'A1.type' in 'where clause'<br /> <br /> ---- Backtrace ----<br /> #0 (root)/include/mysqli.php(207): osTicket->logDBError('DB Error #1054', '[SELECT A1.* FR...')<br /> #1 (root)/include/class.orm.php(3482): db_query('SELECT A1.* FRO...', true, true)<br /> #2 (root)/include/class.orm.php(3529): MySqlExecutor->execute()<br /> #3 (root)/include/class.orm.php(2010): MySqlExecutor->getArray()<br /> #4 (root)/include/class.orm.php(2054): ModelInstanceManager->{closure}()<br /> #5 (root)/include/class.orm.php(2033): CallbackSimpleIterator->next()<br /> #6 (root)/include/class.orm.php(2042): CallbackSimpleIterator->rewind()<br /> #7 (root)/include/class.orm.php(1713): CallbackSimpleIterator->valid()<br /> #8 (root)/include/class.orm.php(1723): CachedResultSet->fillTo(9223372036854775807)<br /> #9 (root)/include/class.orm.php(1337): CachedResultSet->asArray()<br /> #10 (root)/include/class.orm.php(1360): QuerySet->all()<br /> #11 (root)/include/class.orm.php(606): QuerySet->one()<br /> #12 (root)/include/class.orm.php(381): VerySimpleModel::lookup(Array)<br /> #13 (root)/include/class.orm.php(417): VerySimpleModel->get('smtp', NULL)<br /> #14 (root)/include/class.email.php(210): VerySimpleModel->__get('smtp')<br /> #15 (root)/include/class.mailer.php(35): Email->getSmtpAccount(false)<br /> #16 (root)/include/class.email.php(231): osTicket\Mail\Mailer->__construct(Object(Email))<br /> #17 (root)/include/class.email.php(245): Email->send('jscott@kellytou...', '[core]: Upgrade...', '[/**\n* @signatu...', NULL, Array)<br /> #18 (root)/include/class.upgrader.php(204): Email->sendAlert('jscott@kellytou...', '[core]: Upgrade...', '[/**\n* @signatu...')<br /> #19 (root)/include/class.setup.php(115): StreamUpgrader->onError('[/**\n* @signatu...')<br /> #20 (root)/include/class.setup.php(69): SetupWizard->abort('[/**\n* @signatu...', false)<br /> #21 (root)/include/class.setup.php(44): SetupWizard->load_sql('/**\n* @signatur...', 'soft_', true, false)<br /> #22 (root)/include/class.upgrader.php(379): SetupWizard->load_sql_file('/home/customer/...', 'soft_')<br /> #23 (root)/include/class.upgrader.php(112): StreamUpgrader->upgrade()<br /> #24 (root)/include/ajax.upgrader.php(42): Upgrader->upgrade()<br /> #25 (root)/include/class.dispatcher.php(153): UpgraderAjaxAPI->upgrade()<br /> #26 (root)/include/class.dispatcher.php(40): UrlMatcher->dispatch('/upgrader', NULL)<br /> #27 (root)/scp/ajax.php(326): Dispatcher->resolve('/upgrader')<br /> #28 {main}
It seems like the type column is missing from the soft_email_account table which it shouldn't be. Something is definitely going wrong somewhere I just don't know where as I cannot replicate this. Are you sure you are using v1.17.2? Did you copy/replace the code files or completely clear the directory and upload the new files? It's always better to fully replace the files in case copy/replace doesn't work correctly or if there are some old lingering files.
Cheers.
Ah, I see now that you updated the error. So it looks like it's failing with an error and tries to send you an email but that fails. There should be an error logged before this one.
You can see it abort here (stack traces are in reverse, confusing, I know lol):
#20 (root)/include/class.setup.php(69): SetupWizard->abort('[/**\n* @signatu...', false)<br />
#21 (root)/include/class.setup.php(44): SetupWizard->load_sql('/**\n* @signatur...', 'soft_', true, false)<br />Cheers.
You're right, here's the error that came before that:
[core]: Upgrader Error
[/** * @signature e69781546e08be96d787199a911d0ffe * @version v1.14.0 * @title Thread Type * * This patch adds a new field to the Thread Event table called thread_type * it allows us to be able to delete threads and thread entries when a ticket * is deleted while still maintaining dashboard statistics * */ CREATE TABLE `soft_thread_event_new` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `thread_id` int(11) unsigned NOT NULL default '0', `thread_type` char(1) DEFAULT '', `event_id` int(11) unsigned DEFAULT NULL, `staff_id` int(11) unsigned NOT NULL, `team_id` int(11) unsigned NOT NULL, `dept_id` int(11) unsigned NOT NULL, `topic_id` int(11) unsigned NOT NULL, `data` varchar(1024) DEFAULT NULL COMMENT 'Encoded differences', `username` varchar(128) NOT NULL default 'SYSTEM', `uid` int(11) unsigned DEFAULT NULL, `uid_type` char(1) NOT NULL DEFAULT 'S', `annulled` tinyint(1) unsigned NOT NULL default '0', `timestamp` datetime NOT NULL, PRIMARY KEY (`id`), KEY `ticket_state` (`thread_id`, `event_id`, `timestamp`), KEY `ticket_stats` (`timestamp`, `event_id`) ) DEFAULT CHARSET=utf8] Table 'soft_thread_event_new' already exists
KevinTheJedi Are you sure you are using v1.17.2? Did you copy/replace the code files or completely clear the directory and upload the new files?
I copied the new files to overwrite the old site so any pre-existing files remain. Should I delete all the old files and then extract the new ones again?
And yes, definitely 1.17.2.
It tried to create a new table but it already exists. So restore from backup again, but before you run the upgrader, make sure the soft_thread_event_new table doesn't already exist.
Cheers.
Already did that, but it finds another table to fail on. I almost need a list of every new table added from 1.14 onwards.
Or, the installer needs that extra database logic, "IF EXISTS".
I would at least try. Make sure you copy/backup your /path/to/osTicket/include/ost-config.php file as this houses important information.
Cheers.
OK sure, this will be my 6th run through. First I'll delete every table from the database, and then I'll restore it, and then I'll run through the installer and post every error, again.
Roger that. Normally this shouldn’t be an issue but it seems like something is wonky in your install/setup.
Cheers.
OK, started it all over on a freshly restored database, ran it until it quit, and it shows 3 new log events:
Upgrader - 8b923d61 applied
Patch 00c949a6-8b923d61 applied successfully (v1.14.0)
Then
Upgrader - 8b923d61 (task pending).
The ScheduleCreator task reports there is work to do
Then finally:
Upgrader - 9b5550da applied
Patch 8b923d61-9b5550da applied successfully (v1.14.0)
at this point, all I can do is re-run the upgrader, and the next patch is "Thread Type".
As soon as I run that, with no hesitation, I get a 502 error, and then these two new log entries:
This one is repeated:
Upgrader - 9b5550da applied
Patch 8b923d61-9b5550da applied successfully (v1.14.0)
Next is this one:
DB Error #1062
[INSERT INTO `soft_schedule` SET `id` = 1, `flags` = 1, `name` = 'Monday - Friday 8am - 5pm with U.S. Holidays', `created` = NOW(), `updated` = NOW()] Duplicate entry '1' for key 'PRIMARY'<br /> <br /> ---- Backtrace ----<br /> #0 (root)/include/mysqli.php(207): osTicket->logDBError('DB Error #1062', '[INSERT INTO `s...')<br /> #1 (root)/include/class.orm.php(3482): db_query('INSERT INTO `so...', true, true)<br /> #2 (root)/include/class.orm.php(658): MySqlExecutor->execute()<br /> #3 (root)/include/class.schedule.php(319): VerySimpleModel->save(false)<br /> #4 (root)/include/class.schedule.php(364): Schedule->save()<br /> #5 (root)/include/class.schedule.php(369): Schedule::create(Array)<br /> #6 (root)/include/upgrader/streams/core/00c949a6-8b923d61.task.php(9): Schedule::__create(Array)<br /> #7 (root)/include/class.upgrader.php(348): ScheduleCreator->run(30)<br /> #8 (root)/include/class.upgrader.php(121): StreamUpgrader->doTask()<br /> #9 (root)/scp/upgrade.php(39): Upgrader->__call('doTask', Array)<br /> #10 {main}
As you can see, that's complaining about records in the soft_schedule table.
I found that those records DO EXIST in that table, and in previous attempts, I went in and cleared those records in that table, which does let us get to the next step, but it's still a path to failure.
Should I continue? I feel like that spot right there where it failed on soft_schedule is critical.