Scribe Entware coreutils-uname breaks scribe installer

[HTMLSpinnr]

After upgrading to Merlin FW 386.4, the scribe script no longer executes the installer. Because the error screen bails so quickly, users attempting to install via amtm never see the error. I ran through the steps manually to see a warning that the script requires ASUSWRT-Merlin w/ Entware. Knowing I already had the prerequisites, I dug through the script a bit further to see that because 386.4 changes the OS name provided in the uname -o response (now std GNU/Linux vs ASUSWRT-Merlin), this breaks the OS check. Edit: coreutils-uname is to blame. To get around this, I temporarily changed line 52, but the better thing to do would be to account for both if this is an Asus-enforced change rather than an rmerlin change. explicitly call the correct uname to get the expected results.

52c52
< readonly merlin="ASUSWRT-Merlin"
---
> readonly merlin="GNU/Linux"

I can provide the debug tarball if needed. See reply for better fix

 

[HTMLSpinnr]

After engaging rmerlin at http://www.snbforums.com/threads/asuswrt-merlin-386-4-is-now-available.76498/post-733190 - this may be specific to my install. That said, it's also preventable.

Because I have coreutils-uname installed via Entware as /opt/bin/uname, this breaks the Scribe script since there's a difference between the two outputs.

Thus, I'd propose the following fix to get the expected results every time:

54c54
< readonly fwname="$( uname -o )"
---
> readonly fwname="$( /bin/uname -o )"

 

[thelonelycoder]

That is indeed a problem not only for Scribe but for many more scripts. I rely on its output to determine if Asuswrt-Merlin firmware is installed in amtm and Diversion. I have never heard a complaint though in all these years so I'd say that 99.999 percent have not installed that Entware package.

 

[Jack Yaz]

That is indeed a problem not only for Scribe but for many more scripts. I rely on its output to determine if Asuswrt-Merlin firmware is installed in amtm and Diversion. I have never heard a complaint though in all these years so I'd say that 99.999 percent have not installed that Entware package.

Agreed. What's the benefit of the Entware version of uname anyway? @HTMLSpinnr

 

[thelonelycoder]

The two have about the same options, might be that the /opt version has a specific feature:

tlc@RT-AC86U-AD60:/tmp/home/root# /bin/uname --help
BusyBox v1.25.1 (2021-12-28 16:10:32 EST) multi-call binary.

Usage: uname [-amnrspvio]

Print system information

    -a    Print all
    -m    The machine (hardware) type
    -n    Hostname
    -r    Kernel release
    -s    Kernel name (default)
    -p    Processor type
    -v    Kernel version
    -i    The hardware platform
    -o    OS name
tlc@RT-AC86U-AD60:/tmp/home/root# opkg install coreutils-uname
Installing coreutils-uname (8.32-6) to root...
Downloading https://bin.entware.net/aarch64-k3.10/coreutils-uname_8.32-6_aarch64-3.10.ipk
Configuring coreutils-uname.
tlc@RT-AC86U-AD60:/tmp/home/root# /opt/bin/uname --help
Usage: /opt/bin/uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

  -a, --all                print all information, in the following order,
                             except omit -p and -i if unknown:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -p, --processor          print the processor type (non-portable)
  -i, --hardware-platform  print the hardware platform (non-portable)
  -o, --operating-system   print the operating system
      --help     display this help and exit
      --version  output version information and exit

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/uname>
or available locally via: info '(coreutils) uname invocation'

 

[thelonelycoder]

@Jack Yaz what's with your profile pic? I keeps changing.

 

[Jack Yaz]

@Jack Yaz what's with your profile pic? I keeps changing.

Is it? I haven't changed it in years!

 

[SomeWhereOverTheRainBow]

Is it? I haven't changed it in years!

there goes jack changing on us again.

 

[thelonelycoder]

Is it? I haven't changed it in years!

Yeah, I see big writing JACK switching between the J and the other. Weird 2022 ‘Rona bug, maybe.

 

[Jack Yaz]

Yeah, I see big writing JACK switching between the J and the other. Weird 2022 ‘Rona bug, maybe.

Well 2022 has already bitten Exchange!

 

[thelonelycoder]

I changed all uname occurrences accordingly in both amtm and Diversion, will be out with the next releases.

 

[Jack Yaz]

Tagging @cmkelley for visibility

 

[elorimer]

I suspect the entware version is either detecting something entware specific or there is another uname environmental variable override in play.

I can follow why entware might provide the utility for routers that don't have it native.

 

[RMerlin]

That is indeed a problem not only for Scribe but for many more scripts. I rely on its output to determine if Asuswrt-Merlin firmware is installed in amtm and Diversion. I have never heard a complaint though in all these years so I'd say that 99.999 percent have not installed that Entware package.

I suspect something is wrong relative to Entware. /opt paths should be at the end of $PATH. Here for some reason I just noticed they are both at the start and the end:

admin@stargate88ax:/tmp/home/root# echo $PATH
/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin

Wouldn't surprise me that it was Broadcom's SDK screwing things up (like they did with the /opt mount point). I would have to check on my end.

In the meantime, it's never a bad idea to hardcode full paths for critical commands. I generally do so (although I occasionally do get lazy there).

 

[thelonelycoder]

In the meantime, it's never a bad idea to hardcode full paths for critical commands. I generally do so (although I occasionally do get lazy there).

It never is until it becomes a problem. See outdated firmware amtm posts.
The released amtm version uses the full path, Diversion will follow.

 

[HTMLSpinnr]

Built-in is a function of busybox, and rmerlin has hardcoded the OS Name into the busybox config as ASUSWRT-Merlin whereas Entware's utilities stick to the more generic/standard GNU/Linux. It's not dependent upon /proc/sys/kernel/ostype (which usually just returns Linux)

Ref: https://github.com/RMerl/asuswrt-me...1/release/src/router/busybox/config_base#L303

Entware's coreutils Makefile doesn't seem to override coreutils behavior when pulling source from GNU at build time, and their busybox version (which I do not have installed) hardcodes as GNU/Linux in its base and arch-specific configs.

Ref: https://github.com/Entware/Entware/...package/utils/busybox/Config-defaults.in#L865

As for $PATH including /opt paths ahead of platform paths, what's the use of installing full binaries for certain tools to supplant Busybox if they're not used by default? That's an Entware doing as well via the entware-opt package. I prefer it so that other utilities I install as overrides are there by default (e.g. top, file, host, etc.).

I'm honestly trying to remember why I installed the GNU uname binary other than installing some other coreutils binaries to get expected vs truncated or non-standard output. The package install timestamps are about 9 months ago. Since I can't remember why and it breaks functionality, I'm going to remove coreutils-uname for now, though as a best practice, I'd still call out using absolute paths if we know there's a possible difference in output.

 

[RMerlin]

As for $PATH including /opt paths ahead of platform paths, what's the use of installing full binaries for certain tools to supplant Busybox if they're not used by default? That's an Entware doing as well via the entware-opt package. I prefer it so that other utilities I install as overrides are there by default (e.g. top, file, host, etc.).

Overriding built-in applets by default will create all kind of compatibility issues, as the firmware relies on established behaviour. Some of these applets (like syslogd) have been customized for the router's own needs. See the current case where scripts are no longer able to properly detect the OS as uname returns a generic answer.

 

[ColinTaylor]

I suspect something is wrong relative to Entware. /opt paths should be at the end of $PATH. Here for some reason I just noticed they are both at the start and the end:

admin@stargate88ax:/tmp/home/root# echo $PATH
/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin

This is by design. The OS default path has /opt entries at the end. When you install Entware, the Entware terminal session* profile (/opt/etc/profile) inserts /opt entries at the beginning of the path.

I assume the reasoning is that if you've deliberately installed an alternate package (e.g. find) you're doing it for a reason and you want it the take precedence. Of course it's the responsibility of the user to be aware of any incompatibilities and adjust their setup accordingly.


* This profile isn't applied to non-interactive tasks.

 

[RMerlin]

This is by design. The OS default path has /opt entries at the end. When you install Entware, the Entware terminal session* profile (/opt/etc/profile) inserts /opt entries at the beginning of the path.

I see that this is indeed done by Entware. I remember having a long debate with one of the Entware devs at the time, who wanted not only to override paths, but also install busybox by default, which would have broken a lot of things firmware-wise.

So that means that from now on, whenever a user reports a weird problem, myself and script developers will have to start asking people to uninstall any unnecessary Entware package if we don't want to be wasting time tracking down a bug in our code when ultimately it's a self-inflicted wound with the end user's environment.

I assume the reasoning is that if you've deliberately installed an alternate package (e.g. find) you're doing it for a reason and you want it the take precedence. Of course it's the responsibility of the user to be aware of any incompatibilities and adjust their setup accordingly.

I don't expect the average user to fully understand the potential impact of installing a package, as they can't be expected to be aware of any compatibility issue they might be causing by overriding an OS-provided component. That user who installed coreutils-uname for instance couldn't have known that scripts relied on the output generated by the built-in version to assess compatibility.

 

[cmkelley]

Tagging @cmkelley for visibility

Thanks Jack. Of course this happens at the END of my 2 week break when I'm going back to work tomorrow. Worse, I never reinstalled Git desktop when I built my new 'puter last year. I think that since it seems to be unique to installing Entware uname, I will fix it, but it may take a couple weeks. I actually want to move away from the cynicastic username on github for personal reasons, but I need to come up with a seamless or semi-seamless way of doing that.