Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoinstaller not detecting endianness on MIPS routers #55

Closed
dkisselev opened this issue Jul 13, 2015 · 10 comments

Comments

Projects
None yet
2 participants
@dkisselev
Copy link

commented Jul 13, 2015

I have a TL-MR3040 router running OpenWRT (hw wiki link) that I was trying to get nzbget running on.

The autoinstaller correctly identified the arch as MIPS, but got the endianness wrong, so although it looked like it installed correctly, I was getting 'syntax error' on trying to run it. (looks like the shell was trying to run the binary as a script).

Fiddled around for a while but finding answers for any recent version is difficult (the openwrt opkg only comes with 0.8.0 circa 3 years ago, and the most recent other ipkg around is v11, but information about those is limited too), until I noticed that the supported architectures includes mipsel as well as mipseb.

Ran the installer with --arch=mipseb and everything now works swimmingly.

Not sure if this is something that can be detected by the installer or not, but maybe an extra ote in the docs would be great.

@hugbug

This comment has been minimized.

Copy link
Member

commented Jul 13, 2015

The doc does mention parameter --arch. What extra note do you mean?

The installer should detect endianess. Please post the output of the installer.

@dkisselev

This comment has been minimized.

Copy link
Author

commented Jul 13, 2015

I was under the impression that the installer didn't detect endianness at all, so I meant that a note should be added that users should check that the endianness was detected correctly if they see issues, but it sounds like it's actually a fixable bug so nevermind on that note.

Installer output is pretty standard but it does look like it auto-detected to the wrong arch (mipsel), bug in the detection?

root@white:~# sh ./nzbget-latest-bin-linux.run
Installer for nzbget-15.0
Verifying package...
Checking system...
CPU-Architecture: mipsel
Unpacking...
Configuring...
  Free memory detected: 13 MB
Installation completed

Quick help (from nzbget-directory):
   ./nzbget -s        - start nzbget in console mode
   ./nzbget -D        - start nzbget in daemon mode (in background)
   ./nzbget -C        - connect to background process
   ./nzbget -Q        - stop background process
   ./nzbget -h        - help screen with all commands

Successfully installed into /root/nzbget
Web-interface runs on http://10.5.1.1:6789
For support please visit http://nzbget.net/forum
root@white:~/a#
@hugbug

This comment has been minimized.

Copy link
Member

commented Jul 13, 2015

Please try this command and post its output:

dd if=/bin/sh bs=1 count=6

If the above command doesn't fail try the next (that's one long command):

ENDBYTE=`dd if=/bin/sh bs=1 count=6 2>/dev/null | sed -n 's/ELF.\(.*\)/\1/p'`; \
ENDIAN=unknown; \
if test $ENDBYTE="\x01"; then ENDIAN=little; \
elif test $ENDBYTE="\x02"; then ENDIAN=big; fi; \
echo $ENDIAN

That's the code from the installer detection routine. It should print either big or little.

@hugbug

This comment has been minimized.

Copy link
Member

commented Jul 13, 2015

A little explanation

What the command does is it reads the sixth byte of an executable. This byte is part of EXE header and indicates endianess. The command uses /bin/sh as an EXE which is known to belong to the system.

Either your system doesn't have /bin/sh or the dd-command fails. You system sure has dd, otherwise the installer would fail to extract files. The extract command however doesn't uses "count"-parameter. It's possible that the parameter is not supported by your version of dd. If that's the case I would need to find another way to extract the sixth byte.

@dkisselev

This comment has been minimized.

Copy link
Author

commented Jul 13, 2015

It looks like DD works fine, and the samples above run without crashing, but return little-endian in all cases, when this system is big-endian.

I poked around online and found another possible way of detecting endianness: http://serverfault.com/a/163493 (the last code block/line of code there). It successfully returns 0 on my router (big-endian), and 1 on my Ubuntu x86 machine (little-endian).

echo -n I | hexdump -o | awk '{ print substr($2,6,1); exit}'

All the utilities it uses/needs also seem to be available by default on my heavily stripped down openwrt platform, which suggests that it should work against most if not all standard linux distributions.

@hugbug

This comment has been minimized.

Copy link
Member

commented Jul 13, 2015

Thanks for testing.

I just tested the installer command on my small mipsel device and it doesn't work properly. It's strange because I usually don't ship untested code. I have to figure out what's wrong here. Probably an sh thing because the initial testing was made with bash but I had to downgrade the installer to "sh" because "bash" wasn't available everywhere.

echo -n I | hexdump -o | awk '{ print substr($2,6,1); exit}'

This command in fact brings two new dependencies: hexdump and awk. Your platform seems to be very advanced because my mipsel device doesn't know "hexdump" :) And I don't want to add dependency from "awk" either because there will be a platform where it will not work.

When I was developing the installer I had studied the page you linked and many others. The common problem of all solutions - they add dependencies, which is a bad thing if the script has to work with stripped down busybox versions.

@dkisselev

This comment has been minimized.

Copy link
Author

commented Jul 13, 2015

haha, I stand corrected - I figured that the build that OpenWRT would put out for a 4mb of flash travel router would be about as bare-bones as they get until you get into the really custom stuff.

You're right about dependencies though, I made the assumption that hexdump and awk would be as standard as dd, but it seems not.

I don't think it has to do with the sh binary because I tried the script against /bin/bash, /bin/wget, and /root/newsbin/newzbin and got the same result (and I 100% know at least the newzbin result was wrong because I explicitly told it to compile it the other way)

I'd be happy to test anything you come up with

@hugbug

This comment has been minimized.

Copy link
Member

commented Jul 13, 2015

This one works for me (that's one long line):

ENDBYTE=`dd if=/bin/sh bs=1 count=6 2>/dev/null | sed -n 's/.ELF.\(.*\)/\1/p'`; \
ENDIAN=unknown; \
if test "$ENDBYTE" = $'\001'; then \
    ENDIAN=little; \
elif test "$ENDBYTE" = $'\002'; then \
    ENDIAN=big; \
fi; \
echo $ENDIAN

Can you please test it on your systems?

@hugbug hugbug added the bug label Jul 13, 2015

@hugbug hugbug added this to the v16.0 milestone Jul 13, 2015

@dkisselev

This comment has been minimized.

Copy link
Author

commented Jul 14, 2015

That worked and returned big on my device, great work!

@hugbug

This comment has been minimized.

Copy link
Member

commented Jul 14, 2015

If you would like to perform a full installation test please send me a note to nzbget@gmail.com and I'll send you a fixed installer.

@hugbug hugbug closed this in 15e8a85 Jul 14, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.