Add basic support to build EC2 cloud images #18
Conversation
|
I feel like this needs to switch from shell to something more manageable in the long term. Some TODOs inline. Shared to get early feedback. Neither cloud-init-like functionality nor automatic networking are included but access from serial console allows to configure the remaining bits for now. |
|
Also, this probably generalises to more cloud providers and basically any virtualisation stack that can run a raw image in UEFI. |
|
Also, this is only for AMD64 here, but ARM64 (aarch64) should be similarly fine to add. |
|
i want to add support into cloud-init, i don't think we should be doing this manually |
Perfect. I was thinking about trying something more lightweight to align with the lightweightness of chimera. Specifically, I was thinking about glean: https://opendev.org/opendev/glean I know it works very fine across OpenStack installations but never used it with proprietary cloud providers...
What do you mean? I.e., doing what manually? If you mean in terms of cloud-init-like functionalities, then yes, we should rely on that de-facto standard, at least for the most used parts. |
This restores its ability to run on non-Chimera.
systemd-boot is modern, GPL-2.0, works more consistently across archs, and its config is more FAT32-friendly.
|
Another TODO: secure the default fstab entry for the boot partition to make systemd-boot happier (and early randomness security a bit more too). |
Nothing beyond OpenStack with config-drives is supported so glean is a no-go. Meanwhile, I've found https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud but it's focused on Alpine Linux, and https://github.com/clearlinux/micro-config-drive (in C!) but it's limited to config-drives as well. So, it seems to me the best way forward is to adapt cloud-init accordingly. @q66 where can I find your effort so far? Any notes and whatever else you have would be appreciated. :-) |
| [ -d /dev/disk/by-uuid ] || die "/dev/disk/by-uuid not found, gen-systemd-boot would be misled" | ||
| mount_pseudo | ||
| # NOTE(yoctozepto): aarch64 requires console= config, else it hangs (as of 20240731 on EC2 t4g) | ||
| # TODO(yoctozepto): aarch64 rootfs already has the initramfs |
There was a problem hiding this comment.
@q66 Despite that I wrote just about aarch64, now also x86_64 gets the initramfs before this stage. It gets created whenever linux-lts is installed due to initramfs hooks. It was not the case even though the history suggests the same hook was installed (was it blocked from running?). Anyhow, that effort is partially wasted because the initramfs generator has no idea about the UUID of the block device for resume operations - it is going to miss it. Thus, I could skip installing linux-lts at rootfs level and postpone it till now (then get just one, proper build) - this is a bit ugly as it splits the pkg installation effort (also, as an alternative, the entire non-bootstrap part of pkgs could be installed on a loop device for sanity - although this introduces more complexity in the process) - or the previous behaviour could be restored - or else we simply decide to waste the original initramfs build and be fine with that (that's also an option). WDYT?
|
NOTE-TO-SELF: This image is good enough across major cloud providers/services (AWS, GCP, OpenStack) so can be renamed to "cloud". ALSO: Despite lack of cloud-init, it can be easily made more friendly (albeit less secure) - by not requiring configuration via a serial console - and instead enabling dhcpcd and sshd with root password auth allowed (that's why less secure) - the only scenario this won't cover would be static addressing but this basically needs proper cloud-init support to be manageable. |
No description provided.