public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Daniel Dragomir <daniel.dragomir@windriver.com>
To: Paul Barker <paul@pbarker.dev>, openembedded-core@lists.openembedded.org
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Ross Burton <Ross.Burton@arm.com>
Subject: Re: [OE-core][PATCH] wic/engine: warn about old host debugfs for standalone directory copy
Date: Thu, 18 Dec 2025 15:48:39 +0200	[thread overview]
Message-ID: <bce56a9a-88a2-4642-a42a-9ece138fb8ea@windriver.com> (raw)
In-Reply-To: <a77d83f822d4431d08307570482ebd024bcc5238.camel@pbarker.dev>



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.

>>
>> On the kirkstone branch we have e2fsprogs 1.46.5, does the same debugfs
>> issue apply there or has it been patched?

I built a kirkstone SDK and tested this again: debugfs 1.46.5 works 
fine, and all ~1500 files were copied successfully. This issue appears 
to affect only version 1.45.

I can send a v2 of the patch to adjust the minimum required version.

> 
> Also, do you have any links to upstream bug reports or the commit(s)
> that fixed this? I can't find anything relevant in the recent e2fsprogs
> release notes.

No, I have not investigated so far why older versions of scripted 
debugfs (-f) fail to copy complex directory structures.

Adding a warning was discussed in this thread for a patch I sent to fix
copying directories into a WIC image with an ext* partition. I also 
explained how I discovered this behavior on different servers while 
testing the fix.

I only tested standalone usage of wic, using host tools from e2fsprogs.

https://lists.openembedded.org/g/openembedded-core/topic/115585333#msg228042

Regards,
Daniel

> 
> Best regards,
> 


  reply	other threads:[~2025-12-18 13:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 10:15 [OE-core][PATCH] wic/engine: warn about old host debugfs for standalone directory copy Daniel Dragomir
2025-12-18 11:34 ` Paul Barker
2025-12-18 11:46   ` Paul Barker
2025-12-18 13:48     ` Daniel Dragomir [this message]
2026-02-09 18:12       ` Ross Burton
2026-02-10 13:02         ` Daniel Dragomir
2026-01-09 17:45 ` [OE-core][PATCH v2] " Daniel Dragomir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bce56a9a-88a2-4642-a42a-9ece138fb8ea@windriver.com \
    --to=daniel.dragomir@windriver.com \
    --cc=Ross.Burton@arm.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@pbarker.dev \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox