Regression bug: dbus messagebus user generation is wrong

Regression bug: dbus messagebus user generation is wrong

[Bernhard Guillon]

Hi all,
we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
with this commit:

commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
Author: Otavio Salvador <otavio@ossystems.com.br>
Date:   Fri Oct 21 02:49:51 2011 +0000

     dbus: use useradd class to allow use in read-only filesystems

     Move creation of required user/groups to useradd class thus allowing
     use with read-only filesystems and booting the initial boot.

     Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>


We changed the owner ship of the user on the device before this commit. 
Now we change the owner ship on build time which is wrong. If we change 
the owner ship on buildtime we cannot know the gid of the messagebus 
group. On my system it is e.g 117 but on my targtet it is 997. There is no 
standard mapping for gid to names so we need to switch back to change the 
group on the device.

I can send a patch which reenables the postinstall owner ship change if 
you like.

Best regards,
Bernhard


--
Scanned by MailScanner.

Re: Regression bug: dbus messagebus user generation is wrong

[Richard Purdie]

On Thu, 2011-12-22 at 09:49 +0100, Bernhard Guillon wrote:
> we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
> with this commit:
> 
> commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
> Author: Otavio Salvador <otavio@ossystems.com.br>
> Date:   Fri Oct 21 02:49:51 2011 +0000
> 
>      dbus: use useradd class to allow use in read-only filesystems
> 
>      Move creation of required user/groups to useradd class thus allowing
>      use with read-only filesystems and booting the initial boot.
> 
>      Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> 
> 
> We changed the owner ship of the user on the device before this commit. 
> Now we change the owner ship on build time which is wrong. If we change 
> the owner ship on buildtime we cannot know the gid of the messagebus 
> group. On my system it is e.g 117 but on my targtet it is 997. There is no 
> standard mapping for gid to names so we need to switch back to change the 
> group on the device.
> 
> I can send a patch which reenables the postinstall owner ship change if 
> you like.

We have code which is designed to deal with this. The do_install,
do_package* and do_rootfs tasks are run under pseudo which maintains a
separate passwd/group file of IDs which are used instead of the system#s
passwd/group files. When we write out the packages, the named owners of
the files should be correct. When we install the packages, rpm/opkg/dpkg
should be looking up the names and resolving them to the correct IDs for
the system in question. We also have code to ensure the correct users
are present on the system before the packages are extracted.

There have been some issues in this area recently but those issues
should be resolved now. I believe the issue is present in the
1.1/edison/2011-1 release but the upcomming point release should fix
those regressions there.

So which code are you seeing this issue from?

Cheers,

Richard

Re: Regression bug: dbus messagebus user generation is wrong

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

On Thu, Dec 22, 2011 at 09:49:01AM +0100, Bernhard Guillon wrote:
> Hi all,
> we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
> with this commit:
> 
> commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
> Author: Otavio Salvador <otavio@ossystems.com.br>
> Date:   Fri Oct 21 02:49:51 2011 +0000
> 
>      dbus: use useradd class to allow use in read-only filesystems
> 
>      Move creation of required user/groups to useradd class thus allowing
>      use with read-only filesystems and booting the initial boot.
> 
>      Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> 
> 
> We changed the owner ship of the user on the device before this commit. 
> Now we change the owner ship on build time which is wrong. If we change 
> the owner ship on buildtime we cannot know the gid of the messagebus 
> group. On my system it is e.g 117 but on my targtet it is 997. There is no 
> standard mapping for gid to names so we need to switch back to change the 
> group on the device.

See http://bugzilla.pokylinux.org/show_bug.cgi?id=1711
but it's still broken in some cases (on my buildhost 3 from 5 machines
are broken, 2 are working after last opkg changes).

Good test is to enable testlab and run this in your deploy/images directory
find . ! -type l -name \*tar.gz`; do 
  echo $i; 
  tar -tvf $i | grep dbus-daemon-launch; 
  tar --numeric-owner -tvf $i | grep dbus-daemon-launch; 
  tar xzvpf $i ./etc/group; 
  grep messagebus ./etc/group; 
done | tee -a image.test

And working image needs to have not only messagebus as owner but also
matching GID in 2nd line and last line from packaged /etc/group. With
latest opkg fixes it seems to work, but only if there is messagebus in
packaged /etc/group at all, reported here:
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014619.html
but probably got lost in other issues with new opkg, like this one
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014654.html
(if D is not needed to be set from opkg then why was offlineroot_varname.patch
added in first place? and I have updated this after
offlineroot_varname.patch removal and new version is in shr branch)
 
> I can send a patch which reenables the postinstall owner ship change if 
> you like.

Such patch is already on ML from me, now I'm using .bbappend from my
layer 
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=c08dfd5f5559902f6966648f75d6c6bfd2597a5b

Cheers,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Regression bug: dbus messagebus user generation is wrong

[Bernhard Guillon]

On Thu, 22 Dec 2011, Martin Jansa wrote:

> See http://bugzilla.pokylinux.org/show_bug.cgi?id=1711
> but it's still broken in some cases (on my buildhost 3 from 5 machines
> are broken, 2 are working after last opkg changes).
>
> Good test is to enable testlab and run this in your deploy/images directory
> find . ! -type l -name \*tar.gz`; do
>  echo $i;
>  tar -tvf $i | grep dbus-daemon-launch;
>  tar --numeric-owner -tvf $i | grep dbus-daemon-launch;
>  tar xzvpf $i ./etc/group;
>  grep messagebus ./etc/group;
> done | tee -a image.test
>
> And working image needs to have not only messagebus as owner but also
> matching GID in 2nd line and last line from packaged /etc/group. With
> latest opkg fixes it seems to work, but only if there is messagebus in
> packaged /etc/group at all, reported here:
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014619.html
> but probably got lost in other issues with new opkg, like this one
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014654.html
> (if D is not needed to be set from opkg then why was offlineroot_varname.patch
> added in first place? and I have updated this after
> offlineroot_varname.patch removal and new version is in shr branch)


Thanks, for the detailed description. I will try to dig deeper and use a 
bbappend as a hotfix.

Best regards,
Bernhard


--
Scanned by MailScanner.

Re: Regression bug: dbus messagebus user generation is wrong

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]


Op 22 dec. 2011, om 10:10 heeft Martin Jansa het volgende geschreven:

> On Thu, Dec 22, 2011 at 09:49:01AM +0100, Bernhard Guillon wrote:
>> Hi all,
>> we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
>> with this commit:
>> 
>> commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
>> Author: Otavio Salvador <otavio@ossystems.com.br>
>> Date:   Fri Oct 21 02:49:51 2011 +0000
>> 
>>     dbus: use useradd class to allow use in read-only filesystems
>> 
>>     Move creation of required user/groups to useradd class thus allowing
>>     use with read-only filesystems and booting the initial boot.
>> 
>>     Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> 
>> 
>> We changed the owner ship of the user on the device before this commit. 
>> Now we change the owner ship on build time which is wrong. If we change 
>> the owner ship on buildtime we cannot know the gid of the messagebus 
>> group. On my system it is e.g 117 but on my targtet it is 997. There is no 
>> standard mapping for gid to names so we need to switch back to change the 
>> group on the device.
> 
> See http://bugzilla.pokylinux.org/show_bug.cgi?id=1711
> but it's still broken in some cases (on my buildhost 3 from 5 machines
> are broken, 2 are working after last opkg changes).
> 
> Good test is to enable testlab and run this in your deploy/images directory
> find . ! -type l -name \*tar.gz`; do 
>  echo $i; 
>  tar -tvf $i | grep dbus-daemon-launch; 
>  tar --numeric-owner -tvf $i | grep dbus-daemon-launch; 
>  tar xzvpf $i ./etc/group; 
>  grep messagebus ./etc/group; 
> done | tee -a image.test
> 
> And working image needs to have not only messagebus as owner but also
> matching GID in 2nd line and last line from packaged /etc/group. With
> latest opkg fixes it seems to work, but only if there is messagebus in
> packaged /etc/group at all, reported here:
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014619.html
> but probably got lost in other issues with new opkg, like this one
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014654.html
> (if D is not needed to be set from opkg then why was offlineroot_varname.patch
> added in first place? and I have updated this after
> offlineroot_varname.patch removal and new version is in shr branch)
> 
>> I can send a patch which reenables the postinstall owner ship change if 
>> you like.
> 
> Such patch is already on ML from me, now I'm using .bbappend from my
> layer 
> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=c08dfd5f5559902f6966648f75d6c6bfd2597a5b

I'm willing to put that into meta-oe till the problem is 100% fixed.

regards,

Koen

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: Regression bug: dbus messagebus user generation is wrong

[Richard Purdie]

On Thu, 2011-12-22 at 11:26 +0100, Koen Kooi wrote:
> Op 22 dec. 2011, om 10:10 heeft Martin Jansa het volgende geschreven:
> 
> > On Thu, Dec 22, 2011 at 09:49:01AM +0100, Bernhard Guillon wrote:
> >> Hi all,
> >> we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
> >> with this commit:
> >> 
> >> commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
> >> Author: Otavio Salvador <otavio@ossystems.com.br>
> >> Date:   Fri Oct 21 02:49:51 2011 +0000
> >> 
> >>     dbus: use useradd class to allow use in read-only filesystems
> >> 
> >>     Move creation of required user/groups to useradd class thus allowing
> >>     use with read-only filesystems and booting the initial boot.
> >> 
> >>     Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> >> 
> >> 
> >> We changed the owner ship of the user on the device before this commit. 
> >> Now we change the owner ship on build time which is wrong. If we change 
> >> the owner ship on buildtime we cannot know the gid of the messagebus 
> >> group. On my system it is e.g 117 but on my targtet it is 997. There is no 
> >> standard mapping for gid to names so we need to switch back to change the 
> >> group on the device.
> > 
> > See http://bugzilla.pokylinux.org/show_bug.cgi?id=1711
> > but it's still broken in some cases (on my buildhost 3 from 5 machines
> > are broken, 2 are working after last opkg changes).
> > 
> > Good test is to enable testlab and run this in your deploy/images directory
> > find . ! -type l -name \*tar.gz`; do 
> >  echo $i; 
> >  tar -tvf $i | grep dbus-daemon-launch; 
> >  tar --numeric-owner -tvf $i | grep dbus-daemon-launch; 
> >  tar xzvpf $i ./etc/group; 
> >  grep messagebus ./etc/group; 
> > done | tee -a image.test
> > 
> > And working image needs to have not only messagebus as owner but also
> > matching GID in 2nd line and last line from packaged /etc/group. With
> > latest opkg fixes it seems to work, but only if there is messagebus in
> > packaged /etc/group at all, reported here:
> > http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014619.html
> > but probably got lost in other issues with new opkg, like this one
> > http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014654.html
> > (if D is not needed to be set from opkg then why was offlineroot_varname.patch
> > added in first place? and I have updated this after
> > offlineroot_varname.patch removal and new version is in shr branch)
> > 
> >> I can send a patch which reenables the postinstall owner ship change if 
> >> you like.
> > 
> > Such patch is already on ML from me, now I'm using .bbappend from my
> > layer 
> > http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=c08dfd5f5559902f6966648f75d6c6bfd2597a5b
> 
> I'm willing to put that into meta-oe till the problem is 100% fixed.

What I really need is help in understanding what is still breaking. If
someone can show me where things are going wrong I can help (and have
done so) but "there is a problem somewhere" isn't going to help get this
fixed :(

Cheers,

Richard

Re: Regression bug: dbus messagebus user generation is wrong

[Richard Purdie]

On Thu, 2011-12-22 at 10:10 +0100, Martin Jansa wrote:
> See http://bugzilla.pokylinux.org/show_bug.cgi?id=1711
> but it's still broken in some cases (on my buildhost 3 from 5 machines
> are broken, 2 are working after last opkg changes).

Do we have any more details on what is broken or how this is happening?
I'm at a loss as to how to help with this.

> Good test is to enable testlab and run this in your deploy/images directory
> find . ! -type l -name \*tar.gz`; do 
>   echo $i; 
>   tar -tvf $i | grep dbus-daemon-launch; 
>   tar --numeric-owner -tvf $i | grep dbus-daemon-launch; 
>   tar xzvpf $i ./etc/group; 
>   grep messagebus ./etc/group; 
> done | tee -a image.test
> 
> And working image needs to have not only messagebus as owner but also
> matching GID in 2nd line and last line from packaged /etc/group. With
> latest opkg fixes it seems to work, but only if there is messagebus in
> packaged /etc/group at all, reported here:
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014619.html
> but probably got lost in other issues with new opkg, like this one
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014654.html
> (if D is not needed to be set from opkg then why was offlineroot_varname.patch
> added in first place? and I have updated this after
> offlineroot_varname.patch removal and new version is in shr branch)

I added offlineroot_varname at a point when the export D in
rootfs_ipk.bbclass was later. In the final version I moved it and the
other exports earlier to fix different problems. The patch still looked
like a good idea at that point. When a problem appeared with the patch I
decided just to drop it. We should probably continue to export PKG_ROOT
for compatibility and maybe export D in addition to that.

Cheers,

Richard

Re: Regression bug: dbus messagebus user generation is wrong

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 10156 bytes --]

On Thu, Dec 22, 2011 at 10:10:41AM +0100, Martin Jansa wrote:
> On Thu, Dec 22, 2011 at 09:49:01AM +0100, Bernhard Guillon wrote:
> > Hi all,
> > we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
> > with this commit:
> > 
> > commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
> > Author: Otavio Salvador <otavio@ossystems.com.br>
> > Date:   Fri Oct 21 02:49:51 2011 +0000
> > 
> >      dbus: use useradd class to allow use in read-only filesystems
> > 
> >      Move creation of required user/groups to useradd class thus allowing
> >      use with read-only filesystems and booting the initial boot.
> > 
> >      Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > 
> > 
> > We changed the owner ship of the user on the device before this commit. 
> > Now we change the owner ship on build time which is wrong. If we change 
> > the owner ship on buildtime we cannot know the gid of the messagebus 
> > group. On my system it is e.g 117 but on my targtet it is 997. There is no 
> > standard mapping for gid to names so we need to switch back to change the 
> > group on the device.
> 
> See http://bugzilla.pokylinux.org/show_bug.cgi?id=1711
> but it's still broken in some cases (on my buildhost 3 from 5 machines
> are broken, 2 are working after last opkg changes).
> 
> Good test is to enable testlab and run this in your deploy/images directory
> find . ! -type l -name \*tar.gz`; do 
>   echo $i; 
>   tar -tvf $i | grep dbus-daemon-launch; 
>   tar --numeric-owner -tvf $i | grep dbus-daemon-launch; 
>   tar xzvpf $i ./etc/group; 
>   grep messagebus ./etc/group; 
> done | tee -a image.test

./om-gta02/shr-image-om-gta02-20111221231021.rootfs.tar.gz
-rwsr-xr-- root/messagebus  142604 2011-12-19 14:11 ./usr/libexec/dbus-daemon-launch-helper
-rwsr-xr-- 0/997        142604 2011-12-19 14:11 ./usr/libexec/dbus-daemon-launch-helper
./etc/group
messagebus:x:997:
./qemux86-64/shr-image-qemux86-64-20111222003421.rootfs.tar.gz
-rwsr-xr-- root/messagebus  250448 2011-12-19 15:10 ./usr/libexec/dbus-daemon-launch-helper
-rwsr-xr-- 0/997        250448 2011-12-19 15:10 ./usr/libexec/dbus-daemon-launch-helper
./etc/group
messagebus:x:997:
./spitz/shr-image-spitz-20111222011259.rootfs.tar.gz
-rwsr-xr-- root/997     138408 2011-12-21 07:47 ./usr/libexec/dbus-daemon-launch-helper
-rwsr-xr-- 0/997        138408 2011-12-21 07:47 ./usr/libexec/dbus-daemon-launch-helper
./etc/group
./nokia900/shr-image-nokia900-20111221234558.rootfs.tar.gz
-rwsr-xr-- root/sshd    187568 2011-12-19 14:35 ./usr/libexec/dbus-daemon-launch-helper
-rwsr-xr-- 0/998        187568 2011-12-19 14:35 ./usr/libexec/dbus-daemon-launch-helper
./etc/group

This is output from that on my buildhost (qemuarm which was also broken is gone, removed when
testing to rebuild spitz - also armv5te from scratch).

So spitz and nokia900 are wrong, qemux86 and om-gta02 working.

When trying to find what's different in spitz and nokia900 I've tried:
OE @ ~/shr-core $ grep messagebus tmp-eglibc/sysroots/*/usr/share/base-passwd/group.master
OE @ ~/shr-core $ grep messagebus tmp-eglibc/sysroots/*/etc/group
tmp-eglibc/sysroots/nokia900/etc/group:messagebus:x:998:
tmp-eglibc/sysroots/om-gta02/etc/group:messagebus:x:998:
tmp-eglibc/sysroots/qemux86-64/etc/group:messagebus:x:998:
tmp-eglibc/sysroots/spitz/etc/group:messagebus:x:997:

OE @ ~/shr-core $ grep messagebus tmp-eglibc/sysroots/*/etc/passwd
tmp-eglibc/sysroots/nokia900/etc/passwd:messagebus:!:999:998::/var/lib/dbus:/bin/false
tmp-eglibc/sysroots/om-gta02/etc/passwd:messagebus:!:999:998::/var/lib/dbus:/bin/false
tmp-eglibc/sysroots/qemux86-64/etc/passwd:messagebus:!:999:998::/var/lib/dbus:/bin/false
tmp-eglibc/sysroots/spitz/etc/passwd:messagebus:!:998:997::/var/lib/dbus:/bin/false

Sofar looks the same, but from log.do_rootfs files it looks
like base-passwd is not installed soon enough on spitz and nokia900.

Not sure why nscd is so picky or why base-passwd isn't installed soon enough in some cases,
but I'll try to debug more and provide more info (as I have done before).

I've tried to -c cleansstate base-passwd dbus dbus-native to fix
or break any machine, but it doesn't change it (broken are broken again
after rebuild and correct also stay correct).

/********* logs *************/
Checking ERRORs in log.do_rootfs files
============== correct om-gta02:
Installing base-passwd (3.5.22-r9) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv4t/base-passwd_3.5.22-r9_armv4t.ipk.
Running groupadd commands...
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
Installing dbus-1 (1.4.16-r2) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv4t/dbus-1_1.4.16-r2_armv4t.ipk.
Installing libexpat1 (2.0.1-r1) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv4t/libexpat1_2.0.1-r1_armv4t.ipk.
Running groupadd commands...
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
Running useradd commands...
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
Installing util-linux-blkid (2.19.1-r12) to root...

And similar sequence is in qemux86-64 (also correct)

============== wrong nokia900:
Installing dbus-1 (1.4.16-r2) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/dbus-1_1.4.16-r2_armv7a-vfp-neon.ipk.
Running groupadd commands...
grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/group: No such file or directory
groupadd: cannot open /etc/group
Running useradd commands...
grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/passwd: No such file or directory
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
useradd: cannot open /etc/passwd
...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/connman_0.78-r9_armv7a-vfp-neon.ipk.
Running useradd commands...
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
Installing iptables (1.4.12.1-r0) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/nokia900/shadow_4.1.4.3-r7_nokia900.ipk.
Running groupadd commands...
grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/group: No such file or directory
groupadd: cannot open /etc/group

and later
Installing base-passwd (3.5.22-r9) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/base-passwd_3.5.22-r9_armv7a-vfp-neon.ipk.

and then groupadd/useradd working better
Installing connman (0.78-r9) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/connman_0.78-r9_armv7a-vfp-neon.ipk.
Running useradd commands...
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/openssh-sshd_5.9p1-r6_armv7a-vfp-neon.ipk.
Running useradd commands...
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
...
Installing ppp-dialin (0.1-r8) to root...
Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/all/ppp-dialin_0.1-r8_all.ipk.
Running useradd commands...
useradd: group '1000' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!
/usr/sbin/nscd: Only root is allowed to use this option!

And similar sequence is in spitz (also wrong)

Cheers,
> 
> And working image needs to have not only messagebus as owner but also
> matching GID in 2nd line and last line from packaged /etc/group. With
> latest opkg fixes it seems to work, but only if there is messagebus in
> packaged /etc/group at all, reported here:
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014619.html
> but probably got lost in other issues with new opkg, like this one
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014654.html
> (if D is not needed to be set from opkg then why was offlineroot_varname.patch
> added in first place? and I have updated this after
> offlineroot_varname.patch removal and new version is in shr branch)
>  
> > I can send a patch which reenables the postinstall owner ship change if 
> > you like.
> 
> Such patch is already on ML from me, now I'm using .bbappend from my
> layer 
> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=c08dfd5f5559902f6966648f75d6c6bfd2597a5b
> 
> Cheers,
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com



-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Regression bug: dbus messagebus user generation is wrong

[Mark Hatle]

On 12/22/11 7:17 AM, Martin Jansa wrote:
...

> /********* logs *************/
> Checking ERRORs in log.do_rootfs files
> ============== correct om-gta02:
> Installing base-passwd (3.5.22-r9) to root...
> Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv4t/base-passwd_3.5.22-r9_armv4t.ipk.
> Running groupadd commands...
> /usr/sbin/nscd: Only root is allowed to use this option!
> /usr/sbin/nscd: Only root is allowed to use this option!
> /usr/sbin/nscd: Only root is allowed to use this option!

We need to track down that error above and figure out what it means.  It could 
be that groupadd is attempting to run a system helper that it shouldn't be. 
(nscd should never be consulted when we are running through pseudo for 
password/group calculations...)

...

> ============== wrong nokia900:
> Installing dbus-1 (1.4.16-r2) to root...
> Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/dbus-1_1.4.16-r2_armv7a-vfp-neon.ipk.
> Running groupadd commands...
> grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/group: No such file or directory
> groupadd: cannot open /etc/group
> Running useradd commands...
> grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/passwd: No such file or directory
> useradd: group '1000' does not exist
> useradd: the GROUP= configuration in /etc/default/useradd will be ignored
> useradd: cannot open /etc/passwd
> ...

Ya, that is definitely broken.  W/o the files then the groupadd/useradd won't 
function properly and the install is likely a failure.

On other systems I work with, we -always- install the passwd/group files onto 
the system -first-.  Then we perform the regular installation procedure.  I 
wonder if we may have to do something like that within oe-core to force the 
proper ordering.

It would be interesting to me to see the install order that was selected in this 
case.  It could be that opkg either is missing some critical dependency 
information -- or perhaps what we need simply can't be specified.

In other systems I've worked with, the base-passwd packages has been a 
requirement of the libc package.  Since libc generally gets installed early in 
the process it usually enforces it to be first.  I'm not sure if OE-core has 
that same dep.  (Maybe we simply need any package that has files != root:root 
have a dep on the passwd files?  Just thinking outloud here.. I'm not sure thats 
really a good idea.)

--Mark

Re: Regression bug: dbus messagebus user generation is wrong

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]

On Thu, Dec 22, 2011 at 09:52:43AM -0600, Mark Hatle wrote:
> On 12/22/11 7:17 AM, Martin Jansa wrote:
> ...
> 
> > /********* logs *************/
> > Checking ERRORs in log.do_rootfs files
> > ============== correct om-gta02:
> > Installing base-passwd (3.5.22-r9) to root...
> > Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv4t/base-passwd_3.5.22-r9_armv4t.ipk.
> > Running groupadd commands...
> > /usr/sbin/nscd: Only root is allowed to use this option!
> > /usr/sbin/nscd: Only root is allowed to use this option!
> > /usr/sbin/nscd: Only root is allowed to use this option!
> 
> We need to track down that error above and figure out what it means.  It could 
> be that groupadd is attempting to run a system helper that it shouldn't be. 
> (nscd should never be consulted when we are running through pseudo for 
> password/group calculations...)
> 
> ...
> 
> > ============== wrong nokia900:
> > Installing dbus-1 (1.4.16-r2) to root...
> > Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/dbus-1_1.4.16-r2_armv7a-vfp-neon.ipk.
> > Running groupadd commands...
> > grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/group: No such file or directory
> > groupadd: cannot open /etc/group
> > Running useradd commands...
> > grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/passwd: No such file or directory
> > useradd: group '1000' does not exist
> > useradd: the GROUP= configuration in /etc/default/useradd will be ignored
> > useradd: cannot open /etc/passwd
> > ...
> 
> Ya, that is definitely broken.  W/o the files then the groupadd/useradd won't 
> function properly and the install is likely a failure.
> 
> On other systems I work with, we -always- install the passwd/group files onto 
> the system -first-.  Then we perform the regular installation procedure.  I 
> wonder if we may have to do something like that within oe-core to force the 
> proper ordering.
> 
> It would be interesting to me to see the install order that was selected in this 
> case.  It could be that opkg either is missing some critical dependency 
> information -- or perhaps what we need simply can't be specified.
> 
> In other systems I've worked with, the base-passwd packages has been a 
> requirement of the libc package.  Since libc generally gets installed early in 
> the process it usually enforces it to be first.  I'm not sure if OE-core has 
> that same dep.  (Maybe we simply need any package that has files != root:root 
> have a dep on the passwd files?  Just thinking outloud here.. I'm not sure thats 
> really a good idea.)

dbus-1 .ipk file for all 4 architectures here has
Depends: update-rc.d, libdbus-1-3 (>= 1.4.16), libc6 (>= 2.14), shadow, libexpat1 (>= 2.0.1), base-passwd
so the RDEPENDS added by useradd.bbclass worked fine.

But for some reason opkg fix from
http://git.openembedded.org/openembedded-core/commit/?id=2feba313c991170747381c7cf821a45c2cd04632
wasn't enough to ensure that base-passwd was installed before dbus-1

and it probably isn't caused by circular dependency which were allowed by
http://git.openembedded.org/openembedded-core/commit/?id=5a2b67b8faad3dd5417ba89d8e82ca564753ccc9
because I have this in very similar images (same image just different
MACHINE) and I had this even before this patch (in build with all
circular dependencies broken by RRECOMMENDS).

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Regression bug: dbus messagebus user generation is wrong

[Richard Purdie]

On Thu, 2011-12-22 at 09:52 -0600, Mark Hatle wrote:
> On 12/22/11 7:17 AM, Martin Jansa wrote:
> ...
> 
> > /********* logs *************/
> > Checking ERRORs in log.do_rootfs files
> > ============== correct om-gta02:
> > Installing base-passwd (3.5.22-r9) to root...
> > Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv4t/base-passwd_3.5.22-r9_armv4t.ipk.
> > Running groupadd commands...
> > /usr/sbin/nscd: Only root is allowed to use this option!
> > /usr/sbin/nscd: Only root is allowed to use this option!
> > /usr/sbin/nscd: Only root is allowed to use this option!
> 
> We need to track down that error above and figure out what it means.  It could 
> be that groupadd is attempting to run a system helper that it shouldn't be. 
> (nscd should never be consulted when we are running through pseudo for 
> password/group calculations...)
> 
> ...
> 
> > ============== wrong nokia900:
> > Installing dbus-1 (1.4.16-r2) to root...
> > Downloading file:/OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/dbus-1_1.4.16-r2_armv7a-vfp-neon.ipk.
> > Running groupadd commands...
> > grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/group: No such file or directory
> > groupadd: cannot open /etc/group
> > Running useradd commands...
> > grep: /OE/shr-core/tmp-eglibc/work/nokia900-oe-linux-gnueabi/shr-image-2.0-r20/rootfs//etc/passwd: No such file or directory
> > useradd: group '1000' does not exist
> > useradd: the GROUP= configuration in /etc/default/useradd will be ignored
> > useradd: cannot open /etc/passwd
> > ...
> 
> Ya, that is definitely broken.  W/o the files then the groupadd/useradd won't 
> function properly and the install is likely a failure.
> 
> On other systems I work with, we -always- install the passwd/group files onto 
> the system -first-.  Then we perform the regular installation procedure.  I 
> wonder if we may have to do something like that within oe-core to force the 
> proper ordering.
> 
> It would be interesting to me to see the install order that was selected in this 
> case.  It could be that opkg either is missing some critical dependency 
> information -- or perhaps what we need simply can't be specified.
> 
> In other systems I've worked with, the base-passwd packages has been a 
> requirement of the libc package.  Since libc generally gets installed early in 
> the process it usually enforces it to be first.  I'm not sure if OE-core has 
> that same dep.  (Maybe we simply need any package that has files != root:root 
> have a dep on the passwd files?  Just thinking outloud here.. I'm not sure thats 
> really a good idea.)

FWIW the useradd class is adding dependencies and those dependencies
should now be being honoured by opkg after the recent changes.

Martin: If you could share the full do_rootfs log for a broken image
I'll take a look and see if I can spot anything...

Cheers,

Richard