Wget - BusyBox vs. package wget

Software SW bugs discussion
1

Today’s update from 22. 12. 2016 17:10:08 (4.4.38+1-1-efe609c5e5f25db4116d69128330872c-1) broke wget. I’ve installed package “wget 1.18-1”.

Now, after the update, when I run wget, I get version from BusyBox:

turris-epsilon:~# find / -name wget
/usr/bin/wget
turris-epsilon:~# /usr/bin/wget
BusyBox v1.25.1 (2016-12-19 05:23:39 CET) multi-call binary.

I have to reinstall wget package:

turris-epsilon:~# opkg list-installed | grep wget
wget - 1.18-1
turris-epsilon:~# opkg remove wget
Removing package wget from root...
turris-epsilon:~# opkg list-installed | grep wget
turris-epsilon:~# opkg install wget
Installing wget (1.18-1) to root...
Downloading https://api.turris.cz/openwrt-repo/omnia/packages//packages/wget_1.18-1_mvebu.ipk.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  209k  100  209k    0     0  1697k      0 --:--:-- --:--:-- --:--:-- 1836k
Configuring wget.
turris-epsilon:~# opkg list-installed | grep wget
wget - 1.18-1

And now I can use the wget again…

turris-epsilon:~# find / -name wget
/usr/bin/wget
turris-epsilon:~# /usr/bin/wget --version
GNU Wget 1.18 built on linux-gnu.

Exactly the same happened about one month ago, so it’s probably not just coincidence but a bug in the update process.

1 Like
2

can you cat /etc/updater/auto.lua ? does wget appear in there? anything in that list should be auto-reinstalled on an upgrade. if it isn’t in the list, it won’t be re-installed after an upgrade.

installing via LuCI or opkg should add the package to the list, removing a package takes it out of the list.

3

It’s present in the file and probably was there before too - because I reinstalled wget a month ago because of the same issue. Wget was “formally” installed but probably overwritten by BusyBox.

turris-epsilon:~# cat /etc/updater/auto.lua | grep wget
Install "wget"
4

Same happens with less, the problem is that these packages are made to remove busybox symlinks in postinstall script. If busybox is updated, nothing triggers these postinstall scripts again, and busybox wins as /usr/bin is placed in front of /bin in PATH.

Manual fix:

root@omnia:~# ls -la /bin/less 
-rwxr-xr-x    1 root     root        123028 Nov  7 10:21 /bin/less
root@omnia:~# ls -la /usr/bin/less 
lrwxrwxrwx    1 root     root            17 Dec 22 15:20 /usr/bin/less -> ../../bin/busybox
root@omnia:~# /usr/lib/opkg/info/less.postinst
root@omnia:~# ls -la /usr/bin/less 
ls: /usr/bin/less: No such file or directory
root@omnia:~# ls -la /bin/less 
-rwxr-xr-x    1 root     root        123028 Nov  7 10:21 /bin/less

You can also automate this by calling the postinst after every update:

root@omnia:~# /etc/updater/hook_postupdate/04_hooks.sh
#!/bin/sh
/usr/lib/opkg/info/less.postinst
1 Like
5

Thanks for your help! Do you consider this to be a Omnia’s bug that should be fixed or just my weak knowledge?

6

Out of curiosity, which package provides “less”? I’d rather get rid of the one used in busybox, way too limited.

7

It’s in package less :slight_smile:

8

It’s something what the OpenWRT package management can not handle, not sure if it can be better handled in the updater.sh… Definitely it’s unexpected behavior.