Cloudron Forum

thanks, one of my instances seemed to be effected by this

@james said:

With the Dry run restore when taking this path you can also ensure that everything is working as intended reducing possible downtimes.

Exactly

@james said:

Upgrade Ubuntu 20 to 22

Follow the guide https://docs.cloudron.io/guides/upgrade-ubuntu-22

If everything worked out upgrade to 24
Upgrade Ubuntu 22 to 24

Follow the guide https://docs.cloudron.io/guides/upgrade-ubuntu-24

If everything worked out, perfect.

Just to say, personally rather than doing this, I tend to just spin up a new server with the new version on and then restore the back-up to the new server. Quicker and less prone to issues imho but also not always an option.

Also the standard "hack" to skip versions (you can't) is to set auto-updates to happen ever hour until it's caught up.

I just tried them too - so easy! Can literally copy paste it all as is and then it's done! @gengar

@alwynispat https://docs.cloudron.io/server#default-data-directory

@james said:

Please follow these steps if you have this issue:

Can this script be run on the working version I reverted to, or do I need to update to the broken version and then run it?

Edit: yes, it seems fixing the db and then updating also works fine.

I also had a not responding app and have reverted. Guess I need to look at that guide...

@davejgreen said:

I tried again with a fresh install of Ubuntu 24.04

@davejgreen said:

Maybe different versions of Ubuntu do it differently?

I think the only time I've had issues with migrations was when the provider of my VPS (I think it was Netcup) began using stripped down versions of Ubuntu that had stuff Cloudron needs missing.

But I'm guessing you're pulling Ubuntu directly from Ubuntu?

jdaviescoates said:

@LoudLemur said:

@jdaviescoates RustFS is available in unstable now. Would that suit?

I think someone has packaged Garage too.

I don't know if either would suit, but hopefully.

SeaweedFS is available now too

https://forum.cloudron.io/topic/15435/seaweedfs-is-now-available

@davejgreen said:

on the new server, I created my user before installing cloudron

FYI, afaict all the issues you've faced were caused by you doing something that isn't needed

e.g. the above creating a user, plus editing hosts files stuff mentioned previously.

I've migrated my Cloudron server probably 3 or 4 times without any issues

@LoudLemur said:

@jdaviescoates RustFS is available in unstable now. Would that suit?

I think someone has packaged Garage too.

I don't know if either would suit, but hopefully.

A Cloudron S3 addon would be great.

In the interim, I wonder if it might be possible to package an app that requires adding some S3 credentials as part of the initial configuration?

@avatar1024 said:

@jdaviescoates What do you mean? Are you asking if the other app in La Suite also require S3 for storing their files?

Yes

@nebulon said:

So the main issue here is, that it requires an S3 storage

Presumably other apps in La Suite face the same issue?

@marcusquinn to be fair, I think @loudlemur is posting links to his pastebin in response to be asked to not post all his AI generated content directly into the forums and to perhaps link to paste bins instead. But I agree that neither are ideal.

@necrevistonnezr said:

If you could only do something about the sorry state of webmail clients…

@necrevistonnezr I've not looked at it yet, but this could be promising on that front:

https://github.com/suitenumerique/messages

@robi yeah, it's not entirely dead given:

Starting today, Cal.com will relaunch all free and open-source code as Cal.diy under MIT License, widely considered the most liberal and popular open-source license. This new community edition is only for self-hosting and use at your own risk.

https://www.cal.diy/

That probably still meets my own needs. Perhaps a new package is needed for that?

Or perhaps we'll all migrate to @ekevu123's TymeSlot app?

https://tymeslot.app/
https://forum.cloudron.io/topic/15212/tymeslot-better-meeting-scheduling-than-cal.com

@andreasdueren fair enough.

I guess it was really for any app (community or otherwise) where people are worried that auto updates might break things. e.g. some people have auto-updates for Nextcloud turned off as plugins often break things.

Saying that, it's so easy to roll back to backups on Cloudron it's a relatively low risk for most people I'd suggest.

@andreasdueren but this thread is about OpenClaw and it sounds like that often has breaking changes.

There is also all the code that powers https://desec.io/ here https://github.com/desec-io/desec-stack

@creative567145 said:

ideally somebody needs to test the updates before pushing them to all instances.

I've not started using any Community Apps yet myself, but I'd suggest for anything important a good pattern might be to keep auto-updates turned off and to test them first in a cloned app before applying the updates to production