| Message ID | 20250616081245.1565935-1-hongxu.jia@windriver.com |
|---|---|
| State | Accepted, archived |
| Commit | 793732a6ac2b3788d6c6635e5a496b117bd60584 |
| Headers | show |
| Series | scripts/wic: fix calling wic ls|cp|rm|write hung in bitbake task | expand |
On 16 Jun 2025, at 09:12, hongxu via lists.openembedded.org <hongxu.jia=eng.windriver.com@lists.openembedded.org> wrote: > > While calling wic ls/cp/rm/write in bitbake task along with do_image_wic, > it hung without return. > > Due to commit [2255f28b57 wic: add WIC_SECTOR_SIZE variable][1] applied, > It calls get_bitbake_var in `wic ls|cp|rm|write' to define sector size. > By default, get_bitbake_var starts a `bitbake -e' to get variables which > triggers nested bitbake in this situation > > Refer `wic create', adds option --vars and --image-name to support to > read bitbake variables from <image>.env files Does anything in core replicate this, or is this only a problem in your custom tasks? The commit message is confusing as this doesn’t fix wic hanging in bitbake tasks, my understanding is that it gives you a way to avoid the deadlock instead. Ross
On 6/19/25 21:30, 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 16 Jun 2025, at 09:12, hongxu via lists.openembedded.org<hongxu.jia=eng.windriver.com@lists.openembedded.org> wrote: >> While calling wic ls/cp/rm/write in bitbake task along with do_image_wic, >> it hung without return. >> >> Due to commit [2255f28b57 wic: add WIC_SECTOR_SIZE variable][1] applied, >> It calls get_bitbake_var in `wic ls|cp|rm|write' to define sector size. >> By default, get_bitbake_var starts a `bitbake -e' to get variables which >> triggers nested bitbake in this situation >> >> Refer `wic create', adds option --vars and --image-name to support to >> read bitbake variables from <image>.env files > Does anything in core replicate this, or is this only a problem in your custom tasks? > > The commit message is confusing as this doesn’t fix wic hanging in bitbake tasks, my understanding is that it gives you a way to avoid the deadlock instead. The hanging was caused by nested bitbake, while calling wic ls/cp/rm/write in bitbake task, and wic ls/cp/rm/write start a `bitbake -e', there are two bitbake actually. The `wic create' use option --vars and --image-name to read bitbake variables from <image>.env files other than start a `bitbake -e' to avoid nested bitbake in this situation, this commit just refer what `wic create' did //Hongxu > Ross
On Fri, 2025-06-20 at 10:46 +0800, hongxu via lists.openembedded.org wrote: > > On 6/19/25 21:30, 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 16 Jun 2025, at 09:12, hongxu via lists.openembedded.org > > <hongxu.jia=eng.windriver.com@lists.openembedded.org> wrote: > > > > > > > > While calling wic ls/cp/rm/write in bitbake task along with > > > do_image_wic, > > > it hung without return. > > > > > > Due to commit [2255f28b57 wic: add WIC_SECTOR_SIZE variable][1] > > > applied, > > > It calls get_bitbake_var in `wic ls|cp|rm|write' to define sector > > > size. > > > By default, get_bitbake_var starts a `bitbake -e' to get > > > variables which > > > triggers nested bitbake in this situation > > > > > > Refer `wic create', adds option --vars and --image-name to > > > support to > > > read bitbake variables from <image>.env files > > > > > > > Does anything in core replicate this, or is this only a problem in > > your custom tasks? > > > > The commit message is confusing as this doesn’t fix wic hanging in > > bitbake tasks, my understanding is that it gives you a way to avoid > > the deadlock instead. > > > > The hanging was caused by nested bitbake, while calling wic > ls/cp/rm/write in bitbake task, > > and wic ls/cp/rm/write start a `bitbake -e', there are two bitbake > actually. > > The `wic create' use option --vars and --image-name to read bitbake > variables from <image>.env files > > other than start a `bitbake -e' to avoid nested bitbake in this > situation, this commit just refer what `wic create' did > I think what Ross is asking/getting at is why aren't we seeing this in our automated tests? What scenario causes the problem to occur since this is the first time we've seen this reported but plenty of people use wic including our tests? Cheers, Richard
diff --git a/scripts/wic b/scripts/wic index 06e0b48db07..9137208f5e8 100755 --- a/scripts/wic +++ b/scripts/wic @@ -237,6 +237,13 @@ def wic_ls_subcommand(args, usage_str): Command-line handling for list content of images. The real work is done by engine.wic_ls() """ + + if args.image_name: + BB_VARS.default_image = args.image_name + + if args.vars_dir: + BB_VARS.vars_dir = args.vars_dir + engine.wic_ls(args, args.native_sysroot) def wic_cp_subcommand(args, usage_str): @@ -244,6 +251,12 @@ def wic_cp_subcommand(args, usage_str): Command-line handling for copying files/dirs to images. The real work is done by engine.wic_cp() """ + if args.image_name: + BB_VARS.default_image = args.image_name + + if args.vars_dir: + BB_VARS.vars_dir = args.vars_dir + engine.wic_cp(args, args.native_sysroot) def wic_rm_subcommand(args, usage_str): @@ -251,6 +264,12 @@ def wic_rm_subcommand(args, usage_str): Command-line handling for removing files/dirs from images. The real work is done by engine.wic_rm() """ + if args.image_name: + BB_VARS.default_image = args.image_name + + if args.vars_dir: + BB_VARS.vars_dir = args.vars_dir + engine.wic_rm(args, args.native_sysroot) def wic_write_subcommand(args, usage_str): @@ -258,6 +277,12 @@ def wic_write_subcommand(args, usage_str): Command-line handling for writing images. The real work is done by engine.wic_write() """ + if args.image_name: + BB_VARS.default_image = args.image_name + + if args.vars_dir: + BB_VARS.vars_dir = args.vars_dir + engine.wic_write(args, args.native_sysroot) def wic_help_subcommand(args, usage_str): @@ -390,6 +415,12 @@ def wic_init_parser_ls(subparser): help="image spec: <image>[:<vfat partition>[<path>]]") subparser.add_argument("-n", "--native-sysroot", help="path to the native sysroot containing the tools") + subparser.add_argument("-e", "--image-name", dest="image_name", + help="name of the image to use the artifacts from " + "e.g. core-image-sato") + subparser.add_argument("-v", "--vars", dest='vars_dir', + help="directory with <image>.env files that store " + "bitbake variables") def imgpathtype(arg): img = imgtype(arg) @@ -404,6 +435,12 @@ def wic_init_parser_cp(subparser): help="image spec: <image>:<vfat partition>[<path>] or <file>") subparser.add_argument("-n", "--native-sysroot", help="path to the native sysroot containing the tools") + subparser.add_argument("-e", "--image-name", dest="image_name", + help="name of the image to use the artifacts from " + "e.g. core-image-sato") + subparser.add_argument("-v", "--vars", dest='vars_dir', + help="directory with <image>.env files that store " + "bitbake variables") def wic_init_parser_rm(subparser): subparser.add_argument("path", type=imgpathtype, @@ -413,6 +450,12 @@ def wic_init_parser_rm(subparser): subparser.add_argument("-r", dest="recursive_delete", action="store_true", default=False, help="remove directories and their contents recursively, " " this only applies to ext* partition") + subparser.add_argument("-e", "--image-name", dest="image_name", + help="name of the image to use the artifacts from " + "e.g. core-image-sato") + subparser.add_argument("-v", "--vars", dest='vars_dir', + help="directory with <image>.env files that store " + "bitbake variables") def expandtype(rules): """ @@ -454,6 +497,12 @@ def wic_init_parser_write(subparser): help="expand rules: auto or <partition>:<size>[,<partition>:<size>]") subparser.add_argument("-n", "--native-sysroot", help="path to the native sysroot containing the tools") + subparser.add_argument("--image-name", dest="image_name", + help="name of the image to use the artifacts from " + "e.g. core-image-sato") + subparser.add_argument("-v", "--vars", dest='vars_dir', + help="directory with <image>.env files that store " + "bitbake variables") def wic_init_parser_help(subparser): helpparsers = subparser.add_subparsers(dest='help_topic', help=hlp.wic_usage)
While calling wic ls/cp/rm/write in bitbake task along with do_image_wic, it hung without return. Due to commit [2255f28b57 wic: add WIC_SECTOR_SIZE variable][1] applied, It calls get_bitbake_var in `wic ls|cp|rm|write' to define sector size. By default, get_bitbake_var starts a `bitbake -e' to get variables which triggers nested bitbake in this situation Refer `wic create', adds option --vars and --image-name to support to read bitbake variables from <image>.env files NOTE: This commit does not add -e for `wic write' to avoid confliction with existed option -e/--expand [1] https://github.com/openembedded/openembedded-core/commit/2255f28b579bc5db4138bcacbb829661ae0ee721 Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> --- scripts/wic | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+)