Hi Chen,

1) install image created before this change on target device (which doesn't
include coreutils, wget and is depending on usable busybox)
2) build feeds which include this change
3) run  "opkg update && opkg upgrade" on target device (or equivalent in
your favorite package manager)
4) you'll get unusable (and probably unbootable) system at this point,
because /bin/busybox binary from old busybox version was already removed,
but u-a symlinks to new /bin/busybox.(no)suid weren't created because "sed"
used in u-a doesn't work anymore.

As work around I've used
ln -s /bin/busybox.nosuid /bin/busybox
to make old u-a links happy and able to finish postinst in new busybox
version.

FWIW: having /bin/busybox -> busybox.nosuid sounds like good idea to have
"default" busybox in path for people who're running it directly.

Regards,


On Mon, Jul 1, 2013 at 4:14 AM, ChenQi <qi.c...@windriver.com> wrote:

> On 06/28/2013 07:56 PM, Martin Jansa wrote:
>
>> On Tue, Jun 25, 2013 at 04:37:58PM +0000, g...@git.openembedded.org wrote:
>>
>>> Module: openembedded-core.git
>>> Branch: master
>>> Commit: e5a1442819dfb74e86a6f69da008ba**6908c8bbc7
>>> URL:    http://git.openembedded.org/?**p=openembedded-core.git&a=**
>>> commit;h=**e5a1442819dfb74e86a6f69da008ba**6908c8bbc7<http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=e5a1442819dfb74e86a6f69da008ba6908c8bbc7>
>>>
>>> Author: Chen Qi <qi.c...@windriver.com>
>>> Date:   Mon Jun 17 12:47:20 2013 +0800
>>>
>>> busybox: add the ability to split the busybox binary
>>>
>>> This patch enables us to split the busybox into two binaries, one
>>> containing suid applications, and the other containing nosuid apps.
>>>
>>> Add a variable, BUSYBOX_SPLIT_SUID, to control whether to split the
>>> busybox binary into two parts. We default it to "1" to enable the
>>> splitting, but users could still override it to disable the splitting.
>>> After all, busybox has no internal support for this suid apps splitting,
>>> so there might be users out there who want just one busybox binary.
>>>
>>> The basic idea here is to build the busybox twice, each with the correct
>>> configuration items. We extract the non-app part of the original .config
>>> file, and merge this part with the suid-app part to form a .config which
>>> contains only suid apps. The same strategy applies to the non-suid apps.
>>>
>> Hi,
>>
>> have you tried to do on-device upgrade with this change?
>> It looks very broken, description follows:
>>
>> 13:48:33 < JaMa> was sed applet removed from busybox or something like
>> that? upgrade path seems to be broken
>> 13:48:34 < JaMa> Configuring busybox-syslog.
>> 13:48:34 < JaMa> /usr/bin/update-alternatives: line 186: sed: not found
>> 13:48:58 < JaMa> and then all applets in main busybox package fail to set
>> u-a because of missing sed..
>> 13:49:27 < JaMa> and then fixing that is more complicated because wget
>> symlink is gone too, so opkg update opkg upgrade wont work
>> 13:49:40 < zecke> JaMa: IIRC the specific postinst was removed from
>> busybox?!
>> 13:50:55 < JaMa> /var/lib/opkg/info/busybox.**postinst is still there
>> 13:51:02 < JaMa> with a lot of u-a calls
>> 13:51:34 < zecke> JaMa: generated by the bbclass and not the one that was
>> in the busybox.inc (but i only read the digest and skip stuff)
>> 13:51:37 < JaMa> that commit says it removes redundant u-a
>> 13:52:11 < JaMa> SHR root@gjama ~ $ grep sed /var/lib/opkg/info/busybox.*
>> *postinst   update-alternatives --install /bin/sed sed
>> /bin/busybox.nosuid 50
>> 13:52:23 < zecke> JaMa: Do you know if they/he tested on device upgrade?
>> 13:52:56 < zecke> i am obviously just guessing
>> 13:54:05 < JaMa> all u-a are still pointing to /bin/busybox, but that one
>> is gone replaced by /bin/busybox.(no)suid
>> 13:54:44 < JaMa> we should install /bin/busybox -> /bin/busybox.nosuid to
>> fix upgrade path..
>>
> Hi Martin,
>
> Could you please provide me more information about how to reproduce this
> problem?
>
> Thanks,
> Chen Qi
>
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to