Add support for aboot images and aarch64

[alexlarsson]

Aboot image support in bootc was added in bootc-dev/bootc#2490. This PR makes such images runnable via bcvk. Note, this is just the support for ephemeral running of the images. For "to-disk" to work as well we will need work in "bootc install to-disk".

The aboot support itself is just the final commit that adds support for finding the aboot artifacts and extracting the kernel/initrd. The remaining commits are general fixes for aarch64, support for bootconfig chunks (as used by aboot in some cases) and a console input fix.

[cgwalters]

Really nicely split up series, looks great overall just one important thing, this will conflict heavily with #329 so we need to decide which comes first

[cgwalters]

I had never heard of this tool. Interesting, kernel-tools package.

[alexlarsson]

Ok, i rebased as there were some conflicts with main. Also I split out two separate PRs: #387 and #388. The later has the first commits from this PR that won't conflict with #329, so we can merge it earlier if we want to wait with this one.

[alexlarsson]

Ok, rebased on the merged preparatory PRs

[alexlarsson]

@cgwalters Maybe we should switch to the composefs-rs code to extract the kernel from the uki/aboot instead of shelling out stuff?

[cgwalters]

@cgwalters Maybe we should switch to the composefs-rs code to extract the kernel from the uki/aboot instead of shelling out stuff?

Yes, though it kind of escalates notably the amount of code that would be linked here.

In an ideal world I do think it's right to use some kind of CLI - over varlink, you could imagine we do that in bootc or cfsctl

[cgwalters]

Anyways since #329 got closed this one is clear I think

[alexlarsson]

@cgwalters Maybe we should switch to the composefs-rs code to extract the kernel from the uki/aboot instead of shelling out stuff?

Yes, though it kind of escalates notably the amount of code that would be linked here.

In an ideal world I do think it's right to use some kind of CLI - over varlink, you could imagine we do that in bootc or cfsctl

Honestly, that doesn't seem ideal to me. In an ideal world the aboot and uki parsers would be in a standalone crate that is cheap (not a lot of code) to import, used both in composefs and bcvk, rather than code sharing by spawning binaries. But, there is a cost to splitting out all these codebases as well.

[alexlarsson]

I mean, we're not talking about a lot of code:

File                             blank        comment           code
-------------------------------------------------------------------------------
uki.rs                              62            107            376
android_boot.rs                     24             24            286

To avoid some pretty huge dependencies like objcopy and android-tools.

[alexlarsson]

Maybe we could have some build options in composefs-boot to skip the dependencies on the rest of composefs-rs. I'll have a look.

[cgwalters]

Maybe we could have some build options in composefs-boot to skip the dependencies on the rest of composefs-rs. I'll have a look.

I would bet money that LTO is able to dead-code eliminate the rest, but yeah if we're diong it it would make sense to formally support via build opt

[alexlarsson]

I would bet money that LTO is able to dead-code eliminate the rest, but yeah if we're diong it it would make sense to formally support via build opt

I'm pretty sure the final thing will not have any unnecessary code linked in. But, you'd still probably get a bunch of versioned deps in the lock file, and a lot of work going on looking at these dependencies during the build.

[alexlarsson]

I rebased this to fix some conflicts. Also, depending on if we want to do #397 this would have to have some changes.

[cgwalters]

Also, depending on if we want to do #397 this would have to have some changes.

We can do that after I think right?