[Guide] Futurebit Apollo BTC Custom Linux Install - Base

[n0nce]

2) There are still software vulnerabilities involved when following the instructions.

Just wondering, which software has vulnerabilities if we're following n0nce guide? AFAIK there aren't any CVE recently discovered on Bitcoin Core or Core Lightning, while Armbian is actively developed (since the latest version is 22.11).

Maybe he meant that 'stock Futurebit OS' has some security issues. So in 'following the instructions' the 'instructions' could be the official Futurebit instructions.
There's something to that; apt updates still seem to break the kernel modifications that they have in place to connect to the hashboard. Maybe they also just break the device tree. At least that's the only thing I needed to get the hashboard recognized in stock Armbian.

Therefore, users of Futurebit OS are advised not to update; potentially running outdated and insecure packages. This can be resolved by following my guide, which installs everything on its latest version through apt.

Sorry to cause confusion and maybe concern for some readers. My fault for not really fully understanding the instructions, no doubt.

The stuff I picked up as potentially concerning was this: https://bitcointalk.org/index.php?topic=5401730.msg60310493#msg60310493

Attention: As of now, you need to actually get the apolloapi repo instead, since it handles the authentication to the web UI. Also the project(s) require a very old, potentially insecure version of NodeJS; namely NodeJS 9.x - use at your own risk. Do note that you can mine and run your nodes without any web UI at all..

I don't really know what that means, but I figured you highlighted it in red for some reason.

In short; the dashboard might not work. But it's not really required to run Bitcoin Core and mine. I didn't need it, myself at least. No security risks here, though.

The other one is this: https://bitcointalk.org/index.php?topic=5401730.msg60310485#msg60310485

[5] Download the DTS file that comes with the 'Apollo OS'. Yes, this is a binary file I'm providing, but the apollo miner binary is, too, and I'm trying to figure out a better way for this as we speak.

With this one I am even more uncertain if I understand it correctly.
What I thought (while reading the instructions diagonally) this sentence means is this:

'This is a binary file' = no-one can tell what is in it, i.e. no source code provided and therefore we have to trust n0nce and/or jstefanop that the content is not malicious.
I probably misunderstood that one completely, my apologies, I'm not trying to accuse anyone of bad intentions. 

No, that's correct! DTB files are just device trees, though. But I'd prefer to provide just a diff between stock Armbian and the Futurebit DTS (device tree specification), such that it can be applied to any future stock Armbian DTS.
You can decompile the DTB to DTS and read that, they're huge files though and I didn't manually check it, just extracted from Futurebit OS release. So I can't say for certain whether they can (or are) problematic. I highly doubt that, but still wanted to add this disclaimer just in case.

[MrMik]

I just don't see why you would want to do that, if using this one simple step you can save around 50 bucks in cables and power supplies.

Put that way, it makes sense!

But do I not need the extra power supply to power up the Orange Pi in order to install the GPIO setup?

I can put Armbian on the SD card, but 'teaching' it to communicate through that cable to the ASIC board in the Apollo requires that the Orange Pi OS is up and running.

Or will it be powered automatically, just by by virtue of being plugged into that cable, and the GPIO setup just 'teaches' it how to communicate with the ASIC board?

[n0nce]

But do I not need the extra power supply to power up the Orange Pi in order to install the GPIO setup?

No, no, power always works through GPIO; just the OS needs to learn to communicate over other GPIO pins to the board.

Or will it be powered automatically, just by by virtue of being plugged into that cable, and the GPIO setup just 'teaches' it how to communicate with the ASIC board?

Exactly, that's perfectly right.

[MrMik]

No, that's correct! DTB files are just device trees, though. But I'd prefer to provide just a diff between stock Armbian and the Futurebit DTS (device tree specification), such that it can be applied to any future stock Armbian DTS.
You can decompile the DTB to DTS and read that, they're huge files though and I didn't manually check it, just extracted from Futurebit OS release. So I can't say for certain whether they can (or are) problematic. I highly doubt that, but still wanted to add this disclaimer just in case.

I followed instructions here https://michlstechblog.info/blog/linux-decompile-show-a-device-tree-binary-file-dtb/ and am able to read the resulting .dts file.

But, understanding it is a different matter!

Seems to me that the .dtb file only runs once at bootup, but I'm clueless.

However. in the spirit of 'Don't trust, verify' I read through the whole thing and I tried to search for something giving me a hint as to which part of the code is the part needed for the Apollo. I suppose somewhere in the long file are the instructions for how to communicate with the ASIC hashboard.

Do we know the exact ASIC chips name, or something else that could help search for the Apollo related part of the code?

[n0nce]

Do we know the exact ASIC chips name, or something else that could help search for the Apollo related part of the code?

I would take the stock DTB file from your Armbian install, get the DTS from that and diff it, however if I remember correctly, I've already done that and the diff was also huge. Probably since my Armbian was different from the Armbian they used when they created Futurebit OS.

[MrMik]

Do we know the exact ASIC chips name, or something else that could help search for the Apollo related part of the code?

I would take the stock DTB file from your Armbian install, get the DTS from that and diff it, however if I remember correctly, I've already done that and the diff was also huge. Probably since my Armbian was different from the Armbian they used when they created Futurebit OS.

I was hoping to diff the files somehow, but had no idea how easy that is!

Code:

/tmp$ diff tm2p.dts tmp.dts
3,4d2
< // I added this !
< 

But where do I find the .dtb file? Have not seached on armbian yet, but a search on Ubuntu does not find any .dtb files except for the ones I have been playing with.

[n0nce]

But where do I find the .dtb file? Have not seached on armbian yet, but a search on Ubuntu does not find any .dtb files except for the ones I have been playing with.

Have a look in /boot/dtb/rockchip directory.
Otherwise, you can do a full system search like this:

Code:

find / -name *.dtb

[MrMik]

Have a look in /boot/dtb/rockchip directory.

Thank you n0nce!

I found it and did the diff, but still none the wiser.

Have to give up at this point and be happy with the fact that I learned lots while trying to do this.

It has to be safer to run armbian OS with maintenance and updates and that dtb file, than running armbian without updates and that dtb file! 

[n0nce]

Have a look in /boot/dtb/rockchip directory.

Thank you n0nce!
I found it and did the diff, but still none the wiser.
Have to give up at this point and be happy with the fact that I learned lots while trying to do this.

You're welcome; that's how I felt, after going down that rabbit hole, too.

It has to be safer to run armbian OS with maintenance and updates and that dtb file, than running armbian without updates and that dtb file! 

Exactly my point.

[MrMik]

Download page: https://www.armbian.com/orange-pi-4/
Direct link: https://redirect.armbian.com/orangepi4/Bullseye_current (Armbian 22.05 Bullseye - May 28, 2022)

Burn on a new microSD card with 16GB or more using dd or BalenaEtcher (https://www.balena.io/etcher/).
The first boot of this microSD will require to plug in a HDMI monitor and a USB keyboard to create an admin (you can use something else, I just assume this name from here on forward) account and set your locale.

Otherwise just update the whole thing and proceed with miner and / or node install guides, linked above.

Code:

sudo apt update && sudo apt upgrade -y

Trying to follow the instructions, I found that I have to follow them very exactly!

I'm only getting some success when using the same armbian version that n0nce used ( Armbian_22.05.4_Orangepi4-lts_bullseye_current_5.15.48.img.xz )

I tried Armbian_22.11.1_Orangepi4_jammy_current_5.15.80_xfce_desktop.img.xz and Armbian_22.08.2_Orangepi4_jammy_current_5.15.69.img.xz  , but neither of them seem to be able to use the WiFi on the Orange Pi4.

For some reason I also cannot get dd to burn a valid image to SD card, but Etcher worked for all attempted versions.

After finding that the later versions of Armbian do not find the WiFi on the Orange Pi4 , I also tried the ubuntu-22.04.1-desktop-amd64.iso , Etcher reported a successful etch onto the SD card (64GB), but no signs of life on the HDMI monitor when I try to boot it.

So I went back to n0nce's instructions and downloaded the exact armbian version that n0nce used, and it does find the WiFi spontaneously during the first boot.

Now it is downloading updates / upgrades....

And I wonder if this particular armbian OS has a GUI? 

So far it's all code gobbledigook, this might be my first foray into GUI-less computing, wish me luck!   

Now it is downloading updates / upgrades....

And I wonder if this particular armbian OS has a GUI? 

So far it's all code gobbledigook, this might be my first foray into GUI-less computing, wish me luck!   

Meanwhile, the Apollo ASIC board is hashing away happily.

I disconnected the Orange Pi 4 from the ASICs and powered it up using some gear I found within arm's reach.....

I knew this dumb power supply would come in handy one day:  https://www.bunnings.com.au/ryobi-one-18v-usb-power-adapter-skin-only_p6210800
It has a 2.1A and a 1A 5V USB outlet and so far, things seem to work with 2.1A.



Looks like the armbian version is indeed CLI interface only. Oh well, finally a reason t get into this!

Maybe the Ryobi power supply is to blame, or something else, but the newly built Armbian_22.05.4_Orangepi4-lts_bullseye_current_5.15.48.img.xz does not show up on the HDMI monitor when I try to reboot it.

But, after connecting the cable between Orange Pi 4 and ASICs, it does boot up and asks for login and password.

So, here I am, the fan is howling although the miner is stone-cold and that command-prompt is blinking at me...

ROTFLMAO

I'm making progress!

[moderator's note: consecutive posts merged]

[n0nce]

Looks like the armbian version is indeed CLI interface only. Oh well, finally a reason t get into this!

I thought it did have a GUI, to be honest.

On https://www.armbian.com/orange-pi-4/ you find all supported versions, like 'Bullseye CLI', 'Bullseye Minimal' (minimalistic GUI without a lot of bloat), and different versions of Jammy with and without graphical desktop.

I'm not sure about your power supply situation; you probably want to have around 15W of power output so the Orange Pi runs stable; worst-case, just connect the hashboard and power it up through the Futurebit enclosure (12V power supply).