summaryrefslogtreecommitdiff
path: root/scripts/runqemu-extract-sdk
AgeCommit message (Collapse)AuthorFiles
2014-07-03runqemu-extract-sdk: normalize paths to improve outputChen Qi1
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 Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-10-26runqemu-extract-sdk: add --numeric-owner option to tar commandChen Qi1
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] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-08-28runqemu-export-rootfs and friends: don't put pseudo db in target fsPeter Seebach1
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. Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
2011-09-02scripts: Show sensible warning messages if expected binaries don't existRichard Purdie1
[YOCTO #1438] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-04-21Further cleanup of various poky referencesRichard Purdie1
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-04-21runqemu-extra-sdk: Update function usage to clearly reflect its meaningRichard Purdie1
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-04-21Rename ~/.poky-sdk/ temp workdir to ~/.runqemu-sdk/Richard Purdie1
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-04-20Rename the remaining poky-* scripts to oe-* or runqemu-*Richard Purdie1
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>