| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Indentation using a mix of whitespaces and tabs has been unified in
favor of tabs.
(From OE-Core rev: 3827f1aa4a2bb433e445802c48e32f72932950e6)
Signed-off-by: Dennis Menschel <menschel-d@posteo.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
As the format "tar.xz" is included in the IMAGE_TYPES bitbake variable
as defined in meta/classes/image_types.bbclass, it should also be
possible to extract a rootfs that has been built using that format.
(From OE-Core rev: f813ca7b085c7ddf76a34932e2b3f5bc3372b239)
Signed-off-by: Dennis Menschel <menschel-d@posteo.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Usually, the debugfs' (-dbg.tar.*) work follow is:
1) Install regular rootfs to dir_foo
2) Install debugfs (-dbg.tar.*) to the same dir_foo
So we need to allow installing the debugfs on top of the rootfs.
(From OE-Core rev: c54147b286d72d7c4f8ca55a5a62f5d27bd5364a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic STAGING_DIR_NATIVE is gone since RSS, so when find
OECORE_NATIVE_SYSROOT, the user has to specify which recipe's
STAGING_DIR_NATIVE will be used as OECORE_NATIVE_SYSROOT.
* The usage is changed from ". oe-find-native-sysroot" to
". oe-find-native-sysroot <recipe>".
* The oe-run-native's usage has changed from
"oe-run-native tool" to "oe-run-native native-recipe tool".
(From OE-Core rev: e2f6d937bd897083779507ecb9ecd15513b35f1f)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we would have output like below from runqemu-extract-sdk.
Creating directory /home/chenqi/poky/build-systemd/./nfs-root
Normalize paths for runqemu-extract-sdk so that we have output like below.
Creating directory /home/chenqi/poky/build-systemd/nfs-root
(From OE-Core rev: c85f5ec502fecb1ff63f8e795a0da5fc92eca0c1)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the same username exists on both target and the build host, but
the uids differ, and we start target via NFS, then the uid for the
user will be incorrect on target.
For example, if postfix's uid on host is 119 and on target is 1024,
then if we start target via NFS, the uid for postfix will be 119.
The root cause is that when we use runqemu-extract-sdk to generate
the NFS rootfs for later use, the tar command will respect the username
instead of uid. So if PSEUDO_PASSWD environment is not set correctly,
the host /etc/passwd will be used, resulting in wrong uids.
The situation for gid is completely analogous to that of uid.
It's almost impossible for the runqemu-extract-sdk to guess the correct
location of the needed password file merely based on the target tarball
name.
This patch solves this problem by adding the '--numeric-owner' option
to the tar command so that the uid/gid will be used when extracting the
tarball using runqemu-extract-sdk. In this situation, we'll always get
the correct uid/gid after extracting the tarball.
[YOCTO #5364]
(From OE-Core rev: acce6ff1a77cfd29e3868faa89b120becb58bbbf)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a few places, we have scripts which use <rootfs>/var/pseudo for
the pseudo state directory controlling a given filesystem. This
seems possibly risky because it means that stuff running under
qemu or whatnot could wipe out the data being used to handle that
rootfs. Move this to:
<rootfs>/../$(basename_rootfs).pseudo_state
to avoid problems.
This also solves at least one case (not directly hit by yocto's
tree) wherein you could end up trying to remove a rootfs while
pseudo was using a database inside that rootfs, and thus the
remove would fail.
(From OE-Core rev: aa5d6bd006d3b4eede21d8987451876ed3385ab8)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
| |
[YOCTO #1438]
(From OE-Core rev: 6b5706d1f9ce7a3fd4d8f819ff8f3fd789665647)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
| |
permissions)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
| |
(From OE-Core rev: fe73ea8c510877fe4e3c117985e8f3d0b79ddf1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
| |
(From OE-Core rev: 04c1d218ffb775d25c0eaefa3558bab250bb3b4b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
| |
(From OE-Core rev: 69a0bfb8d7203db1c477dc28974287fda35d1a50)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
(From OE-Core rev: 877b3d84597fcfc3abf5aa332019d412f2717896)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
