Skip to content
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

mkimage-raw-efi references lower-level serial container dir directly and shouldn't #4056

Closed
deitch opened this issue Jul 4, 2024 · 4 comments
Labels
question Further information is requested

Comments

@deitch
Copy link
Contributor

deitch commented Jul 4, 2024

The pkg mkimage-raw-efi references the specific path of an onboot container:

# Before changing something here please take a look into the
# images/rootfs.yml.in onboot section: the installer should
# precede the storage-init container.
#
# now lets create an edge container
# FIXME: 002-installer? why not linuxkit build?
WORKDIR /eco/media/root-rw/root/containers/onboot/002-installer
COPY runtime.json config.json ./
RUN mv /out rootfs
# hadolint ignore=DL3003
RUN (cd /eco && find . -xdev | grep -v installer.img | sort | cpio --quiet -o -H newc) | gzip > rootfs/installer.img
RUN mv rootfs /out

This even has a FIXME, and comments in the main rootfs.yml.im to change that if you add anything that changes the onboot order.

Similar code exists in mkverification-raw-efi.

Why is this necessary? What can we do to make this cleaner, as it is messy and almost guaranteed to break in odd ways in the future.

@rouming do you know what this does, i.e. its intended behaviour? You have the commit on mkverification-raw-efi and on mkimage-raw-efi.

Maybe there is nothing better, but we should try.

@deitch deitch added the question Further information is requested label Jul 4, 2024
@rene
Copy link
Contributor

rene commented Jul 15, 2024

@deitch , AFAIU this is done is order to "inject" the installer container only in the installer images.... we could use some .yq image modifier file for that, but that requires some changes to support not only PLATFORM variants, but also different image variants (installer, live, etc...)...

@deitch
Copy link
Contributor Author

deitch commented Jul 15, 2024

Yeah, if we can do it at a higher level, that would be cleaner. The whole pipeline is about, "I build a rootfs.tar, then I convert its contents to ext4 or squashfs or iso9660 or whatever." This sounds like it is a different rootfs.tar content, which we manipulate using the yml inputs.

Did I misunderstand?

Conversely, we could have it always there, but enable/disable it via some filesystem flag, like files:, but do we always want it there? Probably not?

The number of variants of eve is exploding!

@deitch
Copy link
Contributor Author

deitch commented Aug 14, 2024

@rene do you mind explaining this a bit more? How does this work? I see that mkimage-raw-efi - which we use whenever we build an EVE image - goes to one of the onboot containers path at /eco/media/root-rw/root/containers/onboot/002-installer, modifies the container config with a custom runtime.json and config.json, and then generates an installer.img inside /eco/rootfs?

Is it that this section of the Dockerfile is basically an "aside"? Or a stage where we put everything to the side, generate an installer.img, and then move everything back?

If we removed these lines of code, would we then have everything normal except would be missing an installer?

If so, the part I really don't get is, wouldn't that be part of the EVE docker image, the one we can run with docker run lfedge/eve <cmd>? What is it doing as part of mkimage-raw-efi? Or is this run at device installation time? But that cannot be, because you need the EFI disk image before you can boot?

@deitch
Copy link
Contributor Author

deitch commented Sep 24, 2024

This is closed via #4248

@deitch deitch closed this as completed Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants