On 10/11/2014 04:10 PM, Gary Thomas wrote:
On 2014-10-11 11:16, Peter A. Bigot wrote:
Back at
http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053836.html
it was noted that the dbus home directory /var/lib/dbus on the target
was using the
build host uid/gid. Various discussion agreed this shouldn't happen,
but there was no resolution in the thread.
I found https://bugzilla.yoctoproject.org/show_bug.cgi?id=1711 which
is marked fixed, but on a newly installed system I find:
root@beaglebone:~# ls -l /var/lib
total 52
drwxr-xr-x 2 root root 4096 Oct 11 2014 alsa
drwxr-xr-x 2 root root 4096 Oct 11 2014 arpd
drwxr-xr-x 2 root root 4096 Oct 11 12:30 connman
drwxr-xr-x 2 102 105 4096 Oct 11 2014 dbus
where the dbus uid/gid is from my host system as shown by:
root@beaglebone:~# grep dbus /etc/passwd
messagebus:x:999:998::/var/lib/dbus:/bin/false
llc[140]$ grep dbus /etc/passwd
messagebus:x:102:105::/var/run/dbus:/bin/false
This arises in an image extending core-image-base building meta-ti's
version of beaglebone. (I'm actually trying to fix the same problem
arising in a patch intended to make sure
ntp's home directory exists, but the dbus one appears to be the same
thing.)
The suggested workaround for opkg of using a pkg_postinst script
doesn't work in my case because the rpm post-install script gets run
on the build host that's creating rootfs.The
ownership is wrong in the generated rootfs tar files whether or not
there's a post-install script that tries to change it.
For my ntp patch I verified that removing the package and installing
it on the target does work as expected.
Does anybody else see this sort of thing?
If not, where in the image packaging code is the magic that's
supposed to help pseudo record who's really supposed to own the files
and re-apply that when the image packaging is done?
It does not happen in my builds which are more-or-less stock
Poky (I have my own distro and BSP layers). Must be something
going on in the meta-ti layer?
Are you using the latest OE-core (or Poky/Yocto) master?
Thanks for the sanity check.
I'm using master of poky and meta-openembedded, right at the point of
dizzy branch. The problem is reproduced with a fresh bitbake
core-image-base with these layers:
BBLAYERS ?= "\
${OE_META_SOURCES}/poky/meta \
${OE_META_SOURCES}/poky/meta-yocto \
${OE_META_SOURCES}/poky/meta-yocto-bsp \
${OE_META_SOURCES}/meta-openembedded/meta-filesystems \
${OE_META_SOURCES}/meta-openembedded/meta-networking \
${OE_META_SOURCES}/meta-openembedded/meta-oe \
${OE_META_SOURCES}/meta-openembedded/meta-systemd \
${OE_META_SOURCES}/meta-openembedded/meta-python \
${OE_META_SOURCES}/meta-qt3 \
"
and these customizations options in local.conf:
# Default machine
MACHINE ?= "beaglebone"
# Want to try this distro, but it enables security_flags.inc which
# requires recipe changes.
#DISTRO = "poky-lsb"
# So instead do some of the pieces so we can still use core-image-lsb*
DISTRO = "poky"
DISTROOVERRIDES = "poky:linuxstdbase"
DISTRO_FEATURES_append = " pam largefile"
# The future is systemd
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
I did try commenting out the override for poky:linuxstdbase and it had
no effect. I'll try trimming out more stuff tomorrow.
Peter
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
