summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/installer/adt-installer/scripts/extract_rootfs
Commit message (Collapse)AuthorAgeFilesLines
* adt-installer: Drop since its replaced by the extensible SDKRichard Purdie2016-02-281-67/+0
| | | | | | | | | | | | | | The extensible SDK replaces adt-installer so this can be removed now, all future effort in this direction will be placed onto that. This includes a layer version change so the autobuilder knows when to stop building adt-installer. [YOCTO #6404] (From OE-Core rev: c413164c03bdce38f41e63ad2a27dc6108521b9a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu-export-rootfs and friends: don't put pseudo db in target fsPeter Seebach2012-08-291-4/+4
| | | | | | | | | | | | | | | | | | | | 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>
* POKY_NATIVE_SYSROOT -> OECORE_NATIVE_SYSROOTRichard Purdie2011-04-211-1/+1
| | | | | | (From OE-Core rev: c056aeaa13549b404088e3d465f3b03443e5ab88) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* adt-intaller feature implementation, including the bitbake recipe file for ↵Liping Ke2011-01-121-0/+67
creating the intaller tar file under /tmp/deploy/sdk, and the adt-installer script files and config files, set the reference to adt repo entry empty before it's setup Signed-off-by: Jessica Zhang <jessica.zhang@intel.com>