All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dragomir, Daniel" <daniel.dragomir@windriver.com>
To: Ross Burton <Ross.Burton@arm.com>
Cc: "openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>,
	Kexin.Hao@windriver.com, mathieu.dubois-briand@bootlin.com
Subject: Re: [OE-core][PATCH] wic/engine: fix copying directories into wic image with ext* partition
Date: Wed, 17 Dec 2025 15:15:47 +0200	[thread overview]
Message-ID: <4067abbf-57bf-43de-ab80-df09e509f39b@windriver.com> (raw)
In-Reply-To: <D8277C29-A859-491A-85B8-C518E37EB988@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

Sorry for the late response... I’m working this week on a selftest for 
the case fixed by this patch.

Meanwhile, I was focused on another aspect related to this patch. Our 
client reported different behavior when copying complex directory 
structures onto a WIC image using different servers.

It appears that the issue is related to the debugfs version 
(e2fsprogs package).
On Ubuntu 24.04 with e2fsprogs 4.17, all files are copied correctly, 
while on Ubuntu 20.04 with e2fsprogs 1.45, the copy operation fails to 
copy all files and does not create all directories. This failure is 
silent, with no error reported by debugfs.

I tried several approaches to solve this (splitting the command list in 
max 100 instances and calling debugfs 1.45 multiple times), but without 
success.
For our client, we decided to add a debugfs version check in wic code 
and to add a warning if the version is < 1.47.
On those specific servers, they will use wic with the 
-n/--native-sysroot option, pointing to a scarthgap SDK that contains 
1.47 version of the e2fsprogs package.

How should we handle this exception? This was fixed in newer debugfs 
version, but should we add a debugfs version warning when broken version 
of debugfs is used on host?

Regards,
Daniel
------------------------------------------------------------------------
*From:* Ross Burton <Ross.Burton@arm.com>
*Sent:* Monday, October 6, 2025 11:08 PM
*To:* Dragomir, Daniel <Daniel.Dragomir@windriver.com>
*Cc:* openembedded-core@lists.openembedded.org 
<openembedded-core@lists.openembedded.org>
*Subject:* Re: [OE-core][PATCH] wic/engine: fix copying directories into 
wic image with ext* partition
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 3 Oct 2025, at 21:31, Dragomir, Daniel via lists.openembedded.org 
<daniel.dragomir=windriver.com@lists.openembedded.org> wrote:
 >
 > wic uses debugfs to write on ext* partitions, but debugfs can only
 > write to the current working directory and it cannot copy complete
 > directory trees. Running 'wic ls' on a copied directory show this:
 >    -l: Ext2 inode is not a directory
 >
 > Fix this by creating a command list for debugfs (-f parameter) when
 > recursive parsing the host directory in order to create a similar
 > directory structure (mkdir) and copy files (write) on each level
 > into the destination directory from the wic's ext* partition.

This is great, but could you please add a test case to the wic selftests 
to exercise this and ensure it doesn’t break in the future?

Thanks,
Ross

[-- Attachment #2: Type: text/html, Size: 7693 bytes --]

  parent reply	other threads:[~2025-12-17 13:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03 20:31 [OE-core][PATCH] wic/engine: fix copying directories into wic image with ext* partition Dragomir, Daniel
2025-10-06 20:08 ` Ross Burton
2025-12-11 10:07   ` Richard Purdie
2025-12-17 13:15   ` Dragomir, Daniel [this message]
2025-12-17 14:48     ` Richard Purdie

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=4067abbf-57bf-43de-ab80-df09e509f39b@windriver.com \
    --to=daniel.dragomir@windriver.com \
    --cc=Kexin.Hao@windriver.com \
    --cc=Ross.Burton@arm.com \
    --cc=mathieu.dubois-briand@bootlin.com \
    --cc=openembedded-core@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.