Cloudron Forum

@joseph ah, there you go. I have indeed updated to 24.04, and presumably it was before this instruction was added.

Thank you all for the help, guys, all is well now

Great! Thank you!

BTW, it seems in retrospect that the start of the DNS problems coincided with me beginning to use the OpenVPN app. Take that for whatever it's worth.

Many thanks, all. I missed that bit of the documentation.

I'll definitely backup; I'm running on bare hardware, and didn't even do myself the courtesy of running Cloudron in a VM. I may... use this as an opportunity to change that.

Either way, this is all I needed. Thank you!

Thanks for sharing . Right... our current domain/location configuration follows an all or nothing approach. If one or more fail, it will refuse to bring the app up and will get "stuck" forever . We have a task somewhere to make this more smart and also make the app repair feature smarter but it always gets pushed out as low priority.

Well just gone through the upgrade process on a fresh instance through Hetzner to Ubuntu 24.04:

Upgraded to Cloudron 8.0 and took backup to storage box. Downloaded the backup metadata file. Wiped server with ubuntu image from Hetzner and apt failed to do upgrade, moaned about missing files on the mirror. Tried to resolve but I wanted to try out an iso installation from Ubuntu directly rather than using the Hetzner images anyway so gave that a go. Installing from ISO is actually easier than I thought it would be, there was no messing around with the routes as discussed in Hetzner docs. IPV4 works out of the box, I decided to take the netplan config file supplied by Hetzner's imaging process for my server and used that on the fresh Ubuntu install to get IPV6 working. After wiping and reinstalling the new system I changed the SSH port and then ran Cloudron-setup. It installed 8.0 for me as it detected a Ubuntu 24.04 install. In the setup wizard clicked on the restore option and supplied the file. Realised then I didn't have my storage box password so had to change that in the interface. However once changed the restore happened and all my apps were back in around 15 minutes.
Nice work guys, and I've always wanted to test the bear-metal restore from backup.

You can run the CLI tool on Cloudron like https://docs.cloudron.io/apps/mattermost/#command-line-tool . Instead of the import command at https://docs.cloudron.io/apps/mattermost/#migration , use the export command.

To get a file off Cloudron, easiest way is to export to a path under /app/data and then use the File manager to download it.

I am also curious why you are not able to update mattermost on Cloudron. It's all automatic.

There is a bug in Cloudron that it parses swap info incorrectly when there are no swaps in the system. This is fixed in https://git.cloudron.io/cloudron/box/-/commit/b66e77a2d8930381c95153b041d7c3edd331364a

To follow up, 11GB worked fine too.

image.png

@scooke said in Can't start upgrade from Ubuntu 20.04 to Ubuntu 22.0x because of "no development version of an LTS available" error:

This has an interesting bit about the -d. https://askubuntu.com/questions/1412543/how-does-exactly-do-release-upgrade-d-work#:~:text=The command do-release-upgrade,version of an LTS available. .

wow, great link.

@robw I have fixed the guide to remove the -d flag. Thanks for reporting.

Thanks for sharing the solution. Maybe there is a corner-case bug in the database migration about the directory server config.

Done Thanks!

All went well, apps are restored and all is running as intended 😄

Also for others to come here, to get back up on Ubuntu 18.04 run the following commands via SSH:

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

Then the system should be working again, however for the 7.5 update ubuntu has to be upgraded first.

Same here in a home server situation.

Mm, ok. Let's see if we get more reports on this. Maybe you can clone from previous backup and see if the calendars are still there.

This then means, that the system is using cgroups v2 now. I have updated the main docs section at https://docs.cloudron.io/packaging/cheat-sheet/#memory-limit for a start to make an app compatible with cgroup v1 and v2 (I guess in your case its sufficient to only support v2 now.)

Not sure why that slipped through. Is this sorted by now? We had a case where slow I/O caused the issue resulting in a timeout. Could this have been the case? https://forum.cloudron.io/topic/4780/postgresql-database-won-t-start/8

@benborges Ah ok. Maybe you can wait for 7.3. Please update to that and try to update again and we can debug further. There are some cgroup v2 related fixes for Ubuntu 22 in 7.3 which affect docker container creation, it's possible you hit that case.

@necrevistonnezr said in Nextcloud App "not responding" after upgrading to Ubuntu 22.04:

EDIT: I guess that replacement should go into /home/yellowtent/box/src/infra_version.js - but after a restart of box, still not running...

Yes, that's the correct place to fix it!

I will add a warning to our docs that updating to ubuntu 22 when using FTS feature does not work out of the box / without patching until 7.3.

@robi said in Best way to update from Ubuntu 18.04 to 20.04?:

one can use the -y option for apt to 'assume yes' to all prompts.

this doesn't work with do-release-upgrade for whatever reason.