Bug 10501 - do_image_wic fails with "Error: Couldn't find HDDDIR, exiting"
Summary: do_image_wic fails with "Error: Couldn't find HDDDIR, exiting"
Status: RESOLVED WORKSFORME
Alias: None
Product: Meta-yocto
Classification: Build System, Metadata & Runtime
Component: meta-yocto (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.3 M2
Assignee: Ed Bartosh
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-10-25 23:22 UTC by Paul Gortmaker
Modified: 2016-11-29 15:07 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
local configuration file (11.01 KB, application/octet-stream)
2016-10-27 17:22 UTC, Paul Gortmaker
no flags Details
bitbake layers related to the failure (940 bytes, application/octet-stream)
2016-10-27 17:24 UTC, Paul Gortmaker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Gortmaker 2016-10-25 23:22:52 UTC
Recently my rather generic x86 builds started failing with:

Error: Couldn't find HDDDIR, exiting
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_image_wic (log file is located at /home/paul/poky/build/tmp/work/genericx86_64-overc-linux/cube-essential/0.1-r0/temp/log.do_image_wic.6557)

These builds aren't requiring wic/EFI, just tarball, but after:

1fe840a4a0fbb (Ed Bartosh          2016-09-20 12:15:59 +0300 23) IMAGE_FSTYPES += "wic"

in meta-yocto-bsp/conf/machine/include/genericx86-common.inc we now get it unconditionally.

Workaround:  add

IMAGE_FSTYPES_remove = "wic"

to your local.conf
Comment 1 Ed Bartosh 2016-10-27 05:56:08 UTC
Can you provide more details about your build, please? what's you're MACHINE, which layers are used, etc.
Comment 2 Ed Bartosh 2016-10-27 14:59:58 UTC
set status to needinfo. Please, reassign it back to me after providing requested information.
Comment 3 Paul Gortmaker 2016-10-27 17:22:12 UTC
Created attachment 3505 [details]
local configuration file

Local configuration file, indicating MACHINE and other settings.
Comment 4 Paul Gortmaker 2016-10-27 17:24:00 UTC
Created attachment 3506 [details]
bitbake layers related to the failure

Layers in use at the time of the WIC fail ; all are public layers available to anyone.
Comment 5 Paul Gortmaker 2016-10-27 17:25:40 UTC
reassigning as requested after adding configuration details.
Comment 6 Paul Gortmaker 2016-10-27 21:24:36 UTC
Oh, and image target is:

    bitbake cube-graphical-builder
Comment 7 Ed Bartosh 2016-10-31 10:37:24 UTC
Paul, thank you for providing information about your build.

I was able to reproduce the build and the issue.

The reason for it is that wic images are now produced by default for genericx86 and genericx86-64 machines, but image configuration is changed in the layers used for your build. In particular hddimg is produced by genericx85* default configuration, but it's disabled in some of the layers you're using. hddimg is used to produce wic images and it fails as hddimg is not enabled.

There are two ways to fix it. If you want to produce partitioned images ready to be flashed and booted on your hardware we can try to fix this by enabling hddimg and producing wic images for your builds.
If you don't want that you can disable producing of wic images by removing them from IMAGE_FSTYPES variable in one of your layers. 

Which way would you prefer?
Comment 8 Paul Gortmaker 2016-11-01 18:13:03 UTC
I personally have no use for WIC images and hence have no problem with folks revisiting the "everywhere by default" decision, but I also don't claim to represent a giant user base, and don't have the context of why the enabled by default decision was originally made.
Comment 9 Ed Bartosh 2016-11-02 10:35:46 UTC
Paul, you can find more info regarding enabling wic images for all reference BSPs in the bug 8719
Comment 10 Ed Bartosh 2016-11-29 15:07:02 UTC
Resolving as worksforme. So far the working solution is to disable building of wic images if you don't need them.

Feel free to reopen this bug if you think it's not enough.