suse-edge/Factory
SHA256
14
0
Fork 15
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updates SUSE Edge 3.2 branch with updated Kiwi image builder base #124

Closed
roxenham wants to merge 1 commits from roxenham/Factory:kiwi-image-6.0 into 3.2
pull from: roxenham/Factory:kiwi-image-6.0
merge into: suse-edge:3.2
Conversation 5 Commits 1 Files Changed 2 +12 -12
roxenham commented 2025-04-17 14:20:45 +02:00
Owner
Copy Link

In December 2024, the upstream Kiwi team dropped the md5 checksum for generated
images and went with sha256, for good reason:

d4d39e481a

These changes have recently been reflected in updated dracut-kiwi-oem-repart
and dracut-kiwi-oem-dump Dracut modules, bumping to a 10.2 codebase, which
expect the sha256 checksum to be available at install time on SelfInstall ISO
images. However, in the current branch of the Kiwi builder, we use 10.1, which
generates md5 checksums, resulting in an error at deployment time as the Dracut
modules cannot find the sha256 checksum file.

NOTE: This is being put into the 3.2 branch only right now, as it relies on
Micro 6.0; the Kiwi changes have not yet permeated into Micro 6.1, so we'll
need to forward-port this into 3.3 when 6.1 has the new modules. Micro 6.1
images can still be built successfully on the Kiwi 10.1 branches with md5.

In December 2024, the upstream Kiwi team dropped the md5 checksum for generated images and went with sha256, for good reason: https://github.com/OSInside/kiwi/commit/d4d39e481aaff8be28337a9c76c3913a8a482628 These changes have recently been reflected in updated `dracut-kiwi-oem-repart` and `dracut-kiwi-oem-dump` Dracut modules, bumping to a 10.2 codebase, which expect the sha256 checksum to be available at install time on SelfInstall ISO images. However, in the current branch of the Kiwi builder, we use 10.1, which generates md5 checksums, resulting in an error at deployment time as the Dracut modules cannot find the sha256 checksum file. NOTE: This is being put into the 3.2 branch *only* right now, as it relies on Micro 6.0; the Kiwi changes have not yet permeated into Micro 6.1, so we'll need to forward-port this into 3.3 when 6.1 has the new modules. Micro 6.1 images can still be built successfully on the Kiwi 10.1 branches with md5.
roxenham added 1 commit 2025-04-17 14:20:45 +02:00
Updates SUSE Edge 3.2 branch with updated Kiwi image builder base
All checks were successful
Build PR in OBS / Build PR in OBS (pull_request_target) Successful in 11s
Details
923439b5e6 
In December 2024, the upstream Kiwi team dropped the md5 checksum for generated
images and went with sha256, for good reason:

d4d39e481a

These changes have recently been reflected in updated `dracut-kiwi-oem-repart`
and `dracut-kiwi-oem-dump` Dracut modules, bumping to a 10.2 codebase, which
expect the sha256 checksum to be available at install time on SelfInstall ISO
images. However, in the current branch of the Kiwi builder, we use 10.1, which
generates md5 checksums, resulting in an error at deployment time as the Dracut
modules cannot find the sha256 checksum file.

NOTE: This is being put into the 3.2 branch *only* right now, as it relies on
Micro 6.0; the Kiwi changes have not yet permeated into Micro 6.1, so we'll
need to forward-port this into 3.3 when 6.1 has the new modules. Micro 6.1
images can still be built successfully on the Kiwi 10.1 branches with md5.
nbelouin approved these changes 2025-04-17 14:38:38 +02:00
fdegirmenci approved these changes 2025-04-21 17:05:31 +02:00
fdegirmenci left a comment
Owner
Copy Link

This passed in SV with manually built EIB 1.1.1-rc0 and RKE2 1.31.7 for the management cluster deployment: https://gitlab.suse.de/edge-engineering/stack-validation/-/pipelines/1687722

CAPI one is running as well: https://gitlab.suse.de/edge-engineering/stack-validation/-/pipelines/1687794

Ps. you can ignore the failed test case for the first pipeline as it is a timing issue. second pipeline just running the same set of test cases passed here: https://gitlab.suse.de/edge-engineering/stack-validation/-/pipelines/1687792

This passed in SV with manually built EIB 1.1.1-rc0 and RKE2 1.31.7 for the management cluster deployment: https://gitlab.suse.de/edge-engineering/stack-validation/-/pipelines/1687722 CAPI one is running as well: https://gitlab.suse.de/edge-engineering/stack-validation/-/pipelines/1687794 Ps. you can ignore the failed test case for the first pipeline as it is a timing issue. second pipeline just running the same set of test cases passed here: https://gitlab.suse.de/edge-engineering/stack-validation/-/pipelines/1687792
dirkmueller reviewed 2025-04-22 13:58:19 +02:00
kiwi-builder-image/Dockerfile
@@ -3,1 +1,3 @@
FROM registry.suse.com/bci/kiwi:10.1.16
#!BuildTag: %%IMG_PREFIX%%kiwi-builder:10.2.12.0
#!BuildTag: %%IMG_PREFIX%%kiwi-builder:10.2.12.0-%RELEASE%
FROM registry.suse.com/bci/kiwi:10.2.12
dirkmueller commented 2025-04-22 13:58:19 +02:00
Contributor
Copy Link

I wonder if this shouldn't be 10.2 - the 10.2.12 is not going to be "maintained" regularly by updates (it will stop seeing updates as soon as kiwi 10.2.13+ is being submitted and released). there is a floating tag "10.2" which refers to the latest "10.2.x" (as well as a "10" tag which would refer to any kiwi 10.x.y version.

I wonder if this shouldn't be `10.2` - the 10.2.12 is not going to be "maintained" regularly by updates (it will stop seeing updates as soon as kiwi 10.2.13+ is being submitted and released). there is a floating tag "10.2" which refers to the latest "10.2.x" (as well as a "10" tag which would refer to any kiwi 10.x.y version.
fdegirmenci commented 2025-04-22 15:39:34 +02:00
Owner
Copy Link

As this is a released version, I wonder if it makes sense to pin to the specific version, 10.2.12, rather than the floating tag, 10.2, which might change without us noticing + making it difficult to reproduce if the issues occur as what we include in the release this week might not be the same with what customers might be using in 2 months from now.

Edit after thinking a minute - this might not be an issue actually considering we won't be changing the image after the release but pinning to a specific version for the release purposes still makes sense to me.

As this is a released version, I wonder if it makes sense to pin to the specific version, `10.2.12`, rather than the floating tag, `10.2`, which might change without us noticing + making it difficult to reproduce if the issues occur as what we include in the release this week might not be the same with what customers might be using in 2 months from now. Edit after thinking a minute - this might not be an issue actually considering we won't be changing the image after the release but pinning to a specific version for the release purposes still makes sense to me.
dirkmueller commented 2025-04-22 17:55:53 +02:00
Contributor
Copy Link

I think we have a mismatch between what we build and what we document here. I agree we shouldn't necessarily document people to use the very latest image if that hasn't been validated. so pinning that makes sense until there is control in releasing only working images.

However, for building we do need to find latest image. also on every z stream release I think we should be updating to the latest image becaues it includes other fixes.

BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it.

I think we have a mismatch between what we build and what we document here. I agree we shouldn't necessarily document people to use the very latest image if that hasn't been validated. so pinning that makes sense until there is control in releasing only working images. However, for building we do need to find latest image. also on every z stream release I think we should be updating to the latest image becaues it includes other fixes. BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it.
fdegirmenci commented 2025-04-22 18:01:55 +02:00
Owner
Copy Link

BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it.

Aha, this is news to me. Thanks for the info!

> BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it. Aha, this is news to me. Thanks for the info!
dirkmueller commented 2025-04-22 18:06:58 +02:00
Contributor
Copy Link

I made #129 as an alternative to this PR

I made https://src.opensuse.org/suse-edge/Factory/pulls/129 as an alternative to this PR
roxenham commented 2025-04-28 12:27:08 +02:00
Author
Owner
Copy Link

Let's close this in favour of #129

Let's close this in favour of #129
roxenham closed this pull request 2025-04-28 12:27:08 +02:00
All checks were successful
Build PR in OBS / Build PR in OBS (pull_request_target) Successful in 11s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
nbelouin
fdegirmenci
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
amorgante atanasdinov atrendafilov dbekhit dprodanov eminguez fdegirmenci geoagriogiannis ipetrov117 jtomasek kzhelyazkov mchiappero nbelouin roxenham steven.hardy
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: suse-edge/Factory#124
No description provided.
Delete Branch "roxenham/Factory:kiwi-image-6.0"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?