feat(templates): add amazonlinux-2023 distro#4454
feat(templates): add amazonlinux-2023 distro#4454electricalgorithm wants to merge 1 commit intolima-vm:masterfrom
Conversation
|
Testing it with: Correct os-release Info: Correct uname: Correct repos: |
|
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. 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. |
electricalgorithm
changed the title
|
Previous attempt with this (Amazon Linux) was: 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:
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 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? |
electricalgorithm
force-pushed
the
feat/add-al2023-template
branch
from
0f476bd to
e33f646
Compare
I used the same mount point restrictions as the previous PR, the issue still exists but I'm investigating it.
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
force-pushed
the
feat/add-al2023-template
branch
2 times, most recently
from
9dba5e5 to
897084e
Compare
electricalgorithm
changed the title
electricalgorithm
changed the title
|
Update: The mount problem is gone, and it's possible to update the image to the latest one within a new script under I'll check the unit test and the lining stuff later. Does it look OK to you? |
electricalgorithm
force-pushed
the
feat/add-al2023-template
branch
2 times, most recently
from
b48521f to
dedcd61
Compare
|
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 |
|
I still don't want new commits to Lima every two (just to bump a snapshot version) every two weeks |
|
|
||
| # Workaround for Amazon Linux 2023 | ||
| if [ -f /etc/os-release ] && grep -q "Amazon Linux" /etc/os-release; then | ||
| # 1. Create missing mount.virtiofs helper |
There was a problem hiding this comment.
Would it be possible to just fix this issue in the Amazon Linux upstream?
There was a problem hiding this comment.
Curious why this issue happens specifically with Amazon Linux. I thought it was very similar to Fedora?
There was a problem hiding this comment.
I can cut a ticket to the team, but I think it should not be the concern of this PR. We can go with the current upstream approach, and when the fix is there, remove the patch here.
There was a problem hiding this comment.
I think it should not be the concern of this PR
Why not.
|
ping @electricalgorithm |
|
I'll update the PR as soon as possible. |
electricalgorithm
force-pushed
the
feat/add-al2023-template
branch
3 times, most recently
from
f18c355 to
4564989
Compare
It should not be. We can update it on every two weeks by the hack script, but in the end provision script will handle it for us automatically. |
|
Hey people, Sorry for being late. Quite busy months in Winter, as you can imagine. I updated the PR with a change to the latest image and addressed your comments. Please review the code once more, although it does not have much changes. There seems to be issue on GitHub's CI checks. The Lints job failed due to a README's link issue which the PR does not have any modification. I believe there's another issue there. On the vz's integation test job, I couldn't understand if that was my changes breaking it, but after discussing with GitHub's Copilot, looks like it is regarding to setup of the job. Can you verify that the failures are not related to the PR? If all looks good, please check the version string in the template -- which is 1.2.1 right now and check if it's possible to merge it until the release window closes. Kindest regards, |
This commit adds a simple template for the Amazon Linux 2023 operating system's 2026-04-06 version. The OS is scheduled to release every two weeks, therefore, a new script called hack/update-template-amazonlinux.sh is added next to the other template updater scripts. Find the latest images here: https://cdn.amazonlinux.com/al2023/os-images/latest/ This patch: - Adds amazonlinux-2023 template with 2026-04-06 release. - Resolves mount issues on AL2023 with host OS. release. - Adds update-template-amazonlinux.sh script to help maintainers automatically update the verison. Signed-off-by: Gyokhan Kochmarla <hello@gyokhan.com>
electricalgorithm
force-pushed
the
feat/add-al2023-template
branch
from
4564989 to
2c60121
Compare
|
Please review again :) I updated the code to apply your suggestions. |
|
Looks like the failure in jobs is due to the flakiness. Not related to the change. |
| # Amazon Linux 2023 requires a workaround for virtiofs mounts. | ||
| # The mount.virtiofs helper script is missing, and cloud-init | ||
| # may fail to mount the filesystems. This creates the helper | ||
| # and manually mounts them. |
There was a problem hiding this comment.
Does it still produce the valid /etc/fstab? If so, just running mount -a might be fine here?
There was a problem hiding this comment.
I start a new AL2023 KVM to check and it seems that the fstab does not have the virtiofs configs. Therefore, mount -a does not work and we need to parse them from cloud init config's user-data. That was a nice catch by the way. I'm not super into OSes, thanks for the advice!
There was a problem hiding this comment.
Why doesn't it generate fstab?
/var/log/cloud-init.log:
2026-04-16 07:52:01,442 - util.py[DEBUG]: Cloud-init v. 22.2.2 running 'init-local' at Thu, 16 Apr 2026 07:52:01 +0000. Up 1.95 seconds.
[...]
2026-04-16 07:52:04,763 - cc_mounts.py[DEBUG]: mounts configuration is [['lima-648190f135cc8172', '/Users/suda', 'virtiofs', 'ro,nofail', '0', '0']]
2026-04-16 07:52:04,763 - util.py[DEBUG]: Reading from /etc/fstab (quiet=False)
2026-04-16 07:52:04,763 - util.py[DEBUG]: Read 217 bytes from /etc/fstab
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Attempting to determine the real name of lima-648190f135cc8172
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: changed lima-648190f135cc8172 => None
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Ignoring nonexistent named mount lima-648190f135cc8172
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Attempting to determine the real name of ephemeral0
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: changed default device ephemeral0 => None
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Ignoring nonexistent default named mount ephemeral0
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Attempting to determine the real name of swap
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: changed default device swap => None
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Ignoring nonexistent default named mount swap
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: Skipping nonexistent device named None
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: no need to setup swap
2026-04-16 07:52:04,764 - cc_mounts.py[DEBUG]: No modifications to fstab needed
2026-04-16 07:52:04,764 - handlers.py[DEBUG]: finish: init-network/config-mounts: SUCCESS: config-mounts ran successfully
There was a problem hiding this comment.
Maybe related to "AL2023 contains a customized version of cloud-init."
|
Can you re-run the GitHub jobs and merge it if looks good to you since all conversations are resolved @AkihiroSuda? |
| USER_DATA="/var/lib/cloud/instance/user-data.txt" | ||
| if [ -f "${USER_DATA}" ]; then | ||
| # Parse all mount entries from user-data (mount0, mount1, ...) | ||
| MOUNT_ENTRIES=$(grep -E '^\s*-\s+\[mount[0-9]+,' "${USER_DATA}" || true) |
There was a problem hiding this comment.
This grep didn't work for me
[root@lima-amazonlinux ~]# head /var/lib/cloud/instance/user-data.txt
#cloud-config
# vim:syntax=yaml
growpart:
mode: auto
devices: ['/']
mounts:
- [lima-648190f135cc8172, /Users/suda, virtiofs, "ro,nofail", "0", "0"]
timezone: Asia/Tokyo
[root@lima-amazonlinux ~]# grep -E '^\s*-\s+\[mount[0-9]+,' /var/lib/cloud/instance/user-data.txtThere was a problem hiding this comment.
How did you test your PR?
In what condition user-data can have mounts named mount0, mount1, etc.?
|
|
||
| # Workaround for Amazon Linux 2023 | ||
| if [ -f /etc/os-release ] && grep -q "Amazon Linux" /etc/os-release; then | ||
| # 1. Create missing mount.virtiofs helper |
There was a problem hiding this comment.
Why is this helper needed in the first place when we have to execute the mount command by ourselves?
There was a problem hiding this comment.
The helper doesn't even seem to exist on other distros, such as almalinux-9
3 participants
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: