feat(templates): add amazonlinux-2023 distro

[electricalgorithm]

This commit adds a simple template for the Amazon Linux 2023 operating system's latest version. The OS is scheduled to release every two weeks, therefore, we need to find a way to automatically update it from the following AWS website:

• https://cdn.amazonlinux.com/al2023/os-images/2023.9.20251208.0/

[electricalgorithm]

Testing it with:

$ LIMA_TEMPLATES_PATH=lima/templates limactl start --name al2023-test --arch aarch64 --cpus 4 template:amazonlinux-2023 --debug

Correct os-release Info:

[gokhankocmarli@lima-al2023-test ~]$ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2023"
ID="amzn"
ID_LIKE="fedora"
VERSION_ID="2023"
PLATFORM_ID="platform:al2023"
PRETTY_NAME="Amazon Linux 2023.9.20251208"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023"
HOME_URL="https://aws.amazon.com/linux/amazon-linux-2023/"
DOCUMENTATION_URL="https://docs.aws.amazon.com/linux/"
SUPPORT_URL="https://aws.amazon.com/premiumsupport/"
BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2023"
VENDOR_NAME="AWS"
VENDOR_URL="https://aws.amazon.com/"
SUPPORT_END="2029-06-30"

Correct uname:

[gokhankocmarli@lima-al2023-test ~]$ uname -a
Linux lima-al2023-test 6.1.158-180.294.amzn2023.aarch64 #1 SMP Mon Dec  1 05:36:18 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

Correct repos:

[gokhankocmarli@lima-al2023-test ~]$ yum repolist
repo id                                                                         repo name
amazonlinux                                                                     Amazon Linux 2023 repository
kernel-livepatch                                                                Amazon Linux 2023 Kernel Livepatch repository

[electricalgorithm]

It's weird, but the only problem is that the backspace does not work. I don't know if Lima uses SSH underneath, but I'll investigate the debug logs by re-shelling to the VM.

[Update] Yep, it looks like it uses SSH.

DEBU[0000] Failed to detect CPU features. Assuming that AES acceleration is available on this Apple silicon.
DEBU[0000] OpenSSH version 10.0.2 detected, is GSSAPI supported: true
DEBU[0000] AES accelerator seems available, prioritizing [email protected] and [email protected]
DEBU[0000] executing ssh (may take a long)): [/usr/bin/ssh -F /dev/null -o IdentityFile="/Users/gokhankocmarli/.lima/_config/user" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o PreferredAuthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o GSSAPIAuthentication=no -o Ciphers="^[email protected],[email protected]" -o User=gokhankocmarli -o ControlMaster=auto -o ControlPath="/Users/gokhankocmarli/.lima/al2023-test/ssh.sock" -o ControlPersist=yes -t -o SendEnv=COLORTERM -o LogLevel=ERROR -p 54658 127.0.0.1 -- cd /Users/gokhankocmarli/ || cd /Users/gokhankocmarli ; exec "$SHELL" --login]

Then I believe it could be an issue with SendEnv.

[Update 2] The --preserve-env did not work either. Plus, I realised that the mountpoint did not work. I believe there has to be a directory called /Users/gokhankocmarli, which is my $HOME on the host machine.

[afbjorklund]

• Add amazon linux template #4047

Previous attempt with this (Amazon Linux) was:

• Create amazonlinux2023 template #2537

I think it also failed to automate the updating?

[electricalgorithm]

• Add amazon linux template #4047

Previous attempt with this (Amazon Linux) was:

* [Create amazonlinux2023 template #2537](https://github.com/lima-vm/lima/pull/2537)

I think it also failed to automate the updating?

Thank you for the info! I have reviewed the comments there and see that two concerns are in common:

• No dynamic approach to retrieve the latest image from CDN. (Should we even want this?)
• Mount problems with virtiofs.

I'll spend some time fixing those. However, I believe that we can move this template to experimental ones and start iteratively on fixing stuff. Some folks may not need mounts or be happy with just having AL2023 with Lima without the latest image since it's possible to easily update the system using dnf upgrade --releasever=<new-release-date>. Or even better, use latest for releasever.

We could easily patch it by adding a run-script when the image is initialised and upgrading the system to the latest. Wdyt?

[afbjorklund]

You can "fix" the mount problems by excluding the methods that don't work, like 9p (check other templates for examples)

But it's a problem if there is no download URL. Maybe something that upstream can provide, if you ask them?

[electricalgorithm]

You can "fix" the mount problems by excluding the methods that don't work, like 9p (check other templates for examples)

I used the same mount point restrictions as the previous PR, the issue still exists but I'm investigating it.

But it's a problem if there is no download URL. Maybe something that upstream can provide, if you ask them?

I added a new update-template script under hack/ directory. This script automatically fetches the latest version and updates the template. I used the trick of following the URL endpoint /latest and parsing its 302 response to resolve the latest version number (including .1/.0 at the end). I don't know who calls them in what frequency, but I see that it's the common and agreed approach.

[electricalgorithm]

Update: The mount problem is gone, and it's possible to update the image to the latest one within a new script under hack/. Additionally, the system tries to update the latest release when the machine is initialised automatically.

I'll check the unit test and the lining stuff later. Does it look OK to you?

[afbjorklund]

This should use upgradePackages instead, if desired

Then cloud-init will call dnf, and reboot if required

[electricalgorithm]

I haven't found an example of the usage or found the implementation on the Go modules. However, AL2023 does use a different style of releases. Running a simple "yum/dnf upgrade" would not do anything if "releasever" is not defined. I guess this version of upgrade is better. Wdyt?

[afbjorklund]

You lost me there. The upgradePackages is a template feature:

# Upgrade the instance on boot
# Reboot after upgrade if required
# 🟢 Builtin default: false
upgradePackages: null

[afbjorklund]

Or you mean that "dnf upgrade -y" does not work in this distribution?

[electricalgorithm]

It have a different effect then giving releasever. Amazon Linux uses a "fixed" repository method where every two week, they release another repo. This helps customers to make sure that whenever they use the AL2023 with releasever=20251208, all packages would be the same. So, if one wants to update their packages, they have to upgrade the release version of the repository.

Standard yum/dnf upgrade or update is not going to work since it does not define which version to upgrade the repo.

[afbjorklund]

Then it seems to me that the template should not be updating anything at all. If the user writes 20251208.0 they want just that, similar to when you run a docker container. If you want a newer version, you get a newer image? Instead of trying to run the package manager inside a container. Or that it shouldn't be automatic...

For CentOS it was the opposite, they didn't support snapshots (not even monthly, let alone weekly) and when you upgraded you always got the latest. Not the "x.y.z" thing that RHEL support bought you, but only the "x". So I would just skip the whole section, but otherwise it should create the /etc file after upgrading I think?

[electricalgorithm]

Could someone possibly help me reproduce these CI checks? I do run shellcheck, shfmt, etc. but I guess there's some configurations different since all seems good on my local. There has to be a guide on running/replicating GitHub actions in this doc: https://lima-vm.io/docs/dev/testing/

[afbjorklund]

There is make lint, but keeping it in sync with .github is a constant battle... Maybe https://github.com/nektos/act

[afbjorklund]

I still don't want new commits to Lima every two (just to bump a snapshot version) every two weeks