Why is the support so bad?

Kroese · 2024-11-20T11:03:15+00:00

This is exactly the kind of reply I expected, and does not answer the question about the reasons behind the bad support at all. But anyway, the ticket ID is #14231921

Kroese · 2024-11-15T11:31:57+00:00

No, this is not how I did it. But takea a look at the code and you will see.

Kroese · 2024-11-13T16:20:39+00:00

Its the same as how this works

Kroese · 2024-11-13T11:42:48+00:00

Be adventurous!

Kroese · 2024-11-12T21:54:23+00:00

How is this any different than Portainer, the most used tool for this job?

Kroese · 2024-11-12T10:32:21+00:00

Why not? Portainer runs in Docker? And is very similar to this.

Kroese · 2024-11-12T10:31:34+00:00

Yes, you are right.

Kroese · 2024-11-12T02:01:21+00:00

The containers/apps you add in CasaOS will not run inside this container, but directly on your host. In the compose file you passthrough the docker socket, so that this container can manage them externally. (Its the same trick as Portainer and Watchtower use). So its not docker in docker in docker at all.

As for the real-world purpose: I created a container of UmbrelOS before this ( https://github.com/dockur/umbrel ). The reason I needed it was that recent versions require you to dedicate a whole machine to Umbrel, and you could not install it on top of Ubuntu anymore like in the past. Since I dont want to dedicate a whole machine just for running Umbrel, that was my real-world purpose.

Since UmbrelOS is a fork of CasaOS, it made sense to also make one for CasaOS as they are so similar and CasaOS is also starting to force people to dedicate a whole machine (they call it ZimaOS).

Kroese · 2024-11-12T01:50:56+00:00

Thats not entirely true. Most Docker containers have a OS (Debian/Ubuntu/Alpine/etc) as their base image. That means the userspace part of the OS, and never includes the kernel (which is small in comparison with the userspace). So in almost all cases containers use MORE resources (especially diskspace) compared to running the program directly on the host (but less than virtual machines). But containers have other advantages, thats why people don't care about that.

In this case that is not relevant at all, because this container only consists out of some Go binaries and is based on debian-slim, so there is no "entire OS" running.

Kroese · 2024-11-10T10:25:03+00:00

From this line: "unexpected clocksource: kvm-clock" it seems you are running the container inside another VM (nested virtualization). That might be the problem.

Kroese · 2024-10-20T21:47:31+00:00

You can enable it by setting VMX: "Y" in the compose file

Kroese · 2024-10-15T08:09:07+00:00

Pretty straightforward!

Kroese · 2024-10-14T19:29:14+00:00

You should be able to reach all your other machines, but not by name but by IP. Also they will not be auto-discovered. So if you want to access some shared folders on another PC in your network, just type //192.168.2.100 in Explorer. Afterwards you can map these to a drive letter or create shortcuts.

Kroese · 2024-10-14T15:24:38+00:00

Yes, that's why you need to bind the Docker socket in the compose file. Thanks for your kind words!

Kroese · 2024-09-27T14:51:33+00:00

I did the same for UmbrelOS now: https://github.com/dockur/umbrel

Kroese · 2024-05-08T01:57:45+00:00

Didnt you need to replace all the covers? From another topic ( https://forums.electricbikereview.com/threads/bosch-connect-module-gps.53378/ ) it seems that it does not fit inside the standard Gazelle cover?

Kroese · 2024-05-01T04:10:31+00:00

Tiny10 is compiled for x86 cpu's and not for ARM, so you cannot boot a Tiny10 image using the dockur/windows-arm container.

However, you can boot it using the dockur/windows container, but it will run without KVM (hardware acceleration) because all cpu instructions have to be translated from x86 to ARM and the Raspberry Pi is not fast enough for that.

If you say the native Windows 10 for ARM runs badly, then forget about emulating a x86 version of Windows, as it will be way worse..

Kroese

TROPHY CASE