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

tools: Fix kernel asset for NET installer #3702

Merged
merged 1 commit into from
Jan 12, 2024

Conversation

rene
Copy link
Contributor

@rene rene commented Jan 11, 2024

Due to the kernel build changes, the kernel binary asset is not copied to bits/ folder anymore, leading to the following error of the tools/makenet.sh script while building NET installer images:

ipxe.efi.cfg
tar: kernel: No such file or directory
initrd.img
installer.img
initrd.bits
rootfs.img
tar: error exit delayed from previous errors

Now that different kernel packages can be specified with the KERNEL_TAG variable, an approach to fix this issue is to pick the kernel image directly from the final rootfs image. However, this would require manipulate the rootfs image inside the Alpine container used by the makenet.sh script. An easier way (implemented by this commit) is to use the rootfs tarball and pick the kernel image from there, which will work regardless of the type of the rootfs image (squashfs, ext4, etc).

Due to the kernel build changes, the kernel binary asset is not copied to
bits/ folder anymore, leading to the following error of the
tools/makenet.sh script while building NET installer images:

ipxe.efi.cfg
tar: kernel: No such file or directory
initrd.img
installer.img
initrd.bits
rootfs.img
tar: error exit delayed from previous errors

Now that different kernel packages can be specified with the KERNEL_TAG
variable, an approach to fix this issue is to pick the kernel image
directly from the final rootfs image. However, this would require
manipulate the rootfs image inside the Alpine container used by the
makenet.sh script. An easier way (implemented by this commit) is to use
the rootfs tarball and pick the kernel image from there, which will work
regardless of the type of the rootfs image (squashfs, ext4, etc).

Signed-off-by: Renê de Souza Pinto <rene@renesp.com.br>
@rene rene requested a review from jsfakian January 11, 2024 12:03
@jsfakian
Copy link
Contributor

LGTM

@rene
Copy link
Contributor Author

rene commented Jan 11, 2024

Unit tests failing here are not related to the changes of this PR... they are failing on master as well...
FYI: @rouming , @eriknordmark , @milan-zededa

@milan-zededa
Copy link
Contributor

milan-zededa commented Jan 11, 2024

Unit tests failing here are not related to the changes of this PR... they are failing on master as well... FYI: @rouming , @eriknordmark , @milan-zededa

I will fix those in separate PR (DONE: #3703), just ignore it here.
Strangely enough, on my PR those unit tests failed but check is shown green (hence missed): https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206

@rene
Copy link
Contributor Author

rene commented Jan 11, 2024

Unit tests failing here are not related to the changes of this PR... they are failing on master as well... FYI: @rouming , @eriknordmark , @milan-zededa

I will fix those in separate PR (DONE: #3703), just ignore it here. Strangely enough, on my PR those unit tests failed but check is shown green (hence missed): https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206

Yeah, that's strange, but the errors are there as well, for instance: https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206#step:3:633, https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206#step:3:446

@milan-zededa
Copy link
Contributor

Unit tests failing here are not related to the changes of this PR... they are failing on master as well... FYI: @rouming , @eriknordmark , @milan-zededa

I will fix those in separate PR (DONE: #3703), just ignore it here. Strangely enough, on my PR those unit tests failed but check is shown green (hence missed): https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206

Yeah, that's strange, but the errors are there as well, for instance: https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206#step:3:633, https://github.com/lf-edge/eve/actions/runs/7423588723/job/20201342206#step:3:446

I know, but the point is that if check is green nobody will look inside and failures thus propagate to another PR.

Copy link
Contributor

@eriknordmark eriknordmark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@eriknordmark eriknordmark merged commit 6571c96 into lf-edge:master Jan 12, 2024
35 of 46 checks passed
@rene rene deleted the fix-installer-net branch January 15, 2024 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants