[poky] busybox & update-alternatives

[Gary Thomas]

On 02/11/2011 11:37 AM, Mark Hatle wrote:
> On 2/11/11 12:30 PM, Mark Hatle wrote:
>> On 2/11/11 12:24 PM, Gary Thomas wrote:
>>> On 02/11/2011 10:41 AM, Tom Rini wrote:
>>>> On 02/11/2011 09:53 AM, Gary Thomas wrote:
>>>>> A build for my platform with today's master
>>>>> 49a18f1748d2417958b8e19cdd58c0c79f4fc728
>>>>> shows a new behaviour - many messages like this:
>>>>> update-alternatives: Linking //usr/bin/wc to ../../bin/busybox
>>>>>
>>>>> Questions:
>>>>> * Is this truly new or was it just quiet before?
>>>>> * Can't this be done at image build time? On my little
>>>>> embedded OMAP-L138, it takes nearly 2 minutes to run
>>>>> through this. My root is a ramdisk, so this is a cost
>>>>> I see on _every_ boot.
>>>>> * If it can't be done at build time, can I disable it?
>>>>
>>>> It can be done at build time _except_ for when there's a conflict. I suspect what's going on is that a recent change has introduced a conflict (which is to say, busybox provides
>>>> foo as an alternative and something else also provides it, but isn't registering it as an alternative). If you check the whole boot log (or log.do_rootfs) you can find where the
>>>> conflict is and then do something like http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=902b98f32ffd35661e43382f47226f65528ff1b1 (it's a little more complicated if the
>>>> recipe also does BBCLASSEXTEND, since you don't want to do the move for virtclass-foo).
>>>
>>> Running the postinst script manually, I get this error:
>>>
>>> + update-rc.d -s syslog busybox-udhcpc defaults
>>> usage: update-rc.d [-n] [-f] [-r<root>]<basename>  remove
>>>          update-rc.d [-n] [-r<root>] [-s]<basename>  defaults [NN | sNN kNN]
>>>          update-rc.d [-n] [-r<root>] [-s]<basename>  start|stop NN runlvl [runlvl] [...] .
>>>                   -n: not really
>>>                   -f: force
>>>                   -v: verbose
>>>                   -r: alternate root path (default is /)
>>>                   -s: invoke start methods if appropriate to current runlevel
>>>
>>> Looks like update-rc.d is not being called properly.  This
>>> was introduced by
>>>     commit 427472e980cd6254a5e4ef37209b327e15af259b
>>>     Author: Mark Hatle<mark.hatle at windriver.com>
>>>     Date:   Thu Feb 3 19:29:50 2011 -0600
>>>
>>> Mark, any comments?
>>>
>>
>> The error is coming from the INITSCRIPT_NAME_${PN} change.  However, I don't
>> know how to resolve it.  Where there was previously only one init script, there
>> are now two.  So how do we inform bitbake that there are two initscripts to be
>> processed?
>
> I asked and it appears there is a limitation of one initscript per split
> package.  So as a workaround, I suggest removing the busybox-udhcpc from the
> INITSCRIPTS_NAME_${PN} line..

The attached patch looks like it does the right thing.  Any reason it's not
the way to fix this?

>
> --Mark
>
>> (If specifying more then one initscript is correct in the recipe, then the bug
>> is in a class wherever update-rc.d is called.)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: update.patch
URL: <http://lists.yoctoproject.org/pipermail/poky/attachments/20110211/2f3f2368/attachment.ksh>