busybox & update-alternatives

busybox & update-alternatives

[Gary Thomas]

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?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: busybox & update-alternatives

[Tom Rini]

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).

-- 
Tom Rini
Mentor Graphics Corporation

Re: busybox & update-alternatives

[Gary Thomas]

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@windriver.com>
   Date:   Thu Feb 3 19:29:50 2011 -0600

Mark, any comments?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: busybox & update-alternatives

[Mark Hatle]

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@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?

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

--Mark

Re: busybox & update-alternatives

[Mark Hatle]

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@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..

--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.)
> 
> --Mark
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

Re: busybox & update-alternatives

[Koen Kooi]

Op 11 feb 2011, om 19:37 heeft Mark Hatle het volgende geschreven:

> 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@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..

If you use update-rc.bbclass, yes. But that class is only a few lines, easy enough to copy it into the recipe and do multiple initscripts. There are a number of recipes in OE doing that.

regards,

Koen

Re: busybox & update-alternatives

[Gary Thomas]

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

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@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
------------------------------------------------------------

[-- Attachment #2: update.patch --]
[-- Type: text/plain, Size: 736 bytes --]

diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 7e4dda7..3647cb4 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -15,17 +15,23 @@ if test "x$D" != "x"; then
 else
 	OPT="-s"
 fi
-update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
+for i in ${INITSCRIPT_NAME}; do
+  update-rc.d $OPT $i ${INITSCRIPT_PARAMS}
+done
 }
 
 updatercd_prerm() {
 if test "x$D" = "x"; then
-	${INIT_D_DIR}/${INITSCRIPT_NAME} stop
+  for i in ${INITSCRIPT_NAME}; do
+	${INIT_D_DIR}/$i stop
+  done
 fi
 }
 
 updatercd_postrm() {
-update-rc.d $D ${INITSCRIPT_NAME} remove
+for i in ${INITSCRIPT_NAME}; do
+  update-rc.d $D $i remove
+done
 }
 
 

Re: busybox & update-alternatives

[Mark Hatle]

On 2/11/11 1:22 PM, Gary Thomas wrote:
> 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@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?

That patch should work fine.  Only concern is if you have multiple initscripts
with different params.. how do you reconcile that.  (Simplest answer for me
would be ${INITSCRIPT_PARAMS_name} --- but I'm guessing that might clash with
the package names and cause other problems.

I'm exploring adding a -sysroot as well as -udhcpc split package.  But so far
I'm not having much success getting the semantics right....

>>
>> --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.)
> 

Re: busybox & update-alternatives

[Gary Thomas]

On 02/11/2011 12:46 PM, Mark Hatle wrote:
> On 2/11/11 1:22 PM, Gary Thomas wrote:
>> 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@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?
>
> That patch should work fine.  Only concern is if you have multiple initscripts
> with different params.. how do you reconcile that.  (Simplest answer for me
> would be ${INITSCRIPT_PARAMS_name} --- but I'm guessing that might clash with
> the package names and cause other problems.
>
> I'm exploring adding a -sysroot as well as -udhcpc split package.  But so far
> I'm not having much success getting the semantics right....

Since you're working on this, I'll leave the final solution to you :-)

I have a [temporary] solution for now.

Thanks

>>>
>>> --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
------------------------------------------------------------

Re: busybox & update-alternatives

[Khem Raj]

On (11/02/11 12:30), 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@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?

customize update-rc.d class functionality in recipe

> 
> (If specifying more then one initscript is correct in the recipe, then the bug
> is in a class wherever update-rc.d is called.)
> 
> --Mark
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky