-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create amazonlinux2023 template #2537
Conversation
Please fix lint error (remove trailing spaces on first line) and apply DCO signature to the commit: https://github.com/lima-vm/lima/pull/2537/checks?check_run_id=28484568245 |
examples/amazonlinux2023.yaml
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The filename should be amazonlinux.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree because Amazon Linux, Amazon Linux 2, and Amazon Linux 2023 are different operating systems in the same way that Fedora & RedHat are different operating systems. Given #625 was denied, it's an important distinction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't get why the new distro (and later versions) can't be called "amazonlinux".
Does that mean that the new distro will be called "Amazon Linux 2023" practically forever, even in 2030s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, there will be "Amazon Linux 2025", "Amazon Linux 2027", etc in the future.
You can see the expected lifecycles at https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, there will be "Amazon Linux 2025", "Amazon Linux 2027", etc in the future.
So given that in 2027 there will be AL2023 and AL2025 in maintenance, and AL2027 will be the current version, I think it makes sense to include the "2023" in the name.
I wonder though if it should be amazonlinux-2023.yaml
, and then have an amazonlinux.yaml
symlink to it, similarly to how we have almalinux-9.yaml
or debian-12.yaml
. That way in the future we can symlink to amazonlinux-2025.yaml
while still keeping the old amazonlinux-2023.yaml
around until it is EOL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it has to go in experimental either, just because upstream is missing a symlink?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put it in experimental due to no latest
version and because it requires virtiofs
. Since virtiofs
requires experimental vz
on macOS, it made more sense. Do you want me to move it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it require virtiofs, or does it just not support 9p? I was thinking it would fall back to reverse-sshfs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazon Linux 2023 repository 13 MB/s | 26 MB 00:02
Amazon Linux 2023 Kernel Livepatch repository 2.2 kB/s | 8.3 kB 00:03
No match for argument: fuse-sshfs
Error: Unable to find a match: fuse-sshfs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, # CONFIG_NET_9P is not set
in kernel. So that means that it does indeed only support virtiofs
.
examples/amazonlinux2023.yaml
Outdated
vmType: "vz" | ||
mountType: "virtiofs" | ||
images: | ||
- location: "https://cdn.amazonlinux.com/al2023/os-images/2023.5.20240805.0/kvm/al2023-kvm-2023.5.20240805.0-kernel-6.1-x86_64.xfs.gpt.qcow2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these images persistent for years, or are they wiped periodically?
In the latter case, the "latest" image has to be specified as a fallback option.
(See other templates)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these images persistent for years, or are they wiped periodically?
I don't know, that's an Amazon question, sorry. To my knowledge there is no latest
option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these images persistent for years, or are they wiped periodically?
I think "somebody" will have to reach out to AWS to find out. I'll be offline soon, so I can't do it right now; ping me in September if it is still unresolved by then. 😄
Maybe ask the finch
people to find out who can help. They have a channel on the CNCF Slack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be left to just go 404 when it is removed, like with the other distributions?
The "latest" is a nice to have / recovery, but ultimately they all need bumping anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this image link fine for the purposes of the PR? It is an example of an experimental config, not a production config
There is a https://cdn.amazonlinux.com/al2023/os-images/latest/ link, but all filenames seem to be unique? https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2-download.html Maybe there could be an issue or documentation created upstream, how to link to the latest KVM image? https://aws.amazon.com/about-aws/whats-new/2023/12/amazon-linux-kvm-vmware-images-al2023-3/ Maybe finch wants to help out, as well ? Or I suppose you could just use |
Do you want a link to that in the example file? I think anything more than that is more than I want to do for the scope of this PR.
The two are different projects, I'm not sure how they relate, sorry.
Amazon Linux 2023 & Fedora are not the same despite many similarities. |
I moved it into experimental to allow for more user awareness of the state due to lack of |
I was just referring to that Amazon projects (like linux or finch) could make this easier for lima? The template itself doesn't need that information (at the moment), beyond the "latest" image. |
Unfortunately, I think this is the best we've got right now:
|
The update procedure is a separate topic (and not a requirement), many others also lack a good method. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM, but the file rename needs to be reflected in the README.
examples/README.md
Outdated
@@ -14,6 +14,7 @@ Distro: | |||
- [`almalinux-8`](./almalinux-8.yaml): AlmaLinux 8 | |||
- [`almalinux-9`](./almalinux-9.yaml), `almalinux.yaml`: AlmaLinux 9 | |||
- [`alpine`](./alpine.yaml): ☆Alpine Linux | |||
- [`amazonlinux2023.yaml`](./experimental/amazonlinux2023.yaml): [experimental] Amazon Linux 2023 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file has been renamed:
- [`amazonlinux2023.yaml`](./experimental/amazonlinux2023.yaml): [experimental] Amazon Linux 2023 | |
- [`amazonlinux-2023.yaml`](./experimental/amazonlinux-2023.yaml): [experimental] Amazon Linux 2023 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file is renamed on disk, so you need to rename it here in the README too, to match the actual filename.
Also please squash all commits.
You are missing the DCO sign-off. Also please squash commits! |
6c4f51f
to
57b88cd
Compare
Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Unfortunately not there yet:
-
The filenames in the README need to be updated to match the filenames on disk.
-
Adding a comment about the
mountType
would be nice. -
Commits need to be squashed.
examples/README.md
Outdated
@@ -14,6 +14,7 @@ Distro: | |||
- [`almalinux-8`](./almalinux-8.yaml): AlmaLinux 8 | |||
- [`almalinux-9`](./almalinux-9.yaml), `almalinux.yaml`: AlmaLinux 9 | |||
- [`alpine`](./alpine.yaml): ☆Alpine Linux | |||
- [`amazonlinux2023.yaml`](./experimental/amazonlinux2023.yaml): [experimental] Amazon Linux 2023 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file is renamed on disk, so you need to rename it here in the README too, to match the actual filename.
Also please squash all commits.
57b88cd
to
ad4a04e
Compare
Signed-off-by: Sienna Satterwhite <[email protected]>
ad4a04e
to
45865f7
Compare
Sorry, I didn't realise y'all use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
PR looks good to me now, but while testing it on Sonoma with M1 I noticed that the mounts didn't actually work. Do they work for anybody else?
@siennathesane Could you take a look at the mount issue? |
This PR has been enough effort just to share an experimental example. I think it's unclear to me what the purpose of examples are if there's such a high bar to share something that's also experimental. The intent of this PR was to share an example of what an AWS config could look like, because it's my understanding that these are examples, esp experimental ones. At this point if there's a reason not to merge, then go ahead and close the PR, but I'm not going to spend any more time on this. |
"examples" have been renamed to "templates" in #1679 to clarify that they are expected to be useful OOTB, but the git repo still uses The templates, especially experimental ones, may still have non-functional features. |
I've hit the same issue doing it from scratch before landing here... Cloud-init v. 22.2.2 running 'modules:config' at Mon, 14 Oct 2024 16:15:35 +0000. Up 9.95 seconds.
Cloud-init v. 22.2.2 running 'modules:final' at Mon, 14 Oct 2024 16:15:35 +0000. Up 10.15 seconds.
+ LIMA_CIDATA_MNT=/mnt/lima-cidata
+ LIMA_CIDATA_DEV=/dev/disk/by-label/cidata
+ mkdir -p -m 700 /mnt/lima-cidata
+ mount -o ro,mode=0700,dmode=0700,overriderockperm,exec,uid=0 /dev/disk/by-label/cidata /mnt/lima-cidata
+ export LIMA_CIDATA_MNT
+ exec /mnt/lima-cidata/boot.sh
LIMA 2024-10-14T18:15:35+02:00| Executing /mnt/lima-cidata/boot/00-alpine-user-group.sh
LIMA 2024-10-14T18:15:35+02:00| Executing /mnt/lima-cidata/boot/00-modprobe.sh
Loading kernel module "fuse"
Loading kernel module "tun"
Loading kernel module "tap"
Loading kernel module "bridge"
Loading kernel module "veth"
Loading kernel module "ip_tables"
Loading kernel module "ip6_tables"
Loading kernel module "iptable_nat"
Loading kernel module "ip6table_nat"
Loading kernel module "iptable_filter"
Loading kernel module "ip6table_filter"
Loading kernel module "nf_tables"
Loading kernel module "x_tables"
Loading kernel module "xt_MASQUERADE"
Loading kernel module "xt_addrtype"
Loading kernel module "xt_comment"
Loading kernel module "xt_conntrack"
Loading kernel module "xt_mark"
Loading kernel module "xt_multiport"
Loading kernel module "xt_nat"
Loading kernel module "xt_tcpudp"
Loading kernel module "overlay"
LIMA 2024-10-14T18:15:35+02:00| Executing /mnt/lima-cidata/boot/00-reboot-if-required.sh
+ command -v dnf
+ dnf -h needs-restarting
+ dnf needs-restarting -r
LIMA 2024-10-14T18:15:36+02:00| Executing /mnt/lima-cidata/boot/01-alpine-ash-as-bash.sh
LIMA 2024-10-14T18:15:36+02:00| Executing /mnt/lima-cidata/boot/02-wsl2-setup.sh
LIMA 2024-10-14T18:15:36+02:00| Executing /mnt/lima-cidata/boot/04-persistent-data-volume.sh
+ test -f /etc/alpine-release
+ exit 0
LIMA 2024-10-14T18:15:36+02:00| Executing /mnt/lima-cidata/boot/05-lima-disks.sh
+ test 0 -gt 0
+ exit 0
LIMA 2024-10-14T18:15:36+02:00| Executing /mnt/lima-cidata/boot/05-lima-mounts.sh
+ [[ vz == \v\z ]]
+ [[ virtiofs == \v\i\r\t\i\o\f\s ]]
+ '[' -d /sys/fs/selinux ']'
++ grep -n virtiofs
++ cut -d: -f1
LIMA 2024-10-14T18:15:36+02:00| Executing /mnt/lima-cidata/boot/05-rosetta-volume.sh
+ '[' true '!=' true ']'
+ '[' -f /etc/alpine-release ']'
+ binfmt_entry=/proc/sys/fs/binfmt_misc/rosetta
+ binfmtd_conf=/usr/lib/binfmt.d/rosetta.conf
+ '[' true = true ']' I have tried adding provision:
- mode: boot
script: |
# Load the virtiofs module at boot
modprobe virtiofs
# Ensure the module loads on every boot by adding it to the modules-load.d directory
echo "virtiofs" > /etc/modules-load.d/virtiofs.conf
#disable SELinux
grubby --update-kernel ALL --args selinux=0 but unfortunately, it seems like the boot step is executed after the mount ? Thanks for any potential advice from someone. |
Small update here 2024-10-14 16:55:05,857 - cc_mounts.py[DEBUG]: mounts configuration is [['vz-rosetta', '/mnt/lima-rosetta', 'virtiofs', 'defaults', '0', '0'], ['mount0', '/Users/christian.klat', 'virtiofs', 'rw,nofail', '0', '0'], ['mount1', '/tmp/lima', 'virtiofs', 'rw,nofail', '0', '0']]
2024-10-14 16:55:05,860 - util.py[DEBUG]: backgrounded Resizing took 0.006 seconds
2024-10-14 16:55:05,857 - util.py[DEBUG]: Reading from /etc/fstab (quiet=False)
2024-10-14 16:55:05,863 - util.py[DEBUG]: Read 217 bytes from /etc/fstab
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Attempting to determine the real name of vz-rosetta
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: changed vz-rosetta => None
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Ignoring nonexistent named mount vz-rosetta
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Attempting to determine the real name of mount0
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: changed mount0 => None
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Ignoring nonexistent named mount mount0
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Attempting to determine the real name of mount1
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: changed mount1 => None
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Ignoring nonexistent named mount mount1
2024-10-14 16:55:05,863 - cc_mounts.py[DEBUG]: Attempting to determine the real name of ephemeral0
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: changed default device ephemeral0 => None
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: Ignoring nonexistent default named mount ephemeral0
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: Attempting to determine the real name of swap
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: changed default device swap => None
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: Ignoring nonexistent default named mount swap
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: Skipping nonexistent device named None
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: Skipping nonexistent device named None
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: Skipping nonexistent device named None
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: no need to setup swap
2024-10-14 16:55:05,864 - cc_mounts.py[DEBUG]: No modifications to fstab needed
Seems like the cc_mounts.py is failing at performing the mounts.
|
Adds a default template reference for Amazon Linux 2023.