sysext: turn vim to a sysext image

[tormath1]

In this PR, we propose to turn vim to a sysext image built without minimal compiling option. The sysext will be enabled by default to not break existing Vim usage.

• Folks interested to have vim on Flatcar will enjoy the full experience
• Folks not interested to have vim on Flatcar (and its regular amount of CVEs) will be able to remove it

This sysext is called tools and can handle more software inside, see:

We can rather bundle similar things into a feature set, and give it an appropriate name (E.g., we wanted a dev extension with gcc, gdb and other stuff). Here we could call it tools and later on we also add an optional extra-tools extension for anything else we want to add that wasn't part of the base image (E.g., htop, nano?). ¹

One could drop Vim from Flatcar with the current configuration:

variant: flatcar
version: 1.1.0
storage:
  files:
    - path: /etc/flatcar/enabled-sysext.conf
      overwrite: true
      contents:
        inline: |
          -tools

Note: In case of emergency, a nano editor is now shipped on the generic image and will be always available (even if tools sysext is unmerged)

How to use

Use vim as usual:

core@localhost ~ $ systemd-sysext status
HIERARCHY EXTENSIONS         SINCE
/opt      none               -
/usr      containerd-flatcar Tue 2024-12-03 14:33:23 UTC
          docker-flatcar
          flatcar-tools
          oem-qemu
core@localhost ~ $ vim --version | grep -i huge
Huge version without GUI.  Features included (+) or not (-):
core@localhost ~ $ nano --version
 GNU nano, version 8.5
 (C) 2025 the Free Software Foundation and various contributors
 Compiled options: --disable-justify --disable-libmagic --disable-nls --disable-utf8
core@localhost ~ $ sudo systemd-sysext unmerge
Unmerged '/usr'.
core@localhost ~ $ vim --version
-bash: /usr/bin/vim: No such file or directory
core@localhost ~ $ nano --version
 GNU nano, version 8.5
 (C) 2025 the Free Software Foundation and various contributors
 Compiled options: --disable-justify --disable-libmagic --disable-nls --disable-utf8

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc. (Total size difference: decreased by 9833049 bytes (9602 kbytes, 9 mbytes))
• CI: http://localhost:8080/job/container/job/packages_all_arches/6575/cldsv/

Note

• sysext size with vim huge:

$ sudo systemd-dissect ./flatcar-tools.raw
 File Name: flatcar-tools.raw
      Size: 9.9M
 Sec. Size: 512
     Arch.: n/a

Image Name: flatcar-tools
 sysext R.: ID=flatcar
            VERSION_ID=9999.0.0
            ARCHITECTURE=x86-64

    Use As: ✗ bootable system for UEFI
            ✗ bootable system for container
            ✗ portable service
            ✗ initrd
            ✓ sysext for system
            ✓ sysext for portable service
            ✗ sysext for initrd
            ✗ confext for system
            ✗ confext for portable service
            ✗ confext for initrd

RW DESIGNATOR PARTITION UUID PARTITION LABEL FSTYPE   ARCHITECTURE VERITY GROWFS PARTNO
ro root       -              -               squashfs -            -      no          -

Related to:

• vim as a built-in sysext image and remove it from the base image Flatcar#1463
• Add a sysext for vim-huge sysext-bakery#78

Footnotes

1. https://github.com/flatcar/scripts/pull/2502#discussion_r2314870321 ↩

[pothos]

This should go into /usr/share/flatcar/enabled-sysext.conf

[pothos]

I would like to avoid having too many extensions and treat it like packages. We can rather bundle similar things into a feature set, and give it an appropriate name (E.g., we wanted a dev extension with gcc, gdb and other stuff). Here we could call it tools and later on we also add an optional extra-tools extension for anything else we want to add that wasn't part of the base image (E.g., htop, rg?).

[tormath1]

Sounds good to me.

[pothos]

To state what was written elsewhere: We might want to still include an emergency editor in the base image. Something like nano is good because it's common, user friendly, and minimal (and many distros have it as default editor).

[pothos]

Unrelated comment: I think it would be nice to have mksquashfs and mkfs.erofs available to build sysext images on Flatcar itself, maybe they could also directly go to a tools extension instead of the base image. Not sure if tools or optional extra-tools would be better - in doubt extra-tools to keep the default small?

[tormath1]

I am just worried about the confusion that tools and extra-tools can add. What is extra ? Maybe dev-tools (and this could be part of the sysext devcontainer flatcar/Flatcar#1125)

[pothos]

With "extra" thought we can communicate that these are additional/optional. In the dev extension that would replace the dev container we would have even less common things because most people won't need a compiler and debugger. I think three layers somehow make sense in the long run and should give enough room for package inclusion requests so that we don't add a bunch of other extensions where it's maybe difficult to know how they are compatible with each other once dynamic libraries are involved. For the three layers "tools", "extra(-tools)" and "dev" we should build/generate them stacked so that extra and dev can depend on the contents of "tools" (and "extra") to avoid file conflicts.
This dependency can be documented and we can also add "tools"/"extra" implicitly when parsing the extension config file.

[tormath1]

I've just realized that this might break all tests in Github Actions because we don't push the assets on bincache. Flatcar won't be able to boot because tools will be enabled by default but won't be available on bincache.

[pothos]

I've just realized that this might break all tests in Github Actions because we don't push the assets on bincache. Flatcar won't be able to boot because tools will be enabled by default but won't be available on bincache.

To avoid the download we should pre-populate it on the rootfs. The file has to be placed under /etc/flatcar/sysext/flatcar-${NAME}-${VERSION}.raw (and the image build logic should not move it to /usr/'s /etc underlay, so this placement should be done after that has happened).
The kola tests that reformat the rootfs would still fail, though, but since they actually don't need the extension we should be able to provide an empty extension in the test's Ignition config (Don't know if an empty file works or a symlink to /dev/null).

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/17490975553

[tormath1]

I've just realized that this might break all tests in Github Actions because we don't push the assets on bincache. Flatcar won't be able to boot because tools will be enabled by default but won't be available on bincache.

To avoid the download we should pre-populate it on the rootfs. The file has to be placed under /etc/flatcar/sysext/flatcar-${NAME}-${VERSION}.raw (and the image build logic should not move it to /usr/'s /etc underlay, so this placement should be done after that has happened). The kola tests that reformat the rootfs would still fail, though, but since they actually don't need the extension we should be able to provide an empty extension in the test's Ignition config (Don't know if an empty file works or a symlink to /dev/null).

In this case, I think we should seize the opportunity to start unify docker and containerd sysexts management with the other sysexts. There is a default /usr/share/flatcar/enabled-sysext.conf with:

containerd
docker
tools

With those three sysexts populated on the rootfs. All the sysext will be controlled in the same way and no need to symlink the docker / containerd sysext to remove them: https://www.flatcar.org/docs/latest/provisioning/sysext/#remove-docker-and--or-containerd-from-flatcar

[pothos]

Yes :) I think in a follow-up PR after testing that it works with the "tools" extension (Is nightly enough or would we need to test it with an Alpha release? Not sure if we need to wait that long.)