`limactl create`: add `--plain` flag to disable mounts, port forwarding, containerd, etc.

[AkihiroSuda]

The --plain flag will disable:

• mounts
• port forwarding (except the SSH port)
• containerd
• (maybe) guest agent process
• aptgetting sshfs packages, etc.

[fwilhe2]

Question: Could this also support systems that don't have a package manager? I'm asking because I'm currently looking into image-based, immutable systems. There are various approaches to implement this, but they typically have in common that no 'normal' package manager is available. I think it would be great if lima was usable with such systems, and I see that depending on what the image provides some features of lima might not be available, but getting a basic shell via ssh would already be pretty great imo.

Edit: Just noticed two related PRs:

• Add flatcar experimental example, another with coreos ignition #1657
• Add example for Fedora CoreOS, running ignition not cloud-init #1653

[afbjorklund]

The downside is that those read-only systems, will not support all features of a regular operating system. You can install some things in /var (like nerdctl-full), but if for instance fuse and sshfs is missing from the image you will need to make do without it (and use e.g. virtfs). They typically also have bigger disk images, both for including the "kitchen sink" (since there is no package manager) and for doing dual-booting (with an active/passive partitoning, or with snapshots)

But those two systems are examples on what can be done with the current split. The biggest issue maintaining it is that all setup scripts need to be duplicated, since it doesn't support the regular shell scripts but requires systemd units... And of course that all cloud-init configuration needs to be converted to ignition, since it doesn't support the standard. I think the current number of scripts and configs makes it tolerable, but it could stand in the way of bigger future changes?

[afbjorklund]

@fwilhe2 Note that typically CoreOS did not install any user software whatsoever on the host (VM). You started a toolbox container, and then used the package manager inside that... Either "live", or in your Dockerfile

Similar to what WSL2 is doing with the "distributions"

https://github.com/coreos/toolbox

I think the Bean OS will do the same.

[fwilhe2]

Sure, I was mentioning it because a package manager is described as a requirement in the Lima readme

Bean looks interesting 👀

[afbjorklund]

The shell scripts do require a package manager

[jandubois]

The shell scripts do require a package manager

Technically they don't if your base image already includes all the required prerequisites.

[afbjorklund]

I found that it was possible to use the pre-installed software on CoreOS, provided that one mimicked the other setup from the boot scripts (that are not getting called, when not using cloud-init*).

* https://github.com/lima-vm/lima/blob/ea089cb4679e9f82edfe8bb585fc1757a2381737/pkg/cidata/cidata.TEMPLATE.d/ignition.yaml

The guestagent and the nerdctl-full does not require a package manager, since they are just copied with install and unpacked from a tarball. Again provided that all their requirements are there.

So I was able to "install" containerd, even without any package manager. I just used "oneshot" systemd services, since that was the most straightforward (i.e. given the complicated circumstances).

---

The sshfs was hit or miss, though. It's not possible to install or tar that, without system (and kernel) support...

But it is possible to run without a (supported) package manager, like the experiment with tinycorelinux: tinycloud. There most of the required software is mounted from squashfs packages (some is still provided right on the rootfs, though).

Or like how it works in alpine-lima, where all the packages are getting installed to tmpfs instead of being mounted.

[AkihiroSuda]

PR:

• Add "plain" mode (disables mounts, port forwarding, containerd, etc.) #1840