Cloudron Forum

Thank you, that has solved the problem!

... or even in the docs (which are, by the way, excellent!)

The full solution is : First run (as-is): mysql -uroot -ppassword box -e "delete from blobs where id='sftp_private_key' OR id='sftp_public_key'" Then, /home/yellowtent/box/setup/start.sh to complete the migrations Then, systemctl restart box

@girish worked on the 20.x instance

Worked on v 7.3 same issue.

Check the contents of/home/yellowtent/box/VERSION . Is it 7.4.3 ? If so, you can run the commands below and make it work again . After you get it back, snapshot the server and upgrade ubuntu when possible. mkdir -p /usr/local/node-16.18.1 curl -sL https://nodejs.org/dist/v16.18.1/node-v16.18.1-linux-x64.tar.gz -o /tmp/node.tar.gz tar zxvf /tmp/node.tar.gz --strip-components=1 -C /usr/local/node-16.18.1 rm /tmp/node.tar.gz ln -sf /usr/local/node-16.18.1/bin/node /usr/bin/node ln -sf /usr/local/node-16.18.1/bin/npm /usr/bin/npm systemctl restart box

This continues in https://forum.cloudron.io/topic/9514/panic-mode-update-failed

We can't change the doc page yet atleast until 7.5 is stable. Also, 18.04 is still supported to install pre-7.4 releases.

Same here in a home server situation.

@scooke I am out of ideas then. If you like, you can reach out on support@cloudron.io and we can debug further to see if we can resurrect the app.

There was an error in the logs about some keys that resembled another post here. The recommendation was to delete two files (don't remember which ones) and after doing so, the installation went through and after that I was able to update. The issue has been resolved.

@girish That did it. Thanks so much for the help!

@avatar1024 hopefully now it gets a good kick What you say, @girish ?

@girish Thank's

This was a bug in 7.4.0 and is now fixed in 7.4.1. We updated node to v18 (from v16). There was a subtle but impact change hidden... In node 16, the requestTimeout was 0. This meant unlimited time. In node 18, the requestTImeout is now 5 mins. This meant that large restores were failing if the upload didn't finish within 5 mins.

@girish said in Update to version 7.3.6 failed: systemctl kill cloudron-updater This solved it ! Thank you !

@LoudLemur the only time I've ever had any issue with a Cloudron update the culprit was actually a bug in the linux kernel itself and not Cloudron's fault at all! It pretty much Just Works. That's why we all love it.

@girish said in Updating from v7.1.4: @cpa We moved out of AWS a while ago. Looks like older version of Cloudron is caching the old release. To fix: Delete the file /home/yellowtent/platformdata/update/updatechecker.json systemctl restart box Now , Settings -> Check for updates and then try to update Facing the same issue here, and this resolved it for me. And now I realized that my installation was multiple versions behind (like at least half-a-year behind), despite having weekly auto-update enabled. I'm afraid there could be more people like me who didn't check and didn't know it is stuck on 7.1.4.

@timconsidine said in Auto-update 7.3.4 - all apps down: Phew, that was a scary platform update Yes, 7.3 is pretty massive since it updates docker. So, it has to bring down everything and bring it up again.

@girish I didn't install anything, but I might have upgraded from 18 to 20 at some point as well as @Neluser did. dpkg --configure -a resulted in dpkg: error: dpkg frontend lock is locked by another process, so I restarted the machine after all and updating worked fine. Before that I killed the dpkg process and tried to run it, which resulted in that: dpkg --configure -a Setting up grub-efi-amd64-signed (1.173.2~20.04.1+2.04-1ubuntu47.4) ... debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable dpkg: error processing package grub-efi-amd64-signed (--configure): installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent processing triggers for shim-signed: shim-signed depends on grub-efi-amd64-signed | grub-efi-arm64-signed; however: Package grub-efi-amd64-signed is not configured yet. Package grub-efi-arm64-signed is not installed. dpkg: error processing package shim-signed (--configure): dependency problems - leaving triggers unprocessed Errors were encountered while processing: grub-efi-amd64-signed shim-signed Either way, solved not in the most elegant way, but solved