diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 9030b96264..ba74e15d1a 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -741,13 +741,13 @@ ... DESCRIPTION = "A useful utility" ... - EXTRA_OECONF = "--enable-something" + EXTRA_OECONF = "‐‐enable-something" ... #### bbappended from meta-anotherlayer #### DESCRIPTION = "Customized utility" - EXTRA_OECONF += "--enable-somethingelse" + EXTRA_OECONF += "‐‐enable-somethingelse" Ideally, you would tidy up these utilities as follows: @@ -755,7 +755,7 @@ ... DESCRIPTION = "Customized utility" ... - EXTRA_OECONF = "--enable-something --enable-somethingelse" + EXTRA_OECONF = "‐‐enable-something ‐‐enable-somethingelse" ... @@ -1170,6 +1170,61 @@ For other forms of image dependencies see the other areas of this section. + +
+ Customizing an Image Hostname + + + By default the configured hostname (i.e. + /etc/hostname) in an image is the + same as the machine name. + For example, if + MACHINE + equals "qemux86", the configured hostname written to + /etc/hostname is "qemux86". + + + + You can customize this name by altering the value of the + "hostname" variable in the base-files recipe using either + an append file or a configuration file. + + Setting the variable to "" causes no hostname to be + written to /etc/hostname. + + Use the following in an append file: + + hostname="myhostname" + + Use the following in a configuration file: + + hostname_pn-base-files = "myhostname" + + + + + Changing the default value of the variable "hostname" can be + useful in certain situations. + For example, suppose you need to do extensive testing on an + image and you would like to easily identify the image + under test from existing images with typical default + hostnames. + In this situation, you could change the default hostname to + "testme", which results in all the images using the name + "testme". + Once testing is complete and you do not need to rebuild the + image for test any longer, you can easily reset the default + hostname. + + + + Another point of interest is that if you leave the variable + "hostname" unset, the image will have no default hostname + in the filesystem. + This condition is suitable for environments that use + dynamic hostnames such as virtual machines. + +
@@ -2275,7 +2330,7 @@ configure script with the appropriate options. For the case involving a custom configure script, you would run - ./configure --help and look for + ./configure ‐‐help and look for the options you need to set. @@ -2298,7 +2353,7 @@ configure script as needed. For reference information on configure options specific to the software you are building, you can consult the output of the - ./configure --help command within + ./configure ‐‐help command within ${S} or consult the software's upstream documentation. @@ -3780,7 +3835,7 @@ or by entering the command with a help argument as follows: $ wic -h - $ wic --help + $ wic ‐‐help @@ -3796,7 +3851,7 @@ You can also get detailed help on a number of topics from the help system. - The output of wic --help + The output of wic ‐‐help displays a list of available help topics under a "Help topics" heading. You can have the help system display the help text for @@ -3866,38 +3921,38 @@ your own custom file or use a file from a set of existing files as described by further options. - -o OUTDIR, --outdir=OUTDIR + -o OUTDIR, ‐‐outdir=OUTDIR The name of a directory in which to create image. - -i PROPERTIES_FILE, --infile=PROPERTIES_FILE + -i PROPERTIES_FILE, ‐‐infile=PROPERTIES_FILE The name of a file containing the values for image properties as a JSON file. - -e IMAGE_NAME, --image-name=IMAGE_NAME + -e IMAGE_NAME, ‐‐image-name=IMAGE_NAME The name of the image from which to use the artifacts (e.g. core-image-sato). - -r ROOTFS_DIR, --rootfs-dir=ROOTFS_DIR + -r ROOTFS_DIR, ‐‐rootfs-dir=ROOTFS_DIR The path to the /rootfs directory to use as the .wks rootfs source. - -b BOOTIMG_DIR, --bootimg-dir=BOOTIMG_DIR + -b BOOTIMG_DIR, ‐‐bootimg-dir=BOOTIMG_DIR The path to the directory containing the boot artifacts (e.g. /EFI or /syslinux) to use as the .wks bootimg source. - -k KERNEL_DIR, --kernel-dir=KERNEL_DIR + -k KERNEL_DIR, ‐‐kernel-dir=KERNEL_DIR The path to the directory containing the kernel to use in the .wks boot image. - -n NATIVE_SYSROOT, --native-sysroot=NATIVE_SYSROOT + -n NATIVE_SYSROOT, ‐‐native-sysroot=NATIVE_SYSROOT The path to the native sysroot containing the tools to use to build the image. - -s, --skip-build-check + -s, ‐‐skip-build-check Skips the build check. - -D, --debug + -D, ‐‐debug Output debug information. @@ -4107,13 +4162,13 @@ Next, the example modifies the directdisksdb.wks file and changes all - instances of "--ondisk sda" - to "--ondisk sdb". + 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=ext3 --label platform --align 1024 + part /boot ‐‐source bootimg-pcbios ‐‐ondisk sdb ‐‐label boot ‐‐active ‐‐align 1024 + part / ‐‐source rootfs ‐‐ondisk sdb ‐‐fstype=ext3 ‐‐label platform ‐‐align 1024 Once the lines are changed, the example generates the directdisksdb image. @@ -4200,11 +4255,11 @@ somewhere other than the default /var/tmp/wic directory: - $ wic create ~/test.wks -o /home/trz/testwic --rootfs-dir \ + $ wic create ~/test.wks -o /home/trz/testwic ‐‐rootfs-dir \ /home/trz/yocto/yocto-image/build/tmp/work/crownbay_noemgd-poky-linux/core-image-minimal/1.0-r0/rootfs \ - --bootimg-dir /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/share \ - --kernel-dir /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel \ - --native-sysroot /home/trz/yocto/yocto-image/build/tmp/sysroots/x86_64-linux + ‐‐bootimg-dir /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/share \ + ‐‐kernel-dir /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel \ + ‐‐native-sysroot /home/trz/yocto/yocto-image/build/tmp/sysroots/x86_64-linux Creating image(s)... @@ -4247,7 +4302,7 @@ partitions. The plugins provide a mechanism for mapping values specified in .wks files using the - --source keyword to a + ‐‐source keyword to a particular plugin implementation that populates a corresponding partition. @@ -4276,11 +4331,11 @@ When the wic implementation needs to invoke a partition-specific implementation, it looks for the plugin that has the same name as the - --source parameter given to + ‐‐source parameter given to that partition. For example, if the partition is set up as follows: - part /boot --source bootimg-pcbios ... + part /boot ‐‐source bootimg-pcbios ... The methods defined as class members of the plugin having the matching bootimg-pcbios.name @@ -4290,7 +4345,7 @@ To be more concrete, here is the plugin definition that matches a - --source bootimg-pcbios usage, + ‐‐source bootimg-pcbios usage, along with an example method called by the wic implementation when it needs to invoke an implementation-specific @@ -4312,7 +4367,7 @@ The SourcePlugin class defines the following methods, which is the current set of methods that can be implemented or overridden by - --source plugins. + ‐‐source plugins. Any methods not implemented by a SourcePlugin subclass inherit the implementations present in the @@ -4444,13 +4499,13 @@ Following are the supported options: - --size: + ‐‐size: The minimum partition size in MBytes. Specify an integer value such as 500. Do not append the number with "MB". You do not need this option if you use - --source. - --source: + ‐‐source. + ‐‐source: This option is a wic-specific option that names the source of the data that populates @@ -4462,7 +4517,7 @@ "Plugins" section. If you use - --source rootfs, + ‐‐source rootfs, wic creates a partition as large as needed and to fill it with the contents of the root filesystem pointed to by the @@ -4472,14 +4527,14 @@ option. The filesystem type used to create the partition is driven by the value of the - --fstype option + ‐‐fstype option specified for the partition. See the entry on - --fstype that + ‐‐fstype that follows for more information. If you use - --source plugin-name, + ‐‐source plugin-name, wic creates a partition as large as needed and fills it with the contents of the partition that is generated by the @@ -4492,10 +4547,10 @@ filesystem type end up being are dependent on the given plugin implementation. - --ondisk or --ondrive: + ‐‐ondisk or ‐‐ondrive: Forces the partition to be created on a particular disk. - --fstype: + ‐‐fstype: Sets the file system type for the partition. Valid values are: @@ -4512,7 +4567,7 @@ swap - --fsoptions: + ‐‐fsoptions: Specifies a free-form string of options to be used when mounting the filesystem. This string will be copied into the @@ -4522,15 +4577,15 @@ If not specified, the default string is "defaults". - --label label: + ‐‐label label: Specifies the label to give to the filesystem to be made on the partition. If the given label is already in use by another filesystem, a new label is created for the partition. - --active: + ‐‐active: Marks the partition as active. - --align (in KBytes): + ‐‐align (in KBytes): This option is a wic-specific option that says to start a partition on an x KBytes boundary. @@ -4547,17 +4602,17 @@ Bootloader functionality and boot partitions are implemented by the various - --source + ‐‐source plugins that implement bootloader functionality. The bootloader command essentially provides a means of modifying bootloader configuration. - --timeout: + ‐‐timeout: Specifies the number of seconds before the bootloader times out and boots the default option. - --append: + ‐‐append: Specifies kernel parameters. These parameters will be added to the syslinux APPEND or @@ -5826,7 +5881,8 @@ The merge_config.sh script is part of the Linux Yocto kernel Git repositories (i.e. linux-yocto-3.14, - linux-yocto-3.19, and so forth) + linux-yocto-3.10, + linux-yocto-3.8, and so forth) in the scripts/kconfig directory. For more information on configuration fragments, @@ -6484,7 +6540,7 @@ For this scenario, you need to start the PR Service using the bitbake-prserv command: - bitbake-prserv --host ip --port port --start + bitbake-prserv ‐‐host ip ‐‐port port ‐‐start In addition to hand-starting the service, you need to update the local.conf file of each @@ -7136,9 +7192,9 @@ Given this example, issue the following commands on the target: - # smart channel --add all type=rpm-md baseurl=http://server.name/rpm/all - # smart channel --add i585 type=rpm-md baseurl=http://server.name/rpm/i586 - # smart channel --add qemux86 type=rpm-md baseurl=http://server.name/rpm/qemux86 + # smart channel ‐‐add all type=rpm-md baseurl=http://server.name/rpm/all + # smart channel ‐‐add i585 type=rpm-md baseurl=http://server.name/rpm/i586 + # smart channel ‐‐add qemux86 type=rpm-md baseurl=http://server.name/rpm/qemux86 Also from the target machine, fetch the repository information using this command: @@ -8588,13 +8644,13 @@ Consequently, running the tests on other machine means that you have to move the contents and call runexported.py with - "--deploy-dir path" as + "‐‐deploy-dir path" as follows: - ./runexported.py --deploy-dir /new/path/on/this/machine testdata.json + ./runexported.py ‐‐deploy-dir /new/path/on/this/machine testdata.json runexported.py accepts other arguments - as well as described using --help. + as well as described using ‐‐help.
@@ -9054,7 +9110,7 @@ | DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common'] | DEBUG: Executing shell function do_compile | NOTE: make -j 16 - | make --no-print-directory all-am + | make ‐‐no-print-directory all-am | /bin/mkdir -p include/near | /bin/mkdir -p include/near | /bin/mkdir -p include/near @@ -9095,7 +9151,7 @@ | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ 0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h | ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h - | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/ + | i586-poky-linux-gcc -m32 -march=i586 ‐‐sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/ build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybuild/ yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0 -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/ @@ -9170,7 +9226,7 @@ Here is some abbreviated, sample output with the missing dependency clearly visible at the end: - i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/scott-lenovo/...... + i586-poky-linux-gcc -m32 -march=i586 ‐‐sysroot=/home/scott-lenovo/...... . . . @@ -9565,14 +9621,14 @@ - # opcontrol --reset - # opcontrol --start --separate=lib --no-vmlinux -c 5 + # opcontrol ‐‐reset + # opcontrol ‐‐start ‐‐separate=lib ‐‐no-vmlinux -c 5 . . [do whatever is being profiled] . . - # opcontrol --stop + # opcontrol ‐‐stop $ opreport -cl @@ -9585,7 +9641,7 @@ five levels deep. To profile the kernel, you would specify the - --vmlinux=/path/to/vmlinux option. + ‐‐vmlinux=/path/to/vmlinux option. The vmlinux file is usually in the source directory in the /boot/ directory and must match the running kernel. @@ -9648,7 +9704,7 @@ With this connection, you just need to run "oprofile-server" on the device. By default, OProfile listens on port 4224. - You can change the port using the --port command-line + You can change the port using the ‐‐port command-line option. @@ -9738,14 +9794,14 @@ If network access to the target is unavailable, you can generate an archive for processing in oprofile-viewer as follows: - # opcontrol --reset - # opcontrol --start --separate=lib --no-vmlinux -c 5 + # opcontrol ‐‐reset + # opcontrol ‐‐start ‐‐separate=lib ‐‐no-vmlinux -c 5 . . [do whatever is being profiled] . . - # opcontrol --stop + # opcontrol ‐‐stop # oparchive -o my_archive