Re: [OE-core] wic builds an empty rootfs on second image build with rm_work enabled

[Mauro Salvini <m.salvini@koansoftware.com>]

On 18/11/24 15:20, Mikko Rapeli via lists.openembedded.org wrote:
> Hi,
> 
> On Tue, Nov 05, 2024 at 03:53:49PM +0000, Richard Purdie wrote:
>> On Mon, 2024-11-04 at 17:10 +0200, Mikko Rapeli via lists.openembedded.org wrote:
>>> Hi,
>>>
>>> After image build completes, rootfs directory is wiped by rm_work_rootfs.
>>>
>>> If the image recipe is built again without clean, for example when
>>> TESTIMAGE_AUTO is enabled to run tests, then rootfs task will not
>>> run and thus wic uses an empty rootfs directory to populate the rootfs which
>>> of course then fails at runtime.
>>>
>>> How to fix this?
>>>
>>> I know RP doesn't like rm_work, but I really need it. I can't leave all
>>> builds laying around and bitbake IPC setup fails if a lot of IO is wiping
>>> build/tpm's while recipe parsing is happening (the famous 30 second timeout).
>>>
>>> wic image related tasks could possible depend on do_rootfs instead of
>>> do_image_complete but seems to break the whole do_image_complete design.
>>>
>>> Should rm_work_rootfs be moved from after do_image_complete to after do_image_wic
>>> if wic images are used?
>>>
>>> Or should users just remember to "bitbake -c clean image && bitbake image" if things
>>> fail?
>>>
>>> There are some other issues with testimage.bbclass and leaking cooker processes
>>> which confused me for a long time but I'll try to send patches for those.
>>
>> Does changing:
>>
>> image_types_wic.bbclass:
>>          bb.build.addtask('do_image_wic', 'do_image_complete', None, d)
>> to
>>          bb.build.addtask('do_image_wic', 'do_image_complete', 'do_rootfs', d)
>>
>> help?
> 
> This did not help. I need to dig deeper. Some of my changes may be
> triggering this. I'm seeing this now on aarch64 and x86_64 build machines.
> 
> Cheers,
> 
> -Mikko
> 

Hi Mikko,

my two cents: do you have the rm_work enabled? I've seen something 
similar in the past, but with initramfs (the generated cpio.gz file 
sometimes was empty). It seemed that adding and then removing a change 
to the image triggered the problem, as if an older but "corrupted" 
sstate has been used.
I've not found the time to dig into that, but I supposed that rm_work 
could be the culprit.

Hope it could help and not add more confusion.

Cheers

-- 
Mauro