-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Every step is already checked on the update page (.step
file is not deleted)
#243
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
The problem here is that the It might be that the updater didn't update the code to a new internal version? Or that the config.php was tweaked so that the |
To resolve this: remove the |
@MorrisJobke Thank you! |
Typically it is deleted on every upgrade. :( So a weird hack which should™ work is to lower the last number in config.php version number and click through the web updater. But be careful - it should not cause any problems, but better have a backup to rollback (especially the DB). |
The error still occurs with NC 20. |
.step
file is not deleted)
It doesn't occur under normal circumstances. If this is still occurring since you've upgraded past NC20, please provide your last |
I see this issue with every single update, regardless if it's minor or major. I have to manually delete the .step file to make it work via the web updater. This should delete the file. Line 1028 in aac9e4b
I suppose it works as it doesn't throw an exception. I've also altered the code of the updater/index.php and added more debug messages and a check if the .step file exists after it should have been deleted and it works as it should. The permissions on the files in updater-[...] are all correct and the same. Here's my update.log for the last update to 26.0.3:
Nextcloud log for the time period
Output of `occ config:list system{
"system": {
"activity_expire_days": 14,
"auth.bruteforce.protection.enabled": false,
"blacklisted_files": [
".htaccess",
"Thumbs.db",
"thumbs.db"
],
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"cloud.example.com",
"example.com"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "26.0.3.2",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"enable_previews": true,
"enabledPreviewProviders": [
"OC\\Preview\\PNG",
"OC\\Preview\\JPEG",
"OC\\Preview\\GIF",
"OC\\Preview\\BMP",
"OC\\Preview\\XBitmap",
"OC\\Preview\\Movie",
"OC\\Preview\\PDF",
"OC\\Preview\\MP3",
"OC\\Preview\\TXT",
"OC\\Preview\\MarkDown"
],
"loglevel": 2,
"log_rotate_size": 104857600,
"logtimezone": "Europe\/Berlin",
"theme": "",
"maintenance": false,
"forcessl": true,
"mail_smtpmode": "smtp",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"forceSSLforSubdomains": false,
"singleuser": false,
"trashbin_retention_obligation": "auto",
"filelocking.enabled": "true",
"debug": false,
"overwrite.cli.url": "https:\/\/cloud.example.com",
"mail_sendmailmode": "smtp",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpsecure": "tls",
"mail_smtpport": "25",
"app_install_overwrite": [
"calendar",
"keeweb",
"spreedme",
"documentserver_community",
"files_antivirus"
],
"mysql.utf8mb4": true,
"updater.release.channel": "stable",
"twofactor_enforced": "true",
"twofactor_enforced_groups": [
"admin"
],
"twofactor_enforced_excluded_groups": [],
"remember_login_cookie_lifetime": 2592000,
"session_lifetime": 86400,
"session_keepalive": true,
"default_phone_region": "DE",
"memcache.distributed": "\\OC\\Memcache\\Redis",
"memcache.local": "\\OC\\Memcache\\Redis",
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 6379
},
"updater.secret": "***REMOVED SENSITIVE VALUE***"
}
} After looking a bit deeper into the code I found this: Line 1404 in aac9e4b
Afterwards the endstep function is called, which creates the .step file again: Line 1407 in aac9e4b
To me it looks like calling endstep() is unecessary if $step == 12. |
New Nextcloud version, same issue (upgrading 27.0.2 to 27.1.0). While searching for this issue, I found a PR (#438) from @blizzz that should fix this exact issue, but seemingly wasn't merged as it should be handled elsewhere.
This doesn't seem to happen, or happen only partly. Here's an output of ´ls -lash´ of my updater folder:
Both files were modified, but the .step file remained. Now I ran the update like I usually do. Remove .step file. Start the update via the web updater. Once it reached the last step ("Disable Maintenance mode and continue in the web based updater"), I switch to the shell and run occ upgrade -vvv ouput
Then I clicked the Disable Maintenance mode and continue in the web based updater in my browser to disable the maintenance mode and return to my updated instance. I checked the updater folder right after and was once again greeted with a fresh .step file.
Now while this seems like a user error at first (combining web and command line upgrade) I went ahead to double-check the documentation. (In my mind, I had read somewhere that I should use the command line upgrade on larger installations to avoid any PHP timeouts) Sure enough, the documentation confirms that you can use this method to update. See https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html - Step 6. So there is something funky happening with the web based updater that creates a new .step file. I tried to look into this, but I lost the trail in the JavaScript. |
Thanks for your analysis. Could you post the contents from the .step file? So it appears to be created when using the web updater. I know of one instance that is being updated this way, and the same problem is observed occasionally. I update my private instance using the web updater, but never encountered that problem. |
Certainly. Here are the contents of the .step file after the update yesterday:
Contents of the .step-previous-update:
Yes, kind of. At least when you're going the update path I went: Start in web updater → continue via shell occ upgrade → finish in web updater. I haven't tried to upgrade completely via web updater, since I'm running a rather large instance.
Judging by the small amount of people reporting this problem, I suppose most people update do the same. |
I updated today from 27.1.0 to 27.1.1 with a slightly different approach.
Going this route doesn't create a new .step file. So certainly the web updater is doing something odd here. |
So I used the approach mentioned in my last message for the last few updates, and it works reliable. Although I could omit step 1 as the .step file was not created anymore as I wasn't finishing the update on the web based updater. |
Steps to reproduce
1.a Click the "update" button on the admin page or
1.b run php updater/updater.phar
Expected behaviour
I would have expected the checkboxes marking the upgrade steps to be unchecked at first, and to be checked after the upgrade.
Actual behaviour
Server configuration
Operating system: Ubuntu 18.04.3 LTS
Web server:: ngnix 1.14
Database:: postgresql
PHP version: 7.2
Nextcloud version: (see Nextcloud admin page)
Updated from an older Nextcloud/ownCloud or fresh install:
Where did you install Nextcloud from:
Signing status:
Signing status
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Firefox 68
Operating system: Archlinux
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
The text was updated successfully, but these errors were encountered: