lima-vm
feat(templates): add amazonlinux-2023 distro
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/
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
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.
- https://github.com/lima-vm/lima/issues/4047
Previous attempt with this (Amazon Linux) was:
- https://github.com/lima-vm/lima/pull/2537
I think it also failed to automate the updating?
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?
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?
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.
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?
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/
There is make lint, but keeping it in sync with .github is a constant battle... Maybe https://github.com/nektos/act
I still don't want new commits to Lima every two (just to bump a snapshot version) every two weeks