Last week I attempted what now seems an overly complicated upgrade from v15 to v17. Everything worked fine until I tried to update the database, at which time I got this error (plus a lot more that didn’t get captured on this screenshot).
I would love to know how to fix this, though I imagine it’s a bit complicated. Alternatively, I have reverted to my v15 build successfully. If I can get a little more guidance about how to properly update within Gibbon, this page is why I did an overly complicated process to improperly upgrade.
Hi Kevin, I’ve not tried those commands yet, but if they’ve worked, your footer should show v17.0.00. Can you try a force reset in your browser (Cmd-Shft-R on Firefox/Chrome on macOS). Alternatively, you can check /version.php in your Gibbon install. Let me know what that shows. Thanks, Ross.
My footer shows v15.0.00, and version php shows the same (I opened it in the command line–it won’t open in my browser). Force reset in my browser didn’t work either.
I followed all the command line instructions from your updating guide and they all seemed to work fine. I have never used rsync, though, so I’m not sure it did what was intended. I could try it again and share what terminal returns if that might help. Given my problem with the chown command (apache:apache doesn’t work on my system), I wondered if there was some Ubuntu specific syntax I was missing. (I also wondered if chmod was maybe necessary.)
I’m getting files ready to try rsync again if necessary.
Hi Kevin, yeah, if the commands worked properly, then you should definitely see v17.0.00 in the footer and in version.php. Please can you run again, as you suggested, and share a screenshot of what you see? Thanks!
Here’s what I got today. This isn’t what I remember returning the last time I tried, but I haven’t been able to reproduce that. I’ve tried a few variations with trailing / (on dry runs), but I’m just not clear what is happening.
Hi Kevin, I’ve not had a chance to look into this in detail, but “Operation not permitted” and “DRY RUN” look like interesting candidates for further troubleshooting.
The other way to do this is to manually copy over the files. The only thing you have to be wary of is to not overwrite any additional modules or themes that you’ve installed. I normally use FTP over SSH to update my installs, and that avoids this issue (which copying within an OS does not do).
Hope this helps, and sorry I can’t got into more detail on rsync right now. I wonder if @fvlasie, who contributed this script, might be able to add something?
Not a problem, Ross. The “dry run” return is because I ran the rsync command as a dry run (-vuan) before running it for keeps (-vua). The “operation not permitted” is because I didn’t initially run the command as a superuser. They do seem good avenues to explore, but I’ve already exhausted them.
Can you walk me through using sftp to updating an installation? I’ll do a little research too, but that seems a good option I have not explored.
The slowness of manually copying files is the reason I initially tried my upgrade by creating a new directory. But that is what yielded the sql errors that started this post. If nothing else, can you walk me through the process of repairing those sql errors?
I don’t know why, but the -u option in my rsync command was causing the problem. When I ran rsync -va instead of -vua, everything ran fine. My installation is now at 17.0.00 and my database updated without any problems at all.
Hi Kevin, brilliant, glad to hear that you got it sorted, and thanks for sharing the solution here. I’ll keep this in mind for future cases of mysterious rsync failure ; ) Welcome to v17! Ross.
