nebraltd / helium-miner-software Goto Github PK

Currently 2/3 containers are testing fine. The current one that is not is gateway-config.

This uses bluetooth to enable onboarding easier. It seems possibly like access to dbus is at fault.

Hotspot is not showing the correct image .

When opening #42 I noticed that the last 2 characters of the MAC address was chopped off.

Fixing #42 might resolve this, but if not needs fixing.

Just an issue to explain the bases used:

hm-miner: Uses image from Helium, based on alpine.
hm-pktfwd: Uses armv5 debian slim base
hm-config: Uses balena armv6 debian buster base, enables use of piwheels for some of the python libraries required. (H3)
hm-diag: Uses armv6 alpine base for small size.
hm-gwmfr: Uses armv5 debian slim base.

At the time of testing, the gateway-config container was 700-900MB in size which is too big, this would roughly take 10-20 minutes on the average internet connection. Plus result in approximately 2-4GB of bandwidth being used per month (2-4 updates a month).

Target is to get between 200-300MB which will take figuring out the exact packages that are required.

Opened the issue as a note-keeping method.

When setting up the Nebra hotspot I am getting the attached message at the final stage to register hotspot. I have tried closing app. Turn off and turn on Bluetooth and repeating and get the same error message at final stage. Tried for 2 days now at different locations and using WiFi and Ethernet same error message . The antenna screw was very loose on receipt of Nebra which I have since tightened with snipe pliers.

My miner randomly goes down. It's still connected and responding to ping on the network, but I can't access any of the ports - not responding to 80 / 44158

It would be really useful to have logs accessible so we can investigate what's happening.

Maybe we could add a link to the diagnostics page and include last xxx lines from each log file?

For some reason the same container pushed to the same balena app is acting up slightly with the bluetooth configuration.

To-Do: Diagnose the cause of this issue, then fix where possible.

Investigate potential to pass the Helium animal name back to balenaCloud...

Since July 24, I have encountered a problem on one of my HS. He can no longer synchronize with blochain. Looking at the network traffic we observe TCP RST packets sent every 2 mins on communications with the blockchain.

19:40:41.318513 IP 18.213.70.164.443 > 192.168.1.51.57740: Flags [R], seq 1386264293, win 0, length 0
19:41:25.450593 IP 108.184.231.203.44237 > 192.168.1.51.44158: Flags [R], seq 4144492829, win 0, length 0
19:41:38.092816 IP 108.184.231.203.44158 > 192.168.1.51.36995: Flags [R], seq 3643933, win 0, length 0
19:41:38.099914 IP 108.184.231.203.44158 > 192.168.1.51.36995: Flags [R], seq 3643933, win 0, length 0
19:41:38.100178 IP 108.184.231.203.44158 > 192.168.1.51.36995: Flags [R], seq 3643933, win 0, length 0
19:41:38.100416 IP 108.184.231.203.44158 > 192.168.1.51.36995: Flags [R], seq 3643933, win 0, length 0
19:41:38.172395 IP 108.184.231.203.44158 > 192.168.1.51.36995: Flags [R], seq 3643933, win 0, length 0
19:41:40.171250 IP 192.168.1.51.36955 > 151.101.122.133.443: Flags [R], seq 212355067, win 0, length 0
19:41:40.171775 IP 192.168.1.51.36955 > 151.101.122.133.443: Flags [R], seq 212355067, win 0, length 0
19:41:45.972294 IP 192.168.1.51.57756 > 18.213.70.164.443: Flags [R], seq 1006029916, win 0, length 0
19:41:45.972348 IP 192.168.1.51.57756 > 18.213.70.164.443: Flags [R], seq 1006029916, win 0, length 0
19:41:46.131787 IP 18.213.70.164.443 > 192.168.1.51.57756: Flags [R], seq 2442953464, win 0, length 0
19:41:46.211746 IP 18.213.70.164.443 > 192.168.1.51.57756: Flags [R], seq 2442953464, win 0, length 0
19:41:49.202580 IP 192.168.1.51.57760 > 18.213.70.164.443: Flags [R], seq 2357592390, win 0, length 0
19:41:49.202886 IP 192.168.1.51.57760 > 18.213.70.164.443: Flags [R], seq 2357592390, win 0, length 0
19:41:49.394012 IP 18.213.70.164.443 > 192.168.1.51.57760: Flags [R], seq 463090684, win 0, length 0
19:41:49.394298 IP 192.168.1.51.57756 > 18.213.70.164.443: Flags [R], seq 1006029916, win 0, length 0
19:42:05.531987 IP 35.166.211.46.2154 > 192.168.1.51.44657: Flags [R.], seq 0, ack 2743434177, win 0, length 0
19:42:34.687733 IP 135.180.198.255.35025 > 192.168.1.51.44158: Flags [R], seq 2373430884, win 0, length 0
19:42:47.005100 IP 192.168.1.51.44158 > 86.91.102.251.1024: Flags [R.], seq 1134265387, ack 137463222, win 504, options [nop,nop,TS val 2888192168 ecr 996753294], length 0
19:42:47.288961 IP 192.168.1.51.45473 > 151.101.122.133.443: Flags [R], seq 262027931, win 0, length 0
19:42:47.289657 IP 192.168.1.51.45473 > 151.101.122.133.443: Flags [R], seq 262027931, win 0, length 0
19:42:50.593900 IP 192.168.1.51.34008 > 151.101.122.133.443: Flags [R], seq 1809348608, win 0, length 0
19:42:50.594064 IP 192.168.1.51.34008 > 151.101.122.133.443: Flags [R], seq 1809348608, win 0, length 0
19:42:53.048972 IP 192.168.1.51.56956 > 52.55.60.119.443: Flags [R], seq 571888323, win 0, length 0
19:42:53.049026 IP 192.168.1.51.56956 > 52.55.60.119.443: Flags [R], seq 571888323, win 0, length 0
19:42:53.209200 IP 52.55.60.119.443 > 192.168.1.51.56956: Flags [R], seq 3503418488, win 0, length 0
19:42:53.289189 IP 52.55.60.119.443 > 192.168.1.51.56956: Flags [R], seq 3503418488, win 0, length 0
19:42:55.889183 IP 192.168.1.51.50338 > 18.208.44.123.443: Flags [R], seq 3310863611, win 0, length 0
19:42:55.889236 IP 192.168.1.51.50338 > 18.208.44.123.443: Flags [R], seq 3310863611, win 0, length 0
19:42:56.168666 IP 18.208.44.123.443 > 192.168.1.51.50338: Flags [R], seq 2148210163, win 0, length 0
19:42:56.168948 IP 18.208.44.123.443 > 192.168.1.51.50338: Flags [R], seq 2148210163, win 0, length 0
19:43:39.044871 IP 72.68.205.101.55970 > 192.168.1.51.44158: Flags [R], seq 1172483127, win 0, length 0
19:43:39.046499 IP 72.68.205.101.55970 > 192.168.1.51.44158: Flags [R], seq 1172483127, win 0, length 0
19:43:58.287642 IP 192.168.1.51.47257 > 151.101.122.133.443: Flags [R], seq 865035366, win 0, length 0
19:43:58.287886 IP 192.168.1.51.47257 > 151.101.122.133.443: Flags [R], seq 865035366, win 0, length 0
19:43:59.006173 IP 72.68.205.101.44158 > 192.168.1.51.44158: Flags [R], seq 4245902699, win 0, length 0
19:44:02.631081 IP 18.208.44.123.443 > 192.168.1.51.50338: Flags [R], seq 2148210163, win 0, length 0
19:44:02.631245 IP 192.168.1.51.57794 > 18.213.70.164.443: Flags [R], seq 505188380, win 0, length 0
19:44:02.796572 IP 18.213.70.164.443 > 192.168.1.51.57794: Flags [R], seq 1701204746, win 0, length 0
19:44:02.870484 IP 18.213.70.164.443 > 192.168.1.51.57794: Flags [R], seq 1701204746, win 0, length 0
19:44:05.974033 IP 52.55.60.119.443 > 192.168.1.51.56978: Flags [R], seq 1866056928, win 0, length 0
19:44:05.974324 IP 52.55.60.119.443 > 192.168.1.51.56978: Flags [R], seq 1866056928, win 0, length 0
19:44:21.285924 IP 54.151.205.188.2154 > 192.168.1.51.32993: Flags [R.], seq 0, ack 1998060058, win 0, length 0
19:44:47.201957 IP 44.238.156.97.43291 > 192.168.1.51.44158: Flags [R], seq 1249905443, win 0, length 0
19:44:57.843679 IP 3.37.164.87.2154 > 192.168.1.51.34207: Flags [R.], seq 2936722932, ack 4107201980, win 481, options [nop,nop,TS val 3904255432 ecr 191775594], length 0
19:45:04.563267 IP 3.37.164.87.2154 > 192.168.1.51.44158: Flags [R.], seq 0, ack 2759823904, win 0, length 0
19:45:10.610853 IP 192.168.1.51.44158 > 188.40.163.0.2154: Flags [R.], seq 1147030392, ack 3931286515, win 501, options [nop,nop,TS val 699544723 ecr 2263122674], length 0
19:45:10.644493 IP 192.168.1.51.44158 > 188.40.163.0.2154: Flags [R], seq 1147030392, win 0, length 0
19:45:10.804476 IP 192.168.1.51.35863 > 151.101.122.133.443: Flags [R], seq 463809976, win 0, length 0
19:45:10.804530 IP 192.168.1.51.35863 > 151.101.122.133.443: Flags [R], seq 463809976, win 0, length 0
19:45:14.403512 IP 192.168.1.51.34046 > 151.101.122.133.443: Flags [R], seq 4001269886, win 0, length 0
19:45:14.403566 IP 192.168.1.51.34046 > 151.101.122.133.443: Flags [R], seq 4001269886, win 0, length 0
19:45:16.727262 IP 192.168.1.51.50370 > 18.208.44.123.443: Flags [R.], seq 2887698630, ack 2217672850, win 501, options [nop,nop,TS val 61455809 ecr 1178922388], length 0
19:45:16.882671 IP 18.208.44.123.443 > 192.168.1.51.50370: Flags [R], seq 2217672850, win 0, length 0
19:45:16.962614 IP 18.208.44.123.443 > 192.168.1.51.50370: Flags [R], seq 2217672850, win 0, length 0
19:45:20.003068 IP 192.168.1.51.56998 > 52.55.60.119.443: Flags [R], seq 2305923495, win 0, length 0
19:45:20.003226 IP 192.168.1.51.56998 > 52.55.60.119.443: Flags [R], seq 2305923495, win 0, length 0
19:45:20.162507 IP 52.55.60.119.443 > 192.168.1.51.56998: Flags [R], seq 2839715076, win 0, length 0
19:45:20.246766 IP 52.55.60.119.443 > 192.168.1.51.56998: Flags [R], seq 2839715076, win 0, length 0
19:45:21.924337 IP 192.168.1.51.44158 > 104.232.122.34.44158: Flags [R.], seq 0, ack 3303437651, win 0, length 0
19:45:35.722503 IP 35.166.211.46.2154 > 192.168.1.51.43177: Flags [R.], seq 0, ack 4082774780, win 0, length 0

Following this observation I obtained the logs from my HS to try to correlate the reset packets and the logs.

We observe in the logs a helium-miner process which is restarted every 2 minutes because there is a problem accessing the file "/var/data/blockchain_swarm/cache.dets".
Extracts from the log:
04.08.21 13:38:54 (+0200) Connecting to helium-assets.nebra.com (172.67.13.199:443)
04.08.21 13:38:54 (+0200) Restarting service 'helium-miner sha256:ce3db3373450d1317bc1d43025cba0dc60424d818de866172a145e2323297f38'
04.08.21 13:38:55 (+0200) saving to '/opt/miner/releases/0.1.0/sys.config'
04.08.21 13:38:55 (+0200)
sys.config           100% |********************************|   657  0:00:00 ETA
04.08.21 13:38:55 (+0200) '/opt/miner/releases/0.1.0/sys.config' saved
04.08.21 13:39:04 (+0200) Exec: /usr/local/lib/erlang/erts-10.7.1/bin/erlexec -noinput +Bd -boot /opt/miner/releases/0.1.0/start -mode embedded -boot_var SYSTEM_LIB_DIR /usr/local/lib/erlang/lib -config /opt/miner/releases/0.1.0/sys.config -args_file /opt/miner/releases/0.1.0/vm.args -- foreground
04.08.21 13:39:04 (+0200) Root: /opt/miner
04.08.21 13:39:04 (+0200) /opt/miner
04.08.21 13:39:14 (+0200) dets: file "/var/data/blockchain_swarm/cache.dets" not properly closed, repairing ...
04.08.21 13:40:09 (+0200) Killed

I shared this log with a helium developer who advises to delete the blockchain_swarm directory. This directory will be rebuilt when the helium reminer service is launched.
There may be a problem with the flash memory.
I sent the workaround via the support but it's been 3 days that I wait for the manipulation to be done on my HS.
Can you generalize a detection of this type of error message and act with the erasure of the directory?

Hey there,

I am not sure if this is the right place to ask for help.
i have this issue - Miner Connected To Blockchain False
My indoor Nebra hot spot EU868 - Joyous Ceramic Stallion is syncing for 9 days since 12.08.21

Sync Percentage 0.00%
Height Status 0 / 975442
Firmware Version 2021.08.16.1
Frequency 868
Region Plan EU868
Variant Nebra Indoor Hotspot Gen 1
Miner Connected To Blockchain False

Miner Relayed False
ECC Detected True
ETH0 MAC xx:xx:xx:xx:C9:F7
WLAN0 MAC xx:xx:xx:xx:7D:B1
Raspberry Pi Serial 00000000ff52xxxx
Bluetooth Detected True
LoRa Operational True

Can you help please

Might be useful to have a semantic versioning / automatic changelog or something at some point. Not super urgent, but could be useful IMO

I have noticed some devices getting stuck whilst trying to update due to an update lock being applied in /tmp/balena/updates.lock

On occasion I have seen devices stuck in this state for at least a few hours. The only way to seemingly fix it is a forced reboot.

However, what is not clear, is where the lockfile is coming from? As I can't see any code in our codebase that would be applying one. So presumably it is something to do with the balena supervisor?

Ref: https://www.balena.io/docs/learn/deploy/release-strategy/update-locking/

Either test, or re-test to confirm the following modules work.

Table now on wiki page

Main-Vinyl-Jellyfish came online and synced, made some rewards, then suddenly went offline from Aug 9 until now.
Local Diagnostics says Miner Connected To Blockchain False.
Remote Dashboard says Connected To Helium Network: No.
I removed the Wi-Fi and Bluetooth USB adapters and connected the hotspot via Ethernet cable only.
Port forwarding setup on the host router/firewall and I confirmed it is working.
Dashboard sync percentage keeps dropping.
Installed indoors at 22C.
Removed the lid to prevent overheating of CPU on Aug 12.
Filed support ticket #264836 and #265387 with no response from Nebra support.

Local Diagnostics:
Sync Percentage 0.0%
Height Status 0 / 970400
Firmware Version 2021.08.16.1
Frequency 915
Region Plan US915
Variant Nebra Indoor Hotspot Gen 1
Miner Connected To Blockchain False
Miner Relayed False
ECC Detected True
ETH0 MAC xx:xx:xx:xx:4C:66
WLAN0 MAC None
Raspberry Pi Serial 00000000f57bxxxx
Bluetooth Detected False
LoRa Operational True
Modem Detected False

Remote Dashboard:
Connected To Helium Network: No
Blockchain Sync Status: 98.73%

Connected To Update Server: Yes
Model: Nebra Indoor Hotspot Gen 1
IP Address: 192.168.1.100
CPU Usage: ~86%
CPU Temperature: ~62C
Memory Usage: 356 / 962 MB
Storage Usage: 5.7 / 27.8 GB

I forgot to implement getting the IP Address for the miner.

In order to better support multiple hardwares, we ideally need balena hostapps to be available to us.

Otherwise, for every hardware variant we will need a custom machine type on balena to pull in the dbus config file

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <policy user="root">
    <allow own="com.helium.Miner"/>
    <allow send_interface="com.helium.Miner"/>
  </policy>
  <policy context="default">
     <allow send_destination="com.helium.Miner"/>
  </policy>
</busconfig>

Ref: https://github.com/helium/miner/blob/master/config/com.helium.Miner.conf

This needs to be placed on the host os at /etc/dbus-1/system.d as has been done here for the nebra-hnt device type on balena https://github.com/balena-os/balena-raspberrypi/blob/master/layers/meta-balena-raspberrypi/recipes-core/dbus/dbus_%25.bbappend

Currently, we have to manually add this for different devices types by removing read only from filesystem and adding the file in https://forums.balena.io/t/i-want-to-edit-host-os-read-only-files/21266

Hi, I would appreciate Nebra to support IPv6 as I have public IPv6 (and I'm behind 2x NAT at IPv4). It may solve some issues with connection I guess. Thank you!
Many thanks!

We need to document the process of performing factory resets for customers.

Change config and packetforwarder to handle multiple vendors.

EDIT: Status update:

• packet forwarder (works with multiple vendors, but may need to handle different configs)
  • handle different global_conf.json for different vendors (rssi_offset settings etc)
  • NebraLtd/hm-pktfwd#32
• config
  • NebraLtd/hm-config#56
  • NebraLtd/hm-config#57
• diagnostics
  • NebraLtd/hm-diag#96
• balena hostapps / dbus config
  • #105

On dynamic IP connections, where public external IP likes to change multiple times per day, the miner doesn't checks for the real external IP.

That leads to the wrong IP being reported to the blockchain and eventually relayed connection. Rebooting the miner is a workaround as it then updates the chain with the new current IP and is no longer relayed.

Simple workaround is to add periodic check for external public IP and update the chain when necessary. Something like dynamic dns updaters do.

I have a hotspot that randomly drops the network connection on Ethernet.

A customer has had the Wi-Fi BT GATT Request issue on a Pixel 5.

I believe this was fixed however requires some more investigation as it's happening again.

It did work for the customer on a Pixel 4.

Gateway-config looks for the MAC address of the host, however being inside a container the commands it uses doesn't work.

I had 2 Nebra indoor hotspots updated and ready to ship to hosts locations tomorrow.

there was a software update so I decided to plug them in here and let them update but both now result in the following error on the diag page.

'Miner Is Still Loading'

Any ideas please?

I've noticed on a few support tickets people having issues with WiFi when they have both WiFi and Ethernet connected.

I wonder if this is a wider issue as I've seen at least 3 or 4 with similar issue. Not got any conclusive evidence to confirm it, was just anecdotal but thought worth mentioning

Move the miner diagnostics processing code to the diagnostics container, that way we can show the same data on the diagnostics page and then in the config speed it up by presenting the cached copy.

I have
rasberry pi 4 2gb or more ram
64 gig memory card

Unsure if i need
LoRa concentrator from rakk?
packet forwarder (LoRa esp development board?) or will the rasberry pi be efficient at this
lorawan gateway?

Any input on this would be great, thanks

So your just gonna tell me they allow light hotspots?

There isn't a faster way to grow a network than open sourcing it, when you start a monopoly your in it just for the money; not the actuall network. How in the hell can there be a physical key? Before nebra claimed it was AES.

Someone's full of shit here

Not sure how easy this would be, but for support purposes it would be useful to be able to pass the helium name of a miner (and possibly its blockchain address) back to balenacloud as a tag or something similar.

I believe this is possible using:
https://github.com/balena-io-examples/device-tags

Just putting this here for reference...
https://github.com/balena-os/balena-raspberrypi/blob/master/layers/meta-balena-raspberrypi/recipes-core/dbus/files/com.helium.Miner.conf

com.helium.Miner.conf.txt

Perhaps the wrong repo, but I have not come across any documentation on how the disk image for the miner is built. Please document this somewhere.

 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
    <policy user="root">
        <allow own="net.connman"/>
        <allow send_destination="net.connman"/>
        <allow send_interface="net.connman.Agent"/>
        <allow send_interface="net.connman.Counter"/>
        <allow send_interface="net.connman.Notification"/>
    </policy>
    <policy at_console="true">
        <allow send_destination="net.connman"/>
    </policy>
    <policy context="default">
        <deny send_destination="net.connman"/>
    </policy>
</busconfig>

connman-dbus.conf

From here
https://discord.com/channels/404106811252408320/796070988118360094/854134999880171550

Seems like a NetworkManager bug or configuration error perhaps?

Seems similar to...https://www.raspberrypi.org/forums/viewtopic.php?t=196348&start=25

To disable the MAC address randomization create the file
/etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf

with the content

[connection]
wifi.mac-address-randomization=1
 
[device]
wifi.scan-rand-mac-address=no

On some units the Wi-FI adaptor is going into a state where it disables itself,

Needs investigation.

It appears as some of the Balena Deploy jobs will timeout before finishing when merging to production. Need to investigate if we can either break these apart or increase the timeout.

My setup....
pfsense firewall/router setup with a VLAN for separate traffic for miner. One switch port on the SG-2100 is dedicated to the wired miner connection. No other devices are on this VLAN, wireless, or wired connection. POE injector is supplying power.
Miner is Skinny Blonde Eagle.
I cannot get it out of Relay mode and I believe it is because of the mysterious IP address that shows up about every 1-2 hours.
DHCP is on to hand out IP addresses, 44158 is wide open and verified with external port scan, and protocal flags have all be allowed to pass. the miner is grabbing 172.17.0.2 within the DHCP server of 172.17.0.0/16. I opened up the DHCP pool because I have noticed the other IPs showing. The current mysterious IP is 172.17.0.3, and it is showing up as blocked by the native rules in my firewall. I have added a rule to allow it to pass, and still waiting on the IP to be generated again...

See below for 2 images. first one is showing all the pass rules for firewall on the VLAN.
second one is the mystery IP being blocked. it is the only blocked traffic on the VLAN. and I believe it is the reason I am still in Relay mode with miner,

Anyone else seeing the same in their firewall? I am not sure what to do about it, and worry others are not aware of the situation.

Currently to speed up development I've got all the containers as privileged.

When a bit more complete change to only the specific permissions that are required.

The only one that is most likely to require privileged (or enough permissions that it may as well stay priviliged) is the gateway-config container.

Hey,

Finally have received some of our Nebra miners, but one of them shows the issue "Onboarding key not found". Does anyone know how to resolve this issue?

Cheers.

Either re-validate, or test new adaptors / chipsets in the following list

Relates to NebraLtd/hm-diag#69

Once fix is pulled in NebraLtd/hm-diag#70 we need to bump this diagnostics container here

Initial setup was with WiFi, switched to an Ethernet connection, seem unable to clear WiFi credentials - no amount of "forget this network" using the the App actually stops it connecting via WiFi, device always gets two IP addresses - and its unclear if it always prioritises Ethernet.

@ryanteck Now with NAT'ing being discouraged, maybe we should sideload a UPNP client to set this up? I think a lot of consumer grade routers have uPNP enabled by default. What do you think?

Not a major issue at all, but would be a nice to have to run the code auto via flake. Should be easy to do.

{"Kernel pid terminated",application_controller,"{application_start_failure,miner,{{{badmatch,{error,ecc_response_exec_error}},[{miner_keys,get_public_key,2,[{file,"miner_keys.erl"},{line,155}]},{miner_keys,keys,1,[{file,"miner_keys.erl"},{line,72}]},{miner_sup,init,1,[{file,"miner_sup.erl"},{line,63}]},{supervisor,init,1,[{file,"supervisor.erl"},{line,295}]},{gen_server,init_it,2,[{file,"gen_server.erl"},{line,374}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,342}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,249}]}]},{miner_app,start,[normal,[]]}}}"}

Is it planned to include this optional update?

In order to provide more manufacturing flexibility, it would be good if we can support now secure element chips.

Specifically:

• Runjet rjgt102wdp8
• Maxim Integrated DS28C36Q+T / DS28C36BQ+T
• TFLXTLS ATECC608B
• TPM2.0 chips
• ARM TrustZone

Will also need updates to https://github.com/NebraLtd/hm-miner and https://github.com/NebraLtd/hm-diag and https://github.com/NebraLtd/hm-config and https://github.com/NebraLtd/hm-gwmfr

On one unit the miner seems to be in an infinite loop crashing out.

 helium-miner  Exec: /usr/local/lib/erlang/erts-10.7.1/bin/erlexec -noinput +Bd -boot /opt/miner/releases/0.1.0/start -mode embedded -boot_var SYSTEM_LIB_DIR /usr/local/lib/erlang/lib -config /opt/miner/releases/0.1.0/sys.config -args_file /opt/miner/releases/0.1.0/vm.args -- foreground
 helium-miner  Root: /opt/miner
 helium-miner  /opt/miner
 helium-miner  {"Kernel pid terminated",application_controller,"{application_start_failure,miner,{{shutdown,{failed_to_start_child,miner_critical_sup,{shutdown,{failed_to_start_child,blockchain_sup,{shutdown,{failed_to_start_child,blockchain_swarm,{{badmatch,{error,{shutdown,{failed_to_start_child,libp2p_swarm_auxiliary_sup,{shutdown,{failed_to_start_child,swarm_cache,{{badmatch,{error,{not_a_dets_file,\"/var/data/blockchain_swarm/cache.dets\"}}},[{libp2p_cache,init,1,[{file,\"libp2p_cache.erl\"},{line,78}]},{gen_server,init_it,2,[{file,\"gen_server.erl\"},{line,374}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,342}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,249}]}]}}}}}}},[{blockchain_swarm,init,1,[{file,\"blockchain_swarm.erl\"},{line,94}]},{gen_server,init_it,2,[{file,\"gen_server.erl\"},{line,374}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,342}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,249}]}]}}}}}}},{miner_app,start,[normal,[]]}}}"}
 helium-miner  Kernel pid terminated (application_controller) ({application_start_failure,miner,{{shutdown,{failed_to_start_child,miner_critical_sup,{shutdown,{failed_to_start_child,blockchain_sup,{shutdown,{failed_
 helium-miner  
 helium-miner  Crash dump is being written to: erl_crash.dump...done

Hello guys,
because your support via mail is too slow i am asking you for help here.
Please check ticket 258202
First launch of HS was OK but after few hours it went offline and since that time it is not working, maybe it could be online for some time because i have tried to restart HS many times, but now it seems dead at all. Also green LED turn off.
you asked for many pics of components inside and also for video how LEDs inside working, but no response since that time.
here is link for video:
https://drive.google.com/file/d/1bVVRS_oLp1cDvDRlMD-P8M6MHNxxLa3l/view?usp=sharing

we are solving this issue almost month and i am tired with that...so if this has no solution, please give me the contact person for claim.

thank you

The miner bumping process is a very simple, but currently manual process when Helium tag a new GA at https://quay.io/repository/team-helium/miner?tab=tags

Ideally we should automatically bump this, and pull into our testnet, perform some automated tests and automatically issue a PR to production for review and manual confirmation.

Relates to NebraLtd/hm-miner#4

We're using long git hashes for the tag now. There's really no need for that. Let's switch to short ones.