I have the 40GB Hansson Hyper-V VM purchased in February of 2021. I have automatic updates on, and it has been updating every weekend with no issues, though multiple version of Nextcloud. It looks like this weekend, it broke Nextcloud (going from version 24.0.7 to 25.0.1). I reverted back to a Veeam Backup, then just updated the linux packages, no issues. I then reverted again, and only updated nextcloud. After the reboot, Nextcloud is broken again. So it seems to not matter what updates LInux is at. This is the error when i try to access Nextcloud:
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Please check nextcloud logs for errors. There are some bigger changes between 24.x and 25.x
Would be interesting to know what caused this.
We always recommend doing manual updates between major versions. That way you can see where it went wrong directly on the screen.
That was the first thing I did. I restored the VM to the night before, and then manually ran update.sh. It looks like it complete fine, and in the minute before the VM reboots, I access the web interface, but once it reboots, it’s broken.
OK, could you provide any logs? Apache (error.log), PHP-FPM, and Nextloud log would be interesting to start with.
Can you point me in the right direction? Not sure where to find these logs.
You can find all logs in
/var/logs and easiest way to post them here is to copy paste after you did
Can you tell me which of these logs would help?
alternatives.log alternatives.log.9.gz auth.log.1 dmesg.1.gz dpkg.log.5.gz installer msmtp php7.4-fpm.log.5.gz syslog.3.gz ubuntu-advantage.log.5.gz
alternatives.log.1 apache2 auth.log.2.gz dmesg.2.gz dpkg.log.6.gz journal netdata php7.4-fpm.log.6.gz syslog.4.gz ubuntu-advantage-timer.log
alternatives.log.10.gz apport.log auth.log.3.gz dmesg.3.gz dpkg.log.7.gz kern.log nextcloud php7.4-fpm.log.7.gz syslog.5.gz ubuntu-advantage-timer.log.1
alternatives.log.11.gz apport.log.1 auth.log.4.gz dmesg.4.gz dpkg.log.8.gz kern.log.1 null php7.4-fpm.log.8.gz syslog.6.gz ubuntu-advantage-timer.log.2.gz
alternatives.log.12.gz apport.log.2.gz bootstrap.log dpkg.log dpkg.log.9.gz kern.log.2.gz php7.4-fpm.log php7.4-fpm.log.9.gz syslog.7.gz ubuntu-advantage-timer.log.3.gz
alternatives.log.2.gz apport.log.3.gz btmp dpkg.log.1 fail2ban.log kern.log.3.gz php7.4-fpm.log.1 postgresql sysstat ubuntu-advantage-timer.log.4.gz
alternatives.log.3.gz apport.log.4.gz btmp.1 dpkg.log.10.gz fail2ban.log.1 kern.log.4.gz php7.4-fpm.log.10.gz private ubuntu-advantage-license-check.log ubuntu-advantage-timer.log.5.gz
alternatives.log.4.gz apport.log.5.gz cloud-init.log dpkg.log.11.gz fail2ban.log.2.gz landscape php7.4-fpm.log.11.gz redis ubuntu-advantage.log ubuntu-advantage-timer.log.6.gz
alternatives.log.5.gz apport.log.6.gz cloud-init-output.log dpkg.log.12.gz fail2ban.log.3.gz lastlog php7.4-fpm.log.12.gz samba ubuntu-advantage.log.1 wtmp
alternatives.log.6.gz apport.log.7.gz dist-upgrade dpkg.log.2.gz fail2ban.log.4.gz letsencrypt php7.4-fpm.log.2.gz syslog ubuntu-advantage.log.2.gz
alternatives.log.7.gz apt dmesg dpkg.log.3.gz faillog mail.log php7.4-fpm.log.3.gz syslog.1 ubuntu-advantage.log.3.gz
alternatives.log.8.gz auth.log dmesg.0 dpkg.log.4.gz fontconfig.log mail.log.1 php7.4-fpm.log.4.gz syslog.2.gz ubuntu-advantage.log.4.gz
That would be nice to start with
Thanks for helping. Got swamped with work and finally got back to this and I figured out the issues. The update actually ran fine. I had my VM set with dynamic memory. The startup amount was 2GB’s, and then it could expand to 8GBs. I changed the startup ram to 4GBs and then it ran perfectly after another restore. Just an FYI in case it happens to anyone else.