Community Solution

Ubuntu or Debian on ZimaOS: Why a Base Docker Image Stops and When to Use ZVM

An October 2025 ZimaOS 1.5.0 thread where a user entered ubuntu:latest into Install a customized app, but the container would not stay running. Community replies explained the difference between a Docker app and a standalone Debian/Ubuntu virtual machine, and suggested ZVM or a proper Compose service.

Typing ubuntu:latest into ZimaOS's “Install a customized app” field does not create a small always-on Ubuntu server automatically. The image is a minimal Ubuntu container filesystem, not a preconfigured virtual machine with a full boot sequence, SSH daemon, service manager, and a background application already running.

That distinction explains the October 2025 source case. The image could be pulled and a container could be created, but it did not stay running in the way the user expected. The right solution depends on the real goal: run one application in a container, or run a complete general-purpose Debian/Ubuntu operating system inside a VM.

A Docker Container Is Not a Small Virtual Machine

A virtual machine emulates a complete computer environment and boots its own operating-system stack. A container shares the host's Linux kernel and runs one or more isolated processes in its own userspace.

Docker's model centers on the container's main process. If the foreground process exits, a detached container exits too. Containers are therefore normally built around a long-running service such as a web server, database, sync daemon, or application worker.

Ubuntu and Debian Official Images Are Minimal Base Images

The current Ubuntu official image is built from Canonical's minimal root filesystem, and Docker describes it as a minimal installation rather than a complete VM appliance. The Debian official image similarly uses a minimal minbase root filesystem.

If you start one interactively with a terminal, it feels like a small Linux environment because you get a shell. When that shell exits, there may be no remaining foreground service to keep the container alive.

Use the maintained Ubuntu base image information or the maintained Debian base image information before treating either one as a prebuilt server appliance.

Why ubuntu:latest Can Stop Immediately

ZimaOS expects an installed Docker app to have a meaningful long-running process. A bare distribution image is usually a foundation for another image or an interactive shell environment. If there is no service process configured to remain as PID 1, the container can exit normally rather than “crash.”

Check the container log and exit state before assuming ZimaOS failed to install the image. An exited container with no application configured is a different problem from a service that starts and throws an error.

If You Only Need One Application, Start from the Application

The source user clarified that they did not really want a full VM. They wanted one application—iDrive—and access to NAS storage. In that situation, the best Docker design is usually to find a maintained image for the actual application or build a small image that installs and launches that application.

The container should expose only the ports, volumes, credentials, and devices the application needs. Persistent files should live in mapped ZimaOS storage, not only inside the disposable container layer.

Use Docker Compose for a Real Container Service

The community reply suggested a proper Compose definition rather than only entering ubuntu:latest and a container name. Current ZimaOS has moved even further in that direction: it can import Docker Compose, edit YAML, and run multi-container stacks with lifecycle control.

Current IceWhale guidance says standard container runtime configuration belongs in Docker Compose, while ZimaOS-specific store metadata belongs in x-casaos.

Use the current ZimaOS Compose model for self-hosted apps rather than treating a distribution image name as a complete application definition.

Map NAS Storage into the Container

If the application only needs access to one directory, map that real ZimaOS folder into the container. The host side should point to a backup or data folder on the intended storage pool, while the container side exposes a simple path the application expects.

Current ZimaOS explains how host storage maps into container paths. This is usually lighter than running an entire Debian VM just to reach one folder.

Use ZVM When the Software Expects a Full Linux Machine

A VM is the better fit when the application installer expects things such as:

  • a conventional package manager and mutable system filesystem;
  • systemd or several OS-level services;
  • kernel-level behavior that cannot be provided safely through a container;
  • a traditional SSH-administered Linux server environment;
  • software from a vendor that explicitly supports Ubuntu/Debian installs but not Docker.

That matches the first community reply: if the goal is a standalone Debian or Ubuntu operating system, use ZVM rather than forcing a base container image to behave like a full VM.

Do Not Install the App into the ZimaOS Root Filesystem Instead

Moving from “Ubuntu container exits” to “I will apt-install the software on ZimaOS itself” is usually the wrong direction. Current ZimaOS keeps most system folders read-only by design and is not a general Debian/Ubuntu host with apt as its normal application-management model.

Containers and VMs exist precisely so application dependencies can stay separate from the ZimaOS base system.

When a Debian/Ubuntu Base Image Is Still Useful

There are legitimate reasons to build from ubuntu or debian: the target software may publish installation steps only for those distributions, or you may need their package repositories during image build.

In that case, create a Dockerfile or Compose-backed image that installs the application and defines a real foreground command. Do not rely on manually entering a shell, installing packages interactively, and hoping the modified container becomes a durable app. Container recreation can discard changes that were not baked into the image or stored in persistent volumes.

A Restart Policy Does Not Replace a Missing Main Process

Docker restart policies are useful for a real service that should come back after a reboot or unexpected exit. They do not turn an otherwise finished shell session into an application server. If the container's intended work is already complete, repeatedly restarting it only creates a loop.

Choose the Smallest Isolation Layer That Matches the Software

  • App already has a maintained Docker image: use that image.
  • App can be packaged from Ubuntu/Debian dependencies: build a proper application container.
  • App needs a complete conventional Linux host: use ZVM.
  • You only need storage access: map the required NAS folders rather than virtualizing the entire disk.

Ubuntu and Debian on ZimaOS FAQ

Why does ubuntu:latest install but not stay running?

A base distribution image is not automatically an always-on service. A Docker container needs a main process that remains running.

Is ubuntu:latest a full Ubuntu virtual machine?

No. It is a minimal container userspace that shares the host kernel.

Should I use ZVM for every Linux application?

No. A real Docker application is usually lighter and easier to manage when the software supports containers.

When is ZVM the better choice?

Use a VM when the software expects a traditional mutable Ubuntu/Debian server with system-level services or installation assumptions that do not fit a container.