arch-boxes-arm is not updated since v20220323

[AkihiroSuda]

lima/templates/archlinux.yaml

Line 8 in 5fb9353

- location: "https://github.com/mcginty/arch-boxes-arm/releases/download/v20220323/Arch-Linux-aarch64-cloudimg-20220323.0.qcow2"

@mcginty Would it be possible to update the image to the latest revision? 🙏
Also curious if the images can be pushed to http://os.archlinuxarm.org/os

[kairveeehh]

hii , is this issue up to be worked upon , would like to take it up .

[jandubois]

@kairveeehh How do you intend to work on this? The Lima project doesn't publish OS images itself. We rely on the various distros (or their communities) to publish up-to-date images with cloud-init support.

[kairveeehh]

@kairveeehh How do you intend to work on this? The Lima project doesn't publish OS images itself. We rely on the various distros (or their communities) to publish up-to-date images with cloud-init support.

isee then it was a confusion from my side , I thought it has to be done the opposite way so would update as per the issue, my bad 😅
Only the mentioned person can probably do this, as it's being taken from a url mentioned which will be updated .

[mschirrmeister]

I tried to update the image but all the other issues that are mentioned here like #858 or #2866 will not be fixed using latest packages. Something fundamental seems to be wrong with the boot process or maybe boot components.
I guess there is an issue with vz and UEFI in the early boot process.

Using it directly with qemu-system-aarch64 works fine. I will share in the coming days a workaround how you can build a working image.

[mschirrmeister]

TLDR, use this for now. https://github.com/mschirrmeister/archlinux-lima/

As a workaround you could use the generic UEFI installer from here. https://github.com/kwankiu/archlinux-installer
You would need to use the image via qemu and run through the install process once. After it is finished you can use the image in a new template.

Since this is not very user friendly, I created an installer that creates a basic Archlinux ARM image. See repo above. You can use the qcow2.xz image from Github release page or build your own image.

I will file a pull request and hopefully we can include the new image in Lima.

[AkihiroSuda]

Thanks @mschirrmeister have you analyzed the cause of this issue? https://github.com/mschirrmeister/archlinux-lima/blob/6aa2d4ba52a1de5a5897669c9dbdfd91e3c88466/.github/workflows/build_image_cloud.yaml#L14

# We use self-hosted runner, because Github creates images that are twice as big as the ones created on self-hosted runner
# ~ 300MB vs ~ 600MB

Ideally the images should be built on the standard GHA with GitHub Artifact Attestations for verifiability.

[afbjorklund]

Ideally the images should be produced by the upstream distribution, like they are with all the others - instead of having to be special cased downstream...

Like how the Raspbian distro moved into Debian proper?

[mschirrmeister]

Thanks @mschirrmeister have you analyzed the cause of this issue? https://github.com/mschirrmeister/archlinux-lima/blob/6aa2d4ba52a1de5a5897669c9dbdfd91e3c88466/.github/workflows/build_image_cloud.yaml#L14

I tried to analyze it, but could not figure out the real issue that is causing it. The script that runs everything is the same so that could be excluded. That means there is no difference what or how many packages get installed in the image.
Github runner was Ubuntu x86_64 or arm64. Locally I had directly on Arch Linux on a RK3588 sbc and also an Ubuntu runner in Docker on that Arch machine. Based on that, the OS itself should not be the problem.

In the script, I tried to fill the disk with zeros (dd) and delete that file again, as a last step after everything was installed. To clean up the filesystem that was allocated and freed during all the install processes. That made only a few MB difference, so it could be ruled out as well.

I added the filesystem options when the ext4 gets created -E lazy_itable_init=1,lazy_journal_init=1. Did also not make any difference.

mkfs.ext4 was more or less the same version, only the patch level digit was different.
xz I did not check the version yet. Not sure if there could be such a difference between versions.

Maybe it is related to how sparse files are handled on Github. My current guess is that it might be somehow related to the underlying storage where these runner VMs run on.

Ideally the images should be built on the standard GHA with GitHub Artifact Attestations for verifiability.

I have switched to GHA and enabled attestation.

[mschirrmeister]

Ideally the images should be produced by the upstream distribution, like they are with all the others - instead of having to be special cased downstream...

Ideally yes. But when you see posts like this, with no responses, it somewhat looks the Arch Linux ARM team is maybe not interested in it?
https://archlinuxarm.org/forum/viewtopic.php?t=15974
https://archlinuxarm.org/forum/viewtopic.php?t=16013

They don't even have cloud-init in the extra repo like on x86_64.

[mcginty]

FWIW I had proposed upstream changes around when I released this one-off image to Arch Linux ARM on IRC to make it easier to distribute images like this, and I did not receive interest at the time and eventually gave up on trying to advocate against the stream on it.

[SuperGregM]

Built a new script to build Archlinux The Arch Way
with pacstrap (base linux-aarch64 archlinuxarm-keyring grub efibootmgr cloud-guest-utils cloud-init openssh)
uses a github arm64 workflow to build and attest the images
still Around 300MB images
cloud-init still archlinux.org any processor package
cloud-guest-utils for rootfs auto-resize
SuperGregM/archlinux-arm-lima

##OLD##
Hi I have used mschirrmeister/archlinux-lima forked the repo and think I got the bugs out.

Around 300MB images
Updated cloud-init to use archlinux.org any processor package
Added cloud-guest-utils for rootfs auto-resize

My forked repo https://github.com/SuperGregM/archlinux-lima

I have left a pull request
mschirrmeister/archlinux-lima#1 (comment)