@james good points, thank you. Honestly … I didn’t check for 9.1.7, lost too much time getting stable operations again, didn’t want to risk further. I will get brave and do it when a process slot appears. Revoke 9.1.6 : Yes, maybe knee-jerk overkill, but it’s undeniably broken (not Cloudron fault I accept) in a fairly fundamental way for a possibly/probably large number of users. However if 9.1.7 is out and reliable, then users have a path forward. If they know about it. That’s where the Urgent Advisory Notice is relevant : please check if you’re on kernel xxxx, we have detected incompatibility of 9.1.6 with that, you can fix by 9.1.7 which is available now. I didn’t choose to deploy 9.1.6, it happened on a reboot and I was left with a broken system. An Advisory would have shortened restoration of full functionality.

Hello @stirchley.coop I also had a look and redacted some content. Also, the content that was not redacted are not critical since Cloudron ensures that non of the Cloudron services are accessible from the internet. But if you still feel more comfortable to delete the whole topic, I can do that.

@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?

@paradoxbound thanks for investigating . I will fix the timeouts .

@joseph Thanks - I tried the cloudron-firewall.sh patch and restarting but did not get docker to come up so I deleted the conf file like the original solution suggested and it came right back again. Yes it was kernel 110. Everything seems to be running now. Bummer that kernel upgrade caused all of this. Thanks for the help.

Hello @orezbodajoy This issue could be related to the Ubuntu kernel version 110 having a regression. If you are running kernel version 110 (check with uname -r). See https://forum.cloudron.io/topic/15265/unusable-application/39 If you are running Kernel version 110 and you'd like to try, you could apply this patch manually https://git.cloudron.io/platform/box/-/commit/bffc97ab2fedb06100bc507abd0f8b42d343ea6e and then systemctl restart cloudron-firewall. If this resolves the issue, please report back.

Hello @orezbodajoy The dashboard issue is related to the latest ubuntu kernel having a regression. If you are running 110 which has a bug . See https://forum.cloudron.io/topic/15265/unusable-application/39 If you'd like to try, you could apply this patch manually https://git.cloudron.io/platform/box/-/commit/bffc97ab2fedb06100bc507abd0f8b42d343ea6e and then systemctl restart cloudron-firewall. This should solve the issue.

Hello @ruihildt The banner is gone. Does this also resolve your issue?

Just tried updating the CLI via npm install -g cloudron@8.2.1 and it seems to work now Thanks for looking into it.

@tlem4 The dashboard issue is related to the latest ubuntu kernel having a regression. You are running 110 which has a bug . See https://forum.cloudron.io/topic/15265/unusable-application/39

Ok I did restore a previous state and then proceeded to update. This instance was not critical so no data loss

Hello @mendoksai That checks out with our other topic. A RAID failure can cause such a catastrophic issue.

From that error log it seems that other app is sqlite related: "[DB] INFO: Database Type: sqlite" Is this all related to the same rocket.chat app uninstall issue or some other problem? For mongodb not running, with latest Cloudron we stop unused services, so this sounds actually correct.

Needed to run cp /etc/docker/daemon.json /etc/docker/daemon.json.bak printf '{}\n' > /etc/docker/daemon.json systemctl restart docker systemctl status docker --no-pager As per the Hostinger AI, there were an issue aroundlog-driver in conflict

Thanks for the answer - I'll check until monday. Yes, I used AI but I personally checked and validated and understood the problem before posting.

@james Yes, this is a great find. Thanks a lot for your cooperation. In email service’s logs no any log... Whenever you want, I can reproduce issue and I can send you raw log. Keep me posted.

@imc67 So were we using the same rules from @d19dotca ? For now I removed from all istances, but in future I want to keep only rules who works in local, not requiring any outbound connection.

This is now fixed for the next release with https://git.cloudron.io/platform/box/-/commit/a4ea80cf5eb26b08462430111e8b6f75175e749d

@james said: I suspect that this might happen in the backup process and thus changing the amount of files. I think that's actually unlikely in this case because I'm pretty much the only active user of this instance and it backs up while I'm asleep. But I'll try to give enabling maintenance mode a try to see what we can see...