Upgrading Baikal from 0.2.7 to 0.4.X: I Think I Messed It Up

[tanaok]

Hi Dear Community,

Things were working really well for years with Baikal 0.2.7. (TX!) when, all of a sudden, I decided that I "deserved" an upgrade to the latest version 0.4.6: bad idea.

After having carefully followed the steps from http://sabre.io/baikal/upgrade/ I got several install errors ("parse errors in new config file"), followed by another one (the famous one with "synctoken" and "SQLState[42S21]").

Being a total NOOB, but so happy to be able to store my calendars and contacts on a non-Google or -MS server, I tried to solve these problems by downgrading to Baikal version 0.4.4 and even back to 0.2.7...

Situation now is that 1/ My MySQL DB has apparently been preserved from the mess 2/ I got a "Baikal is running allright" message 3/ I even manage to get an admin access but cannot connect anymore to one of my calendars (682 events) via the login and password, even if I changed it through the admin Webpage.

20170916T154433Z I org.dmfs.caldav.autheticator.AuthenticatorActivity calendar discovery log:
20170916T154435Z V org.dmfs.dav.Dav get principal /baikal/cal.php/principals/user/
20170916T154435Z I org.dmfs.dav.Dav found principal: /baikal/cal.php/principals/user/
20170916T154435Z V org.dmfs.dav.CalDav get calendars https://tanaok.be/baikal/cal.php/principals/user/
20170916T154436Z V org.dmfs.dav.CalDav found calendar user address mailto:xxx@yyy.com
20170916T154436Z V org.dmfs.dav.CalDav found calendar user address /baikal/cal.php/principals/user/
20170916T154436Z I org.dmfs.dav.CalDav also looking for calendar home sets in /baikal/cal.php/principals/user/
20170916T154436Z V org.dmfs.dav.CalDav get calendars /baikal/cal.php/principals/user/
20170916T154436Z V org.dmfs.dav.CalDav looking for calendars in https://tanaok.be/baikal/cal.php/calendars/user/
20170916T154436Z V org.dmfs.dav.CalDav resourcetypes DAV::collection urn:ietf:params:xml:ns:caldav:schedule-outbox
20170916T154436Z V org.dmfs.dav.CalDav non-calendar collection found at https://tanaok.be/baikal/cal.php/calendars/user/outbox/
20170916T154436Z V org.dmfs.dav.CalDav resourcetypes DAV::collection
20170916T154436Z V org.dmfs.dav.CalDav additionally looking for calendar in /baikal/cal.php/principals/user/
20170916T154436Z V org.dmfs.dav.CalDav resourcetypes DAV::collection DAV::principal
20170916T154436Z I org.dmfs.caldav.autheticator.AuthenticatorActivity using accountname xxx@yyy.com

App: org.dmfs.caldav.lib
App version: 0.4.32
OS version: 21
OS Info: samsung/jfltexx/jflte:5.0.1/
Manufacturer: samsung
Date: Sat Sep 16 17:44:38 GMT+02:00 2017

I tried to access the server via Android (CalDAV-Sync app) with the following URL: /baikal/cal.php/calendars/user, /baikal/cal.php/calendars/user/default, even the one with "principals" in it but always get a wrong credentials response from the app in return. This app has been working well for ages so the problem doesn't come from there

In short, I think I messed it up totally and wonder how to get the things back on track again. I am especially worried about the MySQL database, afraid no to be able to read all its data anymore (luckily I backed it up).

I don't have any problem to open a TeamViewer connection to my PC to anybody of you interested in helping me out!

TX in advance

[derStephan]

Are you sure, you don't face the problan that PHP stopped execution too early to complete the upgrade?

Try to raise the maximum execution time. Otherwise, the script will be stopped after 30s in the middle of the upgrade process and your data will be corrupted.

This gets worse with each entry you have in the database.

So, restore your backup, raise maximum execution time a lot and run the upgrade script again.

To raise maximum execution time, try adding

ini_set('max_execution_time', 3000); //3000 seconds = 50 minutes

to line 1 in the baikal-file /html/admin/install/index.php

right after <?php

Then run your upgrade and be patient.

P.S: If I am right, then you are not the first one to encounter this problem: #665 or #573

[tanaok]

Hi Stephan, thank you very much for your quick and detailed answer.

So, after having added the ini_set() function to the new /html/admin/install/index.php file as you mentioned (and copied all files to my server without overwritting , I ran the upgrade and got the 'SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'synctoken'' error, already referenced in several issues: #464, #506, #530 and #589...

@tamielbr, in #530, seemed to face similar issues and mentioned the 'change permissions' option: and idea of where and how this has to be done?

[derStephan]

Did you restore your backup first? Otherwise, the new colums will exist but the data in it will be corrupted.

[tanaok]

Hi Stephan, yes unfortunately i did restore my backup... Le 20 sept. 2017 15:17, "derStephan" <notifications@github.com> a écrit : Did you restore your backup first? Otherwise, the new colums will exist but the data in it will be corrupted. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#708 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeiLLrIPK8VHvFSMX8YkRq37ckkENBoJks5skNz_gaJpZM4PZ2ML> .

[derStephan]

yes unfortunately i did restore my backup...

can you switch back to the previous version with your backup? If so, do it to get a clean starting point. If not, then your backup is f***ed

[TheSmartGerman]

Well, I also tried to upgarde from 2.7. to the latest version. Got a lot of errors. Finally I did a clean installation and synced back my data.

But now I'm struggling with the ics export plugin. previously it was defined like this in cal.php (http://sabre.io/dav/ics-export-plugin/):

$icsPlugin = new \Sabre\CalDAV\ICSExportPlugin();
$server->addPlugin($icsPlugin);

but how to use it in dav.php?
THX

[derStephan]

Got a lot of errors.

Not the most precise way of describing things :-)

But now I'm struggling with the ics export plugin

I'd suggest to open another issue for this.

[TheSmartGerman]

Sorry, can't recall the errors. But it was something similar. Finally I did a ics export from on of the synced calendars. installed the Baikal new and imported the ics file.

well, the export is "fixed". The current version supports icalenders by default. no need to enable the plugin.

Therefore I was able to solve my problem.

[derwok]

I had the same issue.

1. with every broken migration step you have to complete replace the /Specific folder with the db content, because migration can not re-sync on a broken previous migration.

2. While migration was in progress I got "504 Gateway Timeout Error" and migration stopped half way - even though I added
   to baikal/html/admin/install/index.php the line ini_set('max_execution_time', 3000);like suggested above. But on top of that I had to follow the directions here: https://easyengine.io/tutorials/php/increase-script-execution-time/ and adapt my nginx config.

Hope this helps someone.

[cmuerau]

The additional entry in the PHP file (max execution time to 3000) worked fine for me after upgrading from 0.2.7 to 0.4.6 and getting the error message that the update did not finish successfully.

And I fully restored the folder from backup before uploading the files again with the changed line.

Thanks a lot for the help here! :-)

[evert]

We've been pretty quiet because the project hasn't had an active maintainer for a while. There's recently been a new release that might solve some of these problems.

It's been a while since your message so I assume you either moved on or solved it. If not, give the latest version a shot and comment here if you're running into problems.