[PATCH] util-linux: make alternatives for rev and ionice work with busybox

[PATCH] util-linux: make alternatives for rev and ionice work with busybox

[Pascal Bach]

Busybox can provide ionice and rev. They are both installed to /bin
The corresponding util-linux variant is installed to /usr/bin

This causes the following error during the do_rootfs task:

> update-alternatives: renaming ionice link from /bin/ionice to /usr/bin/ionice
> mv: cannot stat '/bin/ionice': No such file or directory

Moving the util-linux binaries to /bin avoids this error.

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
---
 meta/recipes-core/util-linux/util-linux.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index a05c1cabbe..b018b1365c 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -158,7 +158,7 @@ do_install () {
 
         sbinprogs="agetty ctrlaltdel cfdisk vipw vigr"
         sbinprogs_a="pivot_root hwclock mkswap mkfs.minix fsck.minix losetup swapon swapoff fdisk fsck blkid blockdev fstrim sulogin switch_root nologin"
-        binprogs_a="dmesg getopt kill more umount mount login su mountpoint"
+        binprogs_a="dmesg getopt kill more umount mount login su mountpoint ionice rev"
 
         if [ "${base_sbindir}" != "${sbindir}" ]; then
         	mkdir -p ${D}${base_sbindir}
@@ -221,7 +221,7 @@ ALTERNATIVE_LINK_NAME[pivot_root] = "${base_sbindir}/pivot_root"
 ALTERNATIVE_LINK_NAME[cal] = "${bindir}/cal"
 ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
 ALTERNATIVE_LINK_NAME[fallocate] = "${bindir}/fallocate"
-ALTERNATIVE_LINK_NAME[rev] = "${bindir}/rev"
+ALTERNATIVE_LINK_NAME[rev] = "${base_bindir}/rev"
 ALTERNATIVE_LINK_NAME[fsfreeze] = "${sbindir}/fsfreeze"
 ALTERNATIVE_LINK_NAME[nologin] = "${base_sbindir}/nologin"
 
@@ -296,7 +296,7 @@ ALTERNATIVE_util-linux-unshare = "unshare"
 ALTERNATIVE_LINK_NAME[unshare] = "${bindir}/unshare"
 
 ALTERNATIVE_util-linux-ionice = "ionice"
-ALTERNATIVE_LINK_NAME[ionice] = "${bindir}/ionice"
+ALTERNATIVE_LINK_NAME[ionice] = "${base_bindir}/ionice"
 
 ALTERNATIVE_util-linux-switch-root = "switch_root"
 ALTERNATIVE_LINK_NAME[switch_root] = "${base_sbindir}/switch_root"
-- 
2.11.0

Re: [PATCH] util-linux: make alternatives for rev and ionice work with busybox

[Burton, Ross]

On Thu, 8 Nov 2018 at 10:58, Pascal Bach <pascal.bach@siemens.com> wrote:
> Busybox can provide ionice and rev. They are both installed to /bin
> The corresponding util-linux variant is installed to /usr/bin
>
> This causes the following error during the do_rootfs task:
>
> > update-alternatives: renaming ionice link from /bin/ionice to /usr/bin/ionice
> > mv: cannot stat '/bin/ionice': No such file or directory
>
> Moving the util-linux binaries to /bin avoids this error.

Isn't it simpler to just set ALTERNATIVE_LINK_NAME[ionice] =
"${base_bindir}/ionice" (so the system knows to use the same symlink
for this and busybox) instead of actually moving the binary too?

Ross

Re: [PATCH] util-linux: make alternatives for rev and ionice work with busybox

[Niko Mauno]

On 11/9/18 2:24 AM, Burton, Ross wrote:
> On Thu, 8 Nov 2018 at 10:58, Pascal Bach <pascal.bach@siemens.com> wrote:
>> Busybox can provide ionice and rev. They are both installed to /bin
>> The corresponding util-linux variant is installed to /usr/bin
>>
>> This causes the following error during the do_rootfs task:
>>
>>> update-alternatives: renaming ionice link from /bin/ionice to /usr/bin/ionice
>>> mv: cannot stat '/bin/ionice': No such file or directory
>>
>> Moving the util-linux binaries to /bin avoids this error.
> 
> Isn't it simpler to just set ALTERNATIVE_LINK_NAME[ionice] =
> "${base_bindir}/ionice" (so the system knows to use the same symlink
> for this and busybox) instead of actually moving the binary too?
> 
> Ross
> 

Case being that busybox has ionice and rev under /bin/ whereas 
util-linux under /usr/bin/, I wonder would the prudent course of action 
at this point rather be to revert the 'ionice' and 'rev' specific bits 
that were introduced (along 'cal') in 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/util-linux/util-linux.inc?id=78db831a7b0c2361a266eb37c7cbf2e368d2280a 


-Niko

Re: [PATCH] util-linux: make alternatives for rev and ionice work with busybox

[Niko Mauno]

On 11/9/18 7:36 PM, Niko Mauno wrote:
> On 11/9/18 2:24 AM, Burton, Ross wrote:
>> On Thu, 8 Nov 2018 at 10:58, Pascal Bach <pascal.bach@siemens.com> wrote:
>>> Busybox can provide ionice and rev. They are both installed to /bin
>>> The corresponding util-linux variant is installed to /usr/bin
>>>
>>> This causes the following error during the do_rootfs task:
>>>
>>>> update-alternatives: renaming ionice link from /bin/ionice to 
>>>> /usr/bin/ionice
>>>> mv: cannot stat '/bin/ionice': No such file or directory
>>>
>>> Moving the util-linux binaries to /bin avoids this error.
>>
>> Isn't it simpler to just set ALTERNATIVE_LINK_NAME[ionice] =
>> "${base_bindir}/ionice" (so the system knows to use the same symlink
>> for this and busybox) instead of actually moving the binary too?
>>
>> Ross
>>
> 
> Case being that busybox has ionice and rev under /bin/ whereas 
> util-linux under /usr/bin/, I wonder would the prudent course of action 
> at this point rather be to revert the 'ionice' and 'rev' specific bits 
> that were introduced (along 'cal') in 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/util-linux/util-linux.inc?id=78db831a7b0c2361a266eb37c7cbf2e368d2280a 
> 
> 
> -Niko

I believe I've pinpointed this issue to https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/commit/?id=fcb26339000021eb9bb711aa264247aebcfdd4ae which added link relocation support to update-alternatives script (it used to error outright in case the new symlink source differed from old one, which deviated from Debian's update-alternatives behaviour). However in the added implementation, handling of case where target rootfs root directory did not match host rootfs root directory (such as in Yocto do_rootfs context) the 'mv' call tried to relocate the symlink on host rootfs rather than target rootfs resulting in 'cannot stat' error.

I submitted a patch a moment ago to opkg-utils upstream, as well as oe-core patch to opkg-utils recipe (just in case the former takes time to propagate to Yocto):
https://lists.yoctoproject.org/pipermail/yocto/2018-November/043249.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-November/275959.html

-Niko