[OE-core] [PATCH 2/7] shadow: add a -native recipe with customized utilities
Mark Hatle
mark.hatle at windriver.com
Thu Sep 1 16:54:04 UTC 2011
On 9/1/11 11:41 AM, Phil Blundell wrote:
> On Thu, 2011-09-01 at 15:46 +0100, Phil Blundell wrote:
>> I just tried using useradd.bbclass for the first time (in an effort to
>> make dbus installable on a readonly-rootfs) and it doesn't seem to be
>> working very well for me.
>>
>> The root of my problem seems to be the code below. As far as I can
>> tell, what's happening is that process_root_flag() consumes all the
>> command line arguments to useradd, which means that the subsequent call
>> to getopt() in process_flags() just returns immediately because there is
>> nothing left for it to do. The upshot of all this is that the switches
>> on the command line are simply ignored and useradd doesn't do what I
>> wanted.
>>
>> Is anybody else using this code successfully in oe-core with a
>> nontrivial USERADD_PARAM?
>
> So, I added a strategic "optind = 1" to useradd.c and the situation
> seems to have improved a bit. However, I've encountered a couple of
> other issues which are slightly annoying:
>
> a) with the attached patch, dbus itself no longer requires a postinst to
> be run at boot time. Which is cool. Unfortunately, inheriting useradd
> causes it to now depend on shadow (which wasn't previously in my image)
> and shadow itself isn't currently amenable to read-only-rootfs either so
> my image build still fails. I guess the answer to this is to have
> shadow excluded (by some or other mechanism) during rootfs construction
> for non-package-management-enabled images.
What is it depending on for the target? Is the shadow-utils or something now
required? That doesn't seem to make sense to me -- other then we need a
passwd/group/shadow/gshadow file to work with. As long as something can provide
those, we should be ok.
> b) the useradd.bbclass stuff seems to try to apply itself to
> virtclass-native packages as well, which was causing an error during
> do_install() for dbus-native. I worked around this by adding
>
> USERADD_PARAM_${PN}_virtclass-native = ""
> GROUPADD_PARAM_${PN}_virtclass-native = ""
Yup, definitely a bug and should be fixed. native and cross cases should not do
anything with useradd.
--Mark
> to the recipe, but it seems as though the class should probably be
> sorting this out for itself.
>
> p.
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
More information about the Openembedded-core
mailing list