Re: [OE-core][PATCH] wic/engine: warn about old host debugfs for standalone directory copy

[Daniel Dragomir <daniel.dragomir@windriver.com>]

On 2/9/26 20:12, Ross Burton wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> On 18 Dec 2025, at 13:48, Daniel Dragomir <daniel.dragomir@windriver.com> wrote:
>>
>>
>>
>> On 12/18/25 13:46, Paul Barker wrote:
>>> On Thu, 2025-12-18 at 11:34 +0000, Paul Barker wrote:
>>>> On Thu, 2025-12-18 at 12:15 +0200, Dragomir, Daniel via
>>>> lists.openembedded.org wrote:
>>>>> When wic is used in standalone mode, it relies on host tools such as
>>>>> debugfs. For directory host->image copies into ext* partitions, wic
>>>>> uses scripted debugfs "-f" input with multiple mkdir/write commands.
>>>>>
>>>>> Older host debugfs versions (< 1.47) may behave unreliably in this
>>>>> mode and can silently miss files. This does not affect builds using
>>>>> debugfs from OE where the version is known to be sufficiently new.
>>>>>
>>>>> Add a debugfs version check and emit a warning when an older host
>>>>> debugfs is detected. The warning is shown once per run and does not
>>>>> alter execution.
>>>>
>>>> If the risk here is silently missing files, resulting in a corrupted
>>>> rootfs or worse, I think this should be a hard error.
>>>>
>>>> Consider the case where someone relies on a device having a firewall
>>>> enabled, but /etc/nftables.conf is silently missed during construction
>>>> of the rootfs ext4 image. That could result in all ports being open.
>>
>> This failure can only occur when copying directories into an already
>> created WIC image with an ext* partition. It does not affect image or
>> rootfs construction.
>>
>> My understanding is that `wic cp` is a post-creation image manipulation
>> tool and is not used during rootfs generation or WIC image creation.
>> It is intended solely for modifying an existing WIC image without
>> mounting it.
> 
> Which can be done by people in production, so I agree with Paul: this should be a fatal error, not a warning.
> 
> Ross

Understood. I'll send a new version of the patch with error instead warning.

Daniel