.. SPDX-License-Identifier: CC-BY-SA-2.0-UK Creating Partitioned Images Using Wic ************************************* Creating an image for a particular hardware target using the OpenEmbedded build system does not necessarily mean you can boot that image as is on your device. Physical devices accept and boot images in various ways depending on the specifics of the device. Usually, information about the hardware can tell you what image format the device requires. Should your device require multiple partitions on an SD card, flash, or an HDD, you can use the OpenEmbedded Image Creator, Wic, to create the properly partitioned image. The ``wic`` command generates partitioned images from existing OpenEmbedded build artifacts. Image generation is driven by partitioning commands contained in an OpenEmbedded kickstart file (``.wks``) specified either directly on the command line or as one of a selection of canned kickstart files as shown with the ``wic list images`` command in the ":ref:`dev-manual/wic:generate an image using an existing kickstart file`" section. When you apply the command to a given set of build artifacts, the result is an image or set of images that can be directly written onto media and used on a particular system. .. note:: For a kickstart file reference, see the ":ref:`ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference`" Chapter in the Yocto Project Reference Manual. The ``wic`` command and the infrastructure it is based on is by definition incomplete. The purpose of the command is to allow the generation of customized images, and as such, was designed to be completely extensible through a plugin interface. See the ":ref:`dev-manual/wic:using the wic plugin interface`" section for information on these plugins. This section provides some background information on Wic, describes what you need to have in place to run the tool, provides instruction on how to use the Wic utility, provides information on using the Wic plugins interface, and provides several examples that show how to use Wic. Background ========== This section provides some background on the Wic utility. While none of this information is required to use Wic, you might find it interesting. - The name "Wic" is derived from OpenEmbedded Image Creator (oeic). The "oe" diphthong in "oeic" was promoted to the letter "w", because "oeic" is both difficult to remember and to pronounce. - Wic is loosely based on the Meego Image Creator (``mic``) framework. The Wic implementation has been heavily modified to make direct use of OpenEmbedded build artifacts instead of package installation and configuration, which are already incorporated within the OpenEmbedded artifacts. - Wic is a completely independent standalone utility that initially provides easier-to-use and more flexible replacements for an existing functionality in OE-Core's :ref:`image-live ` class. The difference between Wic and those examples is that with Wic the functionality of those scripts is implemented by a general-purpose partitioning language, which is based on Redhat kickstart syntax. Requirements ============ In order to use the Wic utility with the OpenEmbedded Build system, your system needs to meet the following requirements: - The Linux distribution on your development host must support the Yocto Project. See the ":ref:`detailed-supported-distros`" section in the Yocto Project Reference Manual for the list of distributions that support the Yocto Project. - The standard system utilities, such as ``cp``, must be installed on your development host system. - You must have sourced the build environment setup script (i.e. :ref:`structure-core-script`) found in the :term:`Build Directory`. - You need to have the build artifacts already available, which typically means that you must have already created an image using the OpenEmbedded build system (e.g. ``core-image-minimal``). While it might seem redundant to generate an image in order to create an image using Wic, the current version of Wic requires the artifacts in the form generated by the OpenEmbedded build system. - You must build several native tools, which are built to run on the build system:: $ bitbake parted-native dosfstools-native mtools-native - Include "wic" as part of the :term:`IMAGE_FSTYPES` variable. - Include the name of the :ref:`wic kickstart file ` as part of the :term:`WKS_FILE` variable. If multiple candidate files can be provided by different layers, specify all the possible names through the :term:`WKS_FILES` variable instead. Getting Help ============ You can get general help for the ``wic`` command by entering the ``wic`` command by itself or by entering the command with a help argument as follows:: $ wic -h $ wic --help $ wic help Currently, Wic supports seven commands: ``cp``, ``create``, ``help``, ``list``, ``ls``, ``rm``, and ``write``. You can get help for all these commands except "help" by using the following form:: $ wic help command For example, the following command returns help for the ``write`` command:: $ wic help write Wic supports help for three topics: ``overview``, ``plugins``, and ``kickstart``. You can get help for any topic using the following form:: $ wic help topic For example, the following returns overview help for Wic:: $ wic help overview There is one additional level of help for Wic. You can get help on individual images through the ``list`` command. You can use the ``list`` command to return the available Wic images as follows:: $ wic list images genericx86 Create an EFI disk image for genericx86* edgerouter Create SD card image for Edgerouter beaglebone-yocto Create SD card image for Beaglebone qemux86-directdisk Create a qemu machine 'pcbios' direct disk image systemd-bootdisk Create an EFI disk image with systemd-boot mkhybridiso Create a hybrid ISO image mkefidisk Create an EFI disk image sdimage-bootpart Create SD card image with a boot partition directdisk-multi-rootfs Create multi rootfs image using rootfs plugin directdisk Create a 'pcbios' direct disk image directdisk-bootloader-config Create a 'pcbios' direct disk image with custom bootloader config qemuriscv Create qcow2 image for RISC-V QEMU machines directdisk-gpt Create a 'pcbios' direct disk image efi-bootdisk Once you know the list of available Wic images, you can use ``help`` with the command to get help on a particular image. For example, the following command returns help on the "beaglebone-yocto" image:: $ wic list beaglebone-yocto help Creates a partitioned SD card image for Beaglebone. Boot files are located in the first vfat partition. Operational Modes ================= You can use Wic in two different modes, depending on how much control you need for specifying the OpenEmbedded build artifacts that are used for creating the image: Raw and Cooked: - *Raw Mode:* You explicitly specify build artifacts through Wic command-line arguments. - *Cooked Mode:* The current :term:`MACHINE` setting and image name are used to automatically locate and provide the build artifacts. You just supply a kickstart file and the name of the image from which to use artifacts. Regardless of the mode you use, you need to have the build artifacts ready and available. Raw Mode -------- Running Wic in raw mode allows you to specify all the partitions through the ``wic`` command line. The primary use for raw mode is if you have built your kernel outside of the Yocto Project :term:`Build Directory`. In other words, you can point to arbitrary kernel, root filesystem locations, and so forth. Contrast this behavior with cooked mode where Wic looks in the :term:`Build Directory` (e.g. ``tmp/deploy/images/``\ machine). The general form of the ``wic`` command in raw mode is:: $ wic create wks_file options ... Where: wks_file: An OpenEmbedded kickstart file. You can provide your own custom file or use a file from a set of existing files as described by further options. optional arguments: -h, --help show this help message and exit -o OUTDIR, --outdir OUTDIR name of directory to create image in -e IMAGE_NAME, --image-name IMAGE_NAME name of the image to use the artifacts from e.g. core- image-sato -r ROOTFS_DIR, --rootfs-dir ROOTFS_DIR path to the /rootfs dir to use as the .wks rootfs source -b BOOTIMG_DIR, --bootimg-dir BOOTIMG_DIR path to the dir containing the boot artifacts (e.g. /EFI or /syslinux dirs) to use as the .wks bootimg source -k KERNEL_DIR, --kernel-dir KERNEL_DIR path to the dir containing the kernel to use in the .wks bootimg -n NATIVE_SYSROOT, --native-sysroot NATIVE_SYSROOT path to the native sysroot containing the tools to use to build the image -s, --skip-build-check skip the build check -f, --build-rootfs build rootfs -c {gzip,bzip2,xz}, --compress-with {gzip,bzip2,xz} compress image with specified compressor -m, --bmap generate .bmap --no-fstab-update Do not change fstab file. -v VARS_DIR, --vars VARS_DIR directory with .env files that store bitbake variables -D, --debug output debug information .. note:: You do not need root privileges to run Wic. In fact, you should not run as root when using the utility. Cooked Mode ----------- Running Wic in cooked mode leverages off artifacts in the :term:`Build Directory`. In other words, you do not have to specify kernel or root filesystem locations as part of the command. All you need to provide is a kickstart file and the name of the image from which to use artifacts by using the "-e" option. Wic looks in the :term:`Build Directory` (e.g. ``tmp/deploy/images/``\ machine) for artifacts. The general form of the ``wic`` command using Cooked Mode is as follows:: $ wic create wks_file -e IMAGE_NAME Where: wks_file: An OpenEmbedded kickstart file. You can provide your own custom file or use a file from a set of existing files provided with the Yocto Project release. required argument: -e IMAGE_NAME, --image-name IMAGE_NAME name of the image to use the artifacts from e.g. core- image-sato Using an Existing Kickstart File ================================ If you do not want to create your own kickstart file, you can use an existing file provided by the Wic installation. As shipped, kickstart files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the following two locations:: poky/meta-yocto-bsp/wic poky/scripts/lib/wic/canned-wks Use the following command to list the available kickstart files:: $ wic list images genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter qemux86-directdisk Create a QEMU machine 'pcbios' direct disk image directdisk-gpt Create a 'pcbios' direct disk image mkefidisk Create an EFI disk image directdisk Create a 'pcbios' direct disk image systemd-bootdisk Create an EFI disk image with systemd-boot mkhybridiso Create a hybrid ISO image sdimage-bootpart Create SD card image with a boot partition directdisk-multi-rootfs Create multi rootfs image using rootfs plugin directdisk-bootloader-config Create a 'pcbios' direct disk image with custom bootloader config When you use an existing file, you do not have to use the ``.wks`` extension. Here is an example in Raw Mode that uses the ``directdisk`` file:: $ wic create directdisk -r rootfs_dir -b bootimg_dir \ -k kernel_dir -n native_sysroot Here are the actual partition language commands used in the ``genericx86.wks`` file to generate an image:: # short-description: Create an EFI disk image for genericx86* # long-description: Creates a partitioned EFI disk image for genericx86* machines part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label msdos --active --align 1024 part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 --use-uuid part swap --ondisk sda --size 44 --label swap1 --fstype=swap bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0" Using the Wic Plugin Interface ============================== You can extend and specialize Wic functionality by using Wic plugins. This section explains the Wic plugin interface. .. note:: Wic plugins consist of "source" and "imager" plugins. Imager plugins are beyond the scope of this section. Source plugins provide a mechanism to customize partition content during the Wic image generation process. You can use source plugins to map values that you specify using ``--source`` commands in kickstart files (i.e. ``*.wks``) to a plugin implementation used to populate a given partition. .. note:: If you use plugins that have build-time dependencies (e.g. native tools, bootloaders, and so forth) when building a Wic image, you need to specify those dependencies using the :term:`WKS_FILE_DEPENDS` variable. Source plugins are subclasses defined in plugin files. As shipped, the Yocto Project provides several plugin files. You can see the source plugin files that ship with the Yocto Project :yocto_git:`here `. Each of these plugin files contains source plugins that are designed to populate a specific Wic image partition. Source plugins are subclasses of the ``SourcePlugin`` class, which is defined in the ``poky/scripts/lib/wic/pluginbase.py`` file. For example, the ``BootimgEFIPlugin`` source plugin found in the ``bootimg-efi.py`` file is a subclass of the ``SourcePlugin`` class, which is found in the ``pluginbase.py`` file. You can also implement source plugins in a layer outside of the Source Repositories (external layer). To do so, be sure that your plugin files are located in a directory whose path is ``scripts/lib/wic/plugins/source/`` within your external layer. When the plugin files are located there, the source plugins they contain are made available to Wic. When the Wic implementation needs to invoke a partition-specific implementation, it looks for the plugin with the same name as the ``--source`` parameter used in the kickstart file given to that partition. For example, if the partition is set up using the following command in a kickstart file:: part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024 The methods defined as class members of the matching source plugin (i.e. ``bootimg-pcbios``) in the ``bootimg-pcbios.py`` plugin file are used. To be more concrete, here is the corresponding plugin definition from the ``bootimg-pcbios.py`` file for the previous command along with an example method called by the Wic implementation when it needs to prepare a partition using an implementation-specific function:: . . . class BootimgPcbiosPlugin(SourcePlugin): """ Create MBR boot partition and install syslinux on it. """ name = 'bootimg-pcbios' . . . @classmethod def do_prepare_partition(cls, part, source_params, creator, cr_workdir, oe_builddir, bootimg_dir, kernel_dir, rootfs_dir, native_sysroot): """ Called to do the actual content population for a partition i.e. it 'prepares' the partition to be incorporated into the image. In this case, prepare content for legacy bios boot partition. """ . . . If a subclass (plugin) itself does not implement a particular function, Wic locates and uses the default version in the superclass. It is for this reason that all source plugins are derived from the ``SourcePlugin`` class. The ``SourcePlugin`` class defined in the ``pluginbase.py`` file defines a set of methods that source plugins can implement or override. Any plugins (subclass of ``SourcePlugin``) that do not implement a particular method inherit the implementation of the method from the ``SourcePlugin`` class. For more information, see the ``SourcePlugin`` class in the ``pluginbase.py`` file for details: The following list describes the methods implemented in the ``SourcePlugin`` class: - ``do_prepare_partition()``: Called to populate a partition with actual content. In other words, the method prepares the final partition image that is incorporated into the disk image. - ``do_configure_partition()``: Called before ``do_prepare_partition()`` to create custom configuration files for a partition (e.g. syslinux or grub configuration files). - ``do_install_disk()``: Called after all partitions have been prepared and assembled into a disk image. This method provides a hook to allow finalization of a disk image (e.g. writing an MBR). - ``do_stage_partition()``: Special content-staging hook called before ``do_prepare_partition()``. This method is normally empty. Typically, a partition just uses the passed-in parameters (e.g. the unmodified value of ``bootimg_dir``). However, in some cases, things might need to be more tailored. As an example, certain files might additionally need to be taken from ``bootimg_dir + /boot``. This hook allows those files to be staged in a customized fashion. .. note:: ``get_bitbake_var()`` allows you to access non-standard variables that you might want to use for this behavior. You can extend the source plugin mechanism. To add more hooks, create more source plugin methods within ``SourcePlugin`` and the corresponding derived subclasses. The code that calls the plugin methods uses the ``plugin.get_source_plugin_methods()`` function to find the method or methods needed by the call. Retrieval of those methods is accomplished by filling up a dict with keys that contain the method names of interest. On success, these will be filled in with the actual methods. See the Wic implementation for examples and details. Wic Examples ============ This section provides several examples that show how to use the Wic utility. All the examples assume the list of requirements in the ":ref:`dev-manual/wic:requirements`" section have been met. The examples assume the previously generated image is ``core-image-minimal``. Generate an Image using an Existing Kickstart File -------------------------------------------------- This example runs in Cooked Mode and uses the ``mkefidisk`` kickstart file:: $ wic create mkefidisk -e core-image-minimal INFO: Building wic-tools... . . . INFO: The new image(s) can be found here: ./mkefidisk-201804191017-sda.direct The following build artifacts were used to create the image(s): ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: The image(s) were created using OE kickstart file: /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks The previous example shows the easiest way to create an image by running in cooked mode and supplying a kickstart file and the "-e" option to point to the existing build artifacts. Your ``local.conf`` file needs to have the :term:`MACHINE` variable set to the machine you are using, which is "qemux86" in this example. Once the image builds, the output provides image location, artifact use, and kickstart file information. .. note:: You should always verify the details provided in the output to make sure that the image was indeed created exactly as expected. Continuing with the example, you can now write the image from the :term:`Build Directory` onto a USB stick, or whatever media for which you built your image, and boot from the media. You can write the image by using ``bmaptool`` or ``dd``:: $ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX or :: $ sudo dd if=mkefidisk-201804191017-sda.direct of=/dev/sdX .. note:: For more information on how to use the ``bmaptool`` to flash a device with an image, see the ":ref:`dev-manual/bmaptool:flashing images using \`\`bmaptool\`\``" section. Using a Modified Kickstart File ------------------------------- Because partitioned image creation is driven by the kickstart file, it is easy to affect image creation by changing the parameters in the file. This next example demonstrates that through modification of the ``directdisk-gpt`` kickstart file. As mentioned earlier, you can use the command ``wic list images`` to show the list of existing kickstart files. The directory in which the ``directdisk-gpt.wks`` file resides is ``scripts/lib/image/canned-wks/``, which is located in the :term:`Source Directory` (e.g. ``poky``). Because available files reside in this directory, you can create and add your own custom files to the directory. Subsequent use of the ``wic list images`` command would then include your kickstart files. In this example, the existing ``directdisk-gpt`` file already does most of what is needed. However, for the hardware in this example, the image will need to boot from ``sdb`` instead of ``sda``, which is what the ``directdisk-gpt`` kickstart file uses. The example begins by making a copy of the ``directdisk-gpt.wks`` file in the ``scripts/lib/image/canned-wks`` directory and then by changing the lines that specify the target disk from which to boot:: $ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \ /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks Next, the example modifies the ``directdisksdb-gpt.wks`` file and changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The example changes the following two lines and leaves the remaining lines untouched:: part /boot --source bootimg-pcbios --ondisk sdb --label boot --active --align 1024 part / --source rootfs --ondisk sdb --fstype=ext4 --label platform --align 1024 --use-uuid Once the lines are changed, the example generates the ``directdisksdb-gpt`` image. The command points the process at the ``core-image-minimal`` artifacts for the Next Unit of Computing (nuc) :term:`MACHINE` the ``local.conf``:: $ wic create directdisksdb-gpt -e core-image-minimal INFO: Building wic-tools... . . . Initialising tasks: 100% |#######################################| Time: 0:00:01 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 1161 tasks of which 1157 didn't need to be rerun and all succeeded. INFO: Creating image(s)... INFO: The new image(s) can be found here: ./directdisksdb-gpt-201710090938-sdb.direct The following build artifacts were used to create the image(s): ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: The image(s) were created using OE kickstart file: /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks Continuing with the example, you can now directly ``dd`` the image to a USB stick, or whatever media for which you built your image, and boot the resulting media:: $ sudo dd if=directdisksdb-gpt-201710090938-sdb.direct of=/dev/sdb 140966+0 records in 140966+0 records out 72174592 bytes (72 MB, 69 MiB) copied, 78.0282 s, 925 kB/s $ sudo eject /dev/sdb Using a Modified Kickstart File and Running in Raw Mode ------------------------------------------------------- This next example manually specifies each build artifact (runs in Raw Mode) and uses a modified kickstart file. The example also uses the ``-o`` option to cause Wic to create the output somewhere other than the default output directory, which is the current directory:: $ wic create test.wks -o /home/stephano/testwic \ --rootfs-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \ --bootimg-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \ --kernel-dir /home/stephano/yocto/build/tmp/deploy/images/qemux86 \ --native-sysroot /home/stephano/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: Creating image(s)... INFO: The new image(s) can be found here: /home/stephano/testwic/test-201710091445-sdb.direct The following build artifacts were used to create the image(s): ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: The image(s) were created using OE kickstart file: test.wks For this example, :term:`MACHINE` did not have to be specified in the ``local.conf`` file since the artifact is manually specified. Using Wic to Manipulate an Image -------------------------------- Wic image manipulation allows you to shorten turnaround time during image development. For example, you can use Wic to delete the kernel partition of a Wic image and then insert a newly built kernel. This saves you time from having to rebuild the entire image each time you modify the kernel. .. note:: In order to use Wic to manipulate a Wic image as in this example, your development machine must have the ``mtools`` package installed. The following example examines the contents of the Wic image, deletes the existing kernel, and then inserts a new kernel: 1. *List the Partitions:* Use the ``wic ls`` command to list all the partitions in the Wic image:: $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic Num Start End Size Fstype 1 1048576 25041919 23993344 fat16 2 25165824 72157183 46991360 ext4 The previous output shows two partitions in the ``core-image-minimal-qemux86.wic`` image. 2. *Examine a Particular Partition:* Use the ``wic ls`` command again but in a different form to examine a particular partition. .. note:: You can get command usage on any Wic command using the following form:: $ wic help command For example, the following command shows you the various ways to use the wic ls command:: $ wic help ls The following command shows what is in partition one:: $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1 Volume in drive : is boot Volume Serial Number is E894-1809 Directory for ::/ libcom32 c32 186500 2017-10-09 16:06 libutil c32 24148 2017-10-09 16:06 syslinux cfg 220 2017-10-09 16:06 vesamenu c32 27104 2017-10-09 16:06 vmlinuz 6904608 2017-10-09 16:06 5 files 7 142 580 bytes 16 582 656 bytes free The previous output shows five files, with the ``vmlinuz`` being the kernel. .. note:: If you see the following error, you need to update or create a ``~/.mtoolsrc`` file and be sure to have the line "mtools_skip_check=1" in the file. Then, run the Wic command again:: ERROR: _exec_cmd: /usr/bin/mdir -i /tmp/wic-parttfokuwra ::/ returned '1' instead of 0 output: Total number of sectors (47824) not a multiple of sectors per track (32)! Add mtools_skip_check=1 to your .mtoolsrc file to skip this test 3. *Remove the Old Kernel:* Use the ``wic rm`` command to remove the ``vmlinuz`` file (kernel):: $ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz 4. *Add In the New Kernel:* Use the ``wic cp`` command to add the updated kernel to the Wic image. Depending on how you built your kernel, it could be in different places. If you used ``devtool`` and an SDK to build your kernel, it resides in the ``tmp/work`` directory of the extensible SDK. If you used ``make`` to build the kernel, the kernel will be in the ``workspace/sources`` area. The following example assumes ``devtool`` was used to build the kernel:: $ wic cp poky_sdk/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+git999-r0/linux-yocto-4.12.12+git999/arch/x86/boot/bzImage \ poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz Once the new kernel is added back into the image, you can use the ``dd`` command or :ref:`bmaptool ` to flash your wic image onto an SD card or USB stick and test your target. .. note:: Using ``bmaptool`` is generally 10 to 20 times faster than using ``dd``.