| Message ID | 20251203144621.2903536-1-Quirin.Gylstorff@siemens.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Fix initrd build depends after setting IMAGE_INITRD | expand |
On 12/3/25 15:45, Quirin Gylstorff wrote: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > As do_image is virtual task it is not executed, see log.taskorder. I'm a bit confused because do_image_tools seems also to be a virtual task in image.bbclass. Why this virtual task was executed? > > 20251203-141015.078894 do_fetch (8603): log.do_fetch.8603 > 20251203-141015.432653 do_unpack (8817): log.do_unpack.8817 > 20251203-141016.385643 do_copy_wks_template (9626): log.do_copy_wks_template.9626 > 20251203-141018.352672 do_check_swu_partition_uuids (11629): log.do_check_swu_partition_uuids.11629 > 20251203-142714.202649 do_rootfs_install (269893): log.do_rootfs_install.269893 > 20251203-142812.346458 do_copy_boot_files (278687): log.do_copy_boot_files.278687 > 20251203-142812.347572 do_deploy_tpm2_firmware (278688): log.do_deploy_tpm2_firmware.278688 > 20251203-142812.479116 do_rootfs_postprocess (278755): log.do_rootfs_postprocess.278755 > 20251203-142813.723336 do_generate_image_uuid (280155): log.do_generate_image_uuid.280155 > 20251203-142813.833043 do_rootfs_finalize (280281): log.do_rootfs_finalize.280281 > 20251203-142813.837689 do_transform_template (280287): log.do_transform_template.280287 > 20251203-142835.289802 do_rootfs_quality_check (303158): log.do_rootfs_quality_check.303158 > 20251203-142835.458624 do_rootfs (303179): log.do_rootfs.303179 > 20251203-142835.545966 do_image_tools (303194): log.do_image_tools.303194 > 20251203-142835.548904 do_rootfs_wicenv (303195): log.do_rootfs_wicenv.303195 > 20251203-142835.635904 do_image_squashfs (303216): log.do_image_squashfs.303216 > 20251203-142853.614060 do_image_verity (305205): log.do_image_verity.305205 > 20251203-142916.978304 do_image_wic (309278): log.do_image_wic.309278 > 20251203-145901.333675 do_image_wic (953): log.do_image_wic.953 > > To ensure that a custom initrd is always build attach the dependency > to do_image_tools instead. > > This fixes a problem with the new IMAGE_INITRD variable in case of > a multiconfig with two custom initrds. Can you elaborate on this issue? Is this related with initrd image not being generated? Zhihang > > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > --- > meta/classes/image.bbclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass > index b030024f..b6301e17 100644 > --- a/meta/classes/image.bbclass > +++ b/meta/classes/image.bbclass > @@ -32,7 +32,7 @@ IMAGE_INITRD ?= "" > INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }-${DISTRO}-${MACHINE}-initrd.img" > > # Make sure dependent initramfs recipe is built > -do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if '${IMAGE_INITRD}' else '' }" > +do_image_tools[depends] += "${@ '${IMAGE_INITRD}:do_build' if '${IMAGE_INITRD}' else '' }" > > # Produce warning(s) if INITRD_IMAGE is used > python() {
Hi On 12/9/25 13:02, Zhihang Wei wrote: > > > On 12/3/25 15:45, Quirin Gylstorff wrote: >> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> >> As do_image is virtual task it is not executed, see log.taskorder. > I'm a bit confused because do_image_tools seems also to be a virtual > task in image.bbclass. Why this virtual task was executed? I think do_image_tools has some implementation behind it due to wic in my case. >>>> 20251203-141015.078894 do_fetch (8603): log.do_fetch.8603 >> 20251203-141015.432653 do_unpack (8817): log.do_unpack.8817 >> 20251203-141016.385643 do_copy_wks_template (9626): >> log.do_copy_wks_template.9626 >> 20251203-141018.352672 do_check_swu_partition_uuids (11629): >> log.do_check_swu_partition_uuids.11629 >> 20251203-142714.202649 do_rootfs_install (269893): >> log.do_rootfs_install.269893 >> 20251203-142812.346458 do_copy_boot_files (278687): >> log.do_copy_boot_files.278687 >> 20251203-142812.347572 do_deploy_tpm2_firmware (278688): >> log.do_deploy_tpm2_firmware.278688 >> 20251203-142812.479116 do_rootfs_postprocess (278755): >> log.do_rootfs_postprocess.278755 >> 20251203-142813.723336 do_generate_image_uuid (280155): >> log.do_generate_image_uuid.280155 >> 20251203-142813.833043 do_rootfs_finalize (280281): >> log.do_rootfs_finalize.280281 >> 20251203-142813.837689 do_transform_template (280287): >> log.do_transform_template.280287 >> 20251203-142835.289802 do_rootfs_quality_check (303158): >> log.do_rootfs_quality_check.303158 >> 20251203-142835.458624 do_rootfs (303179): log.do_rootfs.303179 >> 20251203-142835.545966 do_image_tools (303194): log.do_image_tools.303194 >> 20251203-142835.548904 do_rootfs_wicenv (303195): >> log.do_rootfs_wicenv.303195 >> 20251203-142835.635904 do_image_squashfs (303216): >> log.do_image_squashfs.303216 >> 20251203-142853.614060 do_image_verity (305205): >> log.do_image_verity.305205 >> 20251203-142916.978304 do_image_wic (309278): log.do_image_wic.309278 >> 20251203-145901.333675 do_image_wic (953): log.do_image_wic.953 >> >> To ensure that a custom initrd is always build attach the dependency >> to do_image_tools instead. >> >> This fixes a problem with the new IMAGE_INITRD variable in case of >> a multiconfig with two custom initrds. > Can you elaborate on this issue? Is this related with initrd image not > being generated? The initrd was not generated - so we have a dependency issue. I think the main issue is the anonymous python task. Quirin> > Zhihang >> >> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> --- >> meta/classes/image.bbclass | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >> index b030024f..b6301e17 100644 >> --- a/meta/classes/image.bbclass >> +++ b/meta/classes/image.bbclass >> @@ -32,7 +32,7 @@ IMAGE_INITRD ?= "" >> INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }- >> ${DISTRO}-${MACHINE}-initrd.img" >> # Make sure dependent initramfs recipe is built >> -do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if >> '${IMAGE_INITRD}' else '' }" >> +do_image_tools[depends] += "${@ '${IMAGE_INITRD}:do_build' if >> '${IMAGE_INITRD}' else '' }" >> # Produce warning(s) if INITRD_IMAGE is used >> python() { >
On 12/9/25 13:10, Quirin Gylstorff wrote: > Hi > > On 12/9/25 13:02, Zhihang Wei wrote: >> >> >> On 12/3/25 15:45, Quirin Gylstorff wrote: >>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>> >>> As do_image is virtual task it is not executed, see log.taskorder. >> I'm a bit confused because do_image_tools seems also to be a virtual >> task in image.bbclass. Why this virtual task was executed? > > I think do_image_tools has some implementation behind it due to wic > in my case. > > >>>> 20251203-141015.078894 do_fetch (8603): log.do_fetch.8603 >>> 20251203-141015.432653 do_unpack (8817): log.do_unpack.8817 >>> 20251203-141016.385643 do_copy_wks_template (9626): >>> log.do_copy_wks_template.9626 >>> 20251203-141018.352672 do_check_swu_partition_uuids (11629): >>> log.do_check_swu_partition_uuids.11629 >>> 20251203-142714.202649 do_rootfs_install (269893): >>> log.do_rootfs_install.269893 >>> 20251203-142812.346458 do_copy_boot_files (278687): >>> log.do_copy_boot_files.278687 >>> 20251203-142812.347572 do_deploy_tpm2_firmware (278688): >>> log.do_deploy_tpm2_firmware.278688 >>> 20251203-142812.479116 do_rootfs_postprocess (278755): >>> log.do_rootfs_postprocess.278755 >>> 20251203-142813.723336 do_generate_image_uuid (280155): >>> log.do_generate_image_uuid.280155 >>> 20251203-142813.833043 do_rootfs_finalize (280281): >>> log.do_rootfs_finalize.280281 >>> 20251203-142813.837689 do_transform_template (280287): >>> log.do_transform_template.280287 >>> 20251203-142835.289802 do_rootfs_quality_check (303158): >>> log.do_rootfs_quality_check.303158 >>> 20251203-142835.458624 do_rootfs (303179): log.do_rootfs.303179 >>> 20251203-142835.545966 do_image_tools (303194): >>> log.do_image_tools.303194 >>> 20251203-142835.548904 do_rootfs_wicenv (303195): >>> log.do_rootfs_wicenv.303195 >>> 20251203-142835.635904 do_image_squashfs (303216): >>> log.do_image_squashfs.303216 >>> 20251203-142853.614060 do_image_verity (305205): >>> log.do_image_verity.305205 >>> 20251203-142916.978304 do_image_wic (309278): log.do_image_wic.309278 >>> 20251203-145901.333675 do_image_wic (953): log.do_image_wic.953 >>> >>> To ensure that a custom initrd is always build attach the dependency >>> to do_image_tools instead. >>> >>> This fixes a problem with the new IMAGE_INITRD variable in case of >>> a multiconfig with two custom initrds. >> Can you elaborate on this issue? Is this related with initrd image >> not being generated? > The initrd was not generated - so we have a dependency issue. I think > the main issue is the anonymous python task. > > Quirin> Can you try the patch I just sent? [PATCH] initramfs: Restore default "generate-initrd" logic in initramfs.bbclass. I want to know whether we have the same issue. Zhihang >> Zhihang >>> >>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>> --- >>> meta/classes/image.bbclass | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>> index b030024f..b6301e17 100644 >>> --- a/meta/classes/image.bbclass >>> +++ b/meta/classes/image.bbclass >>> @@ -32,7 +32,7 @@ IMAGE_INITRD ?= "" >>> INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }- >>> ${DISTRO}-${MACHINE}-initrd.img" >>> # Make sure dependent initramfs recipe is built >>> -do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if >>> '${IMAGE_INITRD}' else '' }" >>> +do_image_tools[depends] += "${@ '${IMAGE_INITRD}:do_build' if >>> '${IMAGE_INITRD}' else '' }" >>> # Produce warning(s) if INITRD_IMAGE is used >>> python() { >> >
On 12/9/25 13:28, Zhihang Wei wrote: > > > On 12/9/25 13:10, Quirin Gylstorff wrote: >> Hi >> >> On 12/9/25 13:02, Zhihang Wei wrote: >>> >>> >>> On 12/3/25 15:45, Quirin Gylstorff wrote: >>>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>> >>>> As do_image is virtual task it is not executed, see log.taskorder. >>> I'm a bit confused because do_image_tools seems also to be a virtual >>> task in image.bbclass. Why this virtual task was executed? >> >> I think do_image_tools has some implementation behind it due to wic >> in my case. >> >> >>>> 20251203-141015.078894 do_fetch (8603): log.do_fetch.8603 >>>> 20251203-141015.432653 do_unpack (8817): log.do_unpack.8817 >>>> 20251203-141016.385643 do_copy_wks_template (9626): >>>> log.do_copy_wks_template.9626 >>>> 20251203-141018.352672 do_check_swu_partition_uuids (11629): >>>> log.do_check_swu_partition_uuids.11629 >>>> 20251203-142714.202649 do_rootfs_install (269893): >>>> log.do_rootfs_install.269893 >>>> 20251203-142812.346458 do_copy_boot_files (278687): >>>> log.do_copy_boot_files.278687 >>>> 20251203-142812.347572 do_deploy_tpm2_firmware (278688): >>>> log.do_deploy_tpm2_firmware.278688 >>>> 20251203-142812.479116 do_rootfs_postprocess (278755): >>>> log.do_rootfs_postprocess.278755 >>>> 20251203-142813.723336 do_generate_image_uuid (280155): >>>> log.do_generate_image_uuid.280155 >>>> 20251203-142813.833043 do_rootfs_finalize (280281): >>>> log.do_rootfs_finalize.280281 >>>> 20251203-142813.837689 do_transform_template (280287): >>>> log.do_transform_template.280287 >>>> 20251203-142835.289802 do_rootfs_quality_check (303158): >>>> log.do_rootfs_quality_check.303158 >>>> 20251203-142835.458624 do_rootfs (303179): log.do_rootfs.303179 >>>> 20251203-142835.545966 do_image_tools (303194): >>>> log.do_image_tools.303194 >>>> 20251203-142835.548904 do_rootfs_wicenv (303195): >>>> log.do_rootfs_wicenv.303195 >>>> 20251203-142835.635904 do_image_squashfs (303216): >>>> log.do_image_squashfs.303216 >>>> 20251203-142853.614060 do_image_verity (305205): >>>> log.do_image_verity.305205 >>>> 20251203-142916.978304 do_image_wic (309278): log.do_image_wic.309278 >>>> 20251203-145901.333675 do_image_wic (953): log.do_image_wic.953 >>>> >>>> To ensure that a custom initrd is always build attach the dependency >>>> to do_image_tools instead. >>>> >>>> This fixes a problem with the new IMAGE_INITRD variable in case of >>>> a multiconfig with two custom initrds. >>> Can you elaborate on this issue? Is this related with initrd image >>> not being generated? >> The initrd was not generated - so we have a dependency issue. I think >> the main issue is the anonymous python task. >> >> Quirin> > Can you try the patch I just sent? [PATCH] initramfs: Restore default > "generate-initrd" logic in initramfs.bbclass. I want to know whether we > have the same issue. Your patch would also fix the issue. I had some problems as it was not based on next. Quirin> > Zhihang >>> Zhihang >>>> >>>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>> --- >>>> meta/classes/image.bbclass | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>>> index b030024f..b6301e17 100644 >>>> --- a/meta/classes/image.bbclass >>>> +++ b/meta/classes/image.bbclass >>>> @@ -32,7 +32,7 @@ IMAGE_INITRD ?= "" >>>> INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }- >>>> ${DISTRO}-${MACHINE}-initrd.img" >>>> # Make sure dependent initramfs recipe is built >>>> -do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if >>>> '${IMAGE_INITRD}' else '' }" >>>> +do_image_tools[depends] += "${@ '${IMAGE_INITRD}:do_build' if >>>> '${IMAGE_INITRD}' else '' }" >>>> # Produce warning(s) if INITRD_IMAGE is used >>>> python() { >>> >> >
On 12/9/25 16:12, Quirin Gylstorff wrote: > > > On 12/9/25 13:28, Zhihang Wei wrote: >> >> >> On 12/9/25 13:10, Quirin Gylstorff wrote: >>> Hi >>> >>> On 12/9/25 13:02, Zhihang Wei wrote: >>>> >>>> >>>> On 12/3/25 15:45, Quirin Gylstorff wrote: >>>>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>>> >>>>> As do_image is virtual task it is not executed, see log.taskorder. >>>> I'm a bit confused because do_image_tools seems also to be a >>>> virtual task in image.bbclass. Why this virtual task was executed? >>> >>> I think do_image_tools has some implementation behind it due to wic >>> in my case. >>> >>> >>>> 20251203-141015.078894 do_fetch (8603): log.do_fetch.8603 >>>>> 20251203-141015.432653 do_unpack (8817): log.do_unpack.8817 >>>>> 20251203-141016.385643 do_copy_wks_template (9626): >>>>> log.do_copy_wks_template.9626 >>>>> 20251203-141018.352672 do_check_swu_partition_uuids (11629): >>>>> log.do_check_swu_partition_uuids.11629 >>>>> 20251203-142714.202649 do_rootfs_install (269893): >>>>> log.do_rootfs_install.269893 >>>>> 20251203-142812.346458 do_copy_boot_files (278687): >>>>> log.do_copy_boot_files.278687 >>>>> 20251203-142812.347572 do_deploy_tpm2_firmware (278688): >>>>> log.do_deploy_tpm2_firmware.278688 >>>>> 20251203-142812.479116 do_rootfs_postprocess (278755): >>>>> log.do_rootfs_postprocess.278755 >>>>> 20251203-142813.723336 do_generate_image_uuid (280155): >>>>> log.do_generate_image_uuid.280155 >>>>> 20251203-142813.833043 do_rootfs_finalize (280281): >>>>> log.do_rootfs_finalize.280281 >>>>> 20251203-142813.837689 do_transform_template (280287): >>>>> log.do_transform_template.280287 >>>>> 20251203-142835.289802 do_rootfs_quality_check (303158): >>>>> log.do_rootfs_quality_check.303158 >>>>> 20251203-142835.458624 do_rootfs (303179): log.do_rootfs.303179 >>>>> 20251203-142835.545966 do_image_tools (303194): >>>>> log.do_image_tools.303194 >>>>> 20251203-142835.548904 do_rootfs_wicenv (303195): >>>>> log.do_rootfs_wicenv.303195 >>>>> 20251203-142835.635904 do_image_squashfs (303216): >>>>> log.do_image_squashfs.303216 >>>>> 20251203-142853.614060 do_image_verity (305205): >>>>> log.do_image_verity.305205 >>>>> 20251203-142916.978304 do_image_wic (309278): log.do_image_wic.309278 >>>>> 20251203-145901.333675 do_image_wic (953): log.do_image_wic.953 >>>>> >>>>> To ensure that a custom initrd is always build attach the dependency >>>>> to do_image_tools instead. >>>>> >>>>> This fixes a problem with the new IMAGE_INITRD variable in case of >>>>> a multiconfig with two custom initrds. >>>> Can you elaborate on this issue? Is this related with initrd image >>>> not being generated? >>> The initrd was not generated - so we have a dependency issue. I >>> think the main issue is the anonymous python task. >>> >>> Quirin> >> Can you try the patch I just sent? [PATCH] initramfs: Restore default >> "generate-initrd" logic in initramfs.bbclass. I want to know whether >> we have the same issue. > Your patch would also fix the issue. I had some problems as it was not > based on next. > Quirin> I forgot to mention that my patch has dependency on Jan's patches, "rootfs: Fix disabling of initrd generation if there is a custom one" and "rootfs: Restore previous naming scheme in INITRD_DEPLOY_FILE". Zhihang >> Zhihang >>>> Zhihang >>>>> >>>>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >>>>> --- >>>>> meta/classes/image.bbclass | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>>>> index b030024f..b6301e17 100644 >>>>> --- a/meta/classes/image.bbclass >>>>> +++ b/meta/classes/image.bbclass >>>>> @@ -32,7 +32,7 @@ IMAGE_INITRD ?= "" >>>>> INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }- >>>>> ${DISTRO}-${MACHINE}-initrd.img" >>>>> # Make sure dependent initramfs recipe is built >>>>> -do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if >>>>> '${IMAGE_INITRD}' else '' }" >>>>> +do_image_tools[depends] += "${@ '${IMAGE_INITRD}:do_build' if >>>>> '${IMAGE_INITRD}' else '' }" >>>>> # Produce warning(s) if INITRD_IMAGE is used >>>>> python() { >>>> >>> >> >
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index b030024f..b6301e17 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -32,7 +32,7 @@ IMAGE_INITRD ?= "" INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }-${DISTRO}-${MACHINE}-initrd.img" # Make sure dependent initramfs recipe is built -do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if '${IMAGE_INITRD}' else '' }" +do_image_tools[depends] += "${@ '${IMAGE_INITRD}:do_build' if '${IMAGE_INITRD}' else '' }" # Produce warning(s) if INITRD_IMAGE is used python() {