After update 1.6.2 half my docker apps are not starting

Insight & Feedback
1

I just updated to 1.6.2, and most of my apps, the most important ones are not starting! Jellyfin, vaultwarden. On top of that, I can’t go to settings for any app, running or not!

I honestly am not sure what to do even to try and troubleshoot what is going on since I can’t even access any settings. See terminal on apps. I guess I need to see if I can find logs anywhere, but I honestly don’t know where to look.

2

After 30 minutes, apps started popping up working. That was awful. For the record, if I have to roll back to a previous version, what do I have to do?

3

Hi mate,

Glad to hear the apps eventually started. A 30-minute delay is not normal, so it would help to understand your setup before suggesting rollback.

Could you please confirm which Zima device you are using, whether the affected apps use external storage, and whether their app data is stored under /DATA/AppData?

Please also post:

docker ps -a

docker info | grep -iE 'Docker Root Dir|Storage Driver'

You could also run ZimaBrain CE while the issue is happening. It may help identify whether the containers are waiting for storage, failing during startup, or being affected by a post-update service problem.

4

Same here. The BigBear repo is disppeared (in the beta 2 was ok)

5

I think it’s DNS related, and it can’t get any DNS info from a DNS server.
I figured it out, when I did a

ip route show default
default via 192.168.1.0 dev eth3 proto static metric 100
default via 192.168.1.1 dev eth2 proto static metric 101
default via 192.168.1.1 dev eth0 proto static metric 102
default via 169.254.0.1 dev thunderboltbr0 proto static metric 425 linkdown

am not sure how in the update, it changed the Eth3 primary ethernet selected changed the default gateway to 1.0 I ended up fixing it in the gui and then I could ping external again today. What is weird is things were working when I went to bed but were not when I got up this morning. I discovered that external pings were not working, so cloudflare wouldn’t work again. I eventually found the problem with the help of copilot and managed to make the change in the gui and that worked. After that I did another reboot and it still is working.

But for future reference, I’d like to know the process for rolling back, that should be documented somewhere.

6

Hi mate,

Good find. This appears to have been caused by the incorrect default gateway on eth3:

default via 192.168.1.0 dev eth3 proto static metric 100

Because it had the lowest metric, ZimaOS preferred that route instead of the valid 192.168.1.1 gateways. That would prevent external connectivity, with DNS and Cloudflare failing as a consequence.

Could you confirm your hardware and how eth0, eth2, and eth3 are connected? Also, was eth3 configured with a static address before updating to 1.6.2?

I agree that an official rollback procedure should be clearly documented. The current official recovery guide only describes booting the alternate A/B slot, while the offline-install guide documents installing an update package. Neither currently provides a clearly documented procedure for rolling back to a selected older release.

7

it was fully working on what I assume was eth3 before the update. I know it was working with the static IP it was configured, and the default gateway was set correctly to 192.168.1.1 Something during the upgrade changed it to 192.168.1.0

8

Thanks, that confirms the static configuration was correct before the update and the gateway changed from 192.168.1.1 to 192.168.1.0 during or immediately after upgrading to 1.6.2.

I believe IceWhale should investigate this as a possible network configuration migration regression. It would be useful if you could also post your hardware model and whether eth3 is onboard, PCIe, USB, or Thunderbolt networking.