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 aes128-gcm@openssh.com and aes256-gcm@openssh.com
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="^aes128-gcm@openssh.com,aes256-gcm@openssh.com" -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