On 10/18/13 10:04 AM, Richard Purdie wrote:
On Wed, 2013-10-16 at 15:25 -0500, Tom Zanussi wrote:
Without this, files in the generated filesystem pick up the wrong
ownership.
Signed-off-by: Tom Zanussi <[email protected]>
---
scripts/lib/mic/kickstart/custom_commands/partition.py | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/mic/kickstart/custom_commands/partition.py
b/scripts/lib/mic/kickstart/custom_commands/partition.py
index 302cace..0eb0671 100644
--- a/scripts/lib/mic/kickstart/custom_commands/partition.py
+++ b/scripts/lib/mic/kickstart/custom_commands/partition.py
@@ -216,7 +216,14 @@ class Wic_PartData(Mic_PartData):
"""
Prepare content for an ext2/3/4 rootfs partition.
"""
- populate_script = "%s/usr/bin/populate-extfs.sh" % native_sysroot
+ populate_script = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
+ populate_script += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
rootfs_dir
+ populate_script += "export PSEUDO_PASSWD=%s;" % rootfs_dir
Location of the passwd file, if we are in a chroot, it will use the chroot'd
version, otherwise you need to tell pseudo where it is.
+ populate_script += "export PSEUDO_NOSYMLINKEXP=1;"
This controls how the symlinks are populated from the point of view of
non-pseudo environment. If you intend to manipulate the results (and make them
useful) -outside- of the pseudo environment, you need this. If you do all of
your operations from within pseudo, the defaults are correct. Otherwise you can
get links such as "/bin/sh -> /bin/bash" and it points to the host's bash, not
the chroot's /bin/bash.
+ populate_script += "export PSEUDO_DISABLED=0;"
This shouldn't have to be set, unless the disabled has been previously set in
the environment.
+ populate_script += "%s/usr/bin/pseudo %s/usr/bin/populate-extfs.sh" % \
+ (native_sysroot, native_sysroot)
+
image_extra_space = 10240
image_rootfs = rootfs_dir
I've merged this but I would like to figure out why pseudo can't manage
more sane defaults rather than needing all of those variables...
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
