-
Notifications
You must be signed in to change notification settings - Fork 14
Move to a post post-image world #1267
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
Conversation
bf65879 to
8d8f587
Compare
A bunch of different artifacts should follow the same naming scheme, depending on a bunch of config settings + whether we're building a release or not. Therefore, provide a single definition of this that we can reuse to name disk images, upgrade packages, etc.
The board/*/*/*.mk is very broad, intended to hit all board specific definitions, but may also cause duplicate inclusions, e.g., in board/common. Let each architecture do the inclusion instead.
Rather than using the creation of a signed image as a proxy for whether the trusted keys should be installed RAUC/U-Boot's trust stores, use the dedicated option.
Add scaffolding for breaking out image generation to separate make targets.
Add a generic image target to build aux.ext4, which can be used both when creating target-specific SD-card images, and when creating regular disk images. While we're here, make sure that we don't need a RAUC bundle in order to generate aux.ext4 (which mkrauc-status.sh did). This saves us time on _every_ incremental build.
We have not installed .dtb:s to $O/images/ for quite some time, and nobody cared. That goes to show that this is not really used. The image is still useful at times, so if it needed in the future, then we can resurrect it from the logs and refactor it to an image package.
Limit support to x86, like we do on the "official" appliances on the marketplace. Aarch64 has never really been used AFAIK. Avoid the os-release import, since all that info is not important now that these appliance files are only for development scenarios. In all other cases, the official one, based on a proper release, should be used.
This is an internal artifact, so there is no need to give it a branded name.
Remnants from the olde country.
Now that all components are generated from their own fragments, we have no need for post-image.sh anymore.
Previously, post-image.sh was able to create QEMU images from an existing release tarball. This was useful when you wanted to test a new bootloader build without having to wait for a full Infix build. Restore this capability by adding a separate image target for it, and then allow image-itb-qcow to source its input images from that instead of a locally build squash+aux.
This CPU has less emulation overhead than `max`, which is what we mostly care about.
Use the new image-itb-dl-release to compose a QCOW with Infix and U-Boot, in the same way that we previously did in post-image.sh.
troglobit
left a comment
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.
Much needed cleanup, nice work!
|
One failing test on Not sure what happened there (or why the report was not uploaded). But seems more likely to be some flaky thing in the test (given that it was added very recently), or what do you think @troglobit? |
Agreed, very likely flaky new test. Created #1303 for this. |
Description
Checklist
Tick relevant boxes, this PR is-a or has-a: