Search content
Sort by

Showing 7 of 7 results by MegatronOHMICAVT
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 15/12/2024, 17:15:13 UTC
Hello Apollo noderunners – working on an Apollo BTC issue where the OS is not detecting the NVME SSD. Occurrs on 2.0.5 and 2.0.6.

Tested a couple functioning NVME drives and neither is detected by the system.

Was able to see what seems to be a relevant problem listed during system startup...

Code:
rc.local[1486]: mount: /media/nvme: special device /dev/nvme0n1p1 does not exist. [FAILED] Failure to start /etc/rc.local Compatibility.

Checking systemctl status
Code:
rc.local.service: Failed with result 'exit-code'.

Has anyone encountered this before?
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 24/11/2024, 21:42:58 UTC
You need to format the new 2TB drive with the format command in settings. Don't format your old data drive.  Just to make sure all is good.   I did that with my new drive.  Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive.  takes about 45 mins.  then shutdown, swap and reboot and it should work fine.  THat's my experience.  Keep the 1TB as a backup.  That's what I have.

I did the reindex-chainstate , took longer.  I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate.  Also lack of ram slows the process.    Seems to actually be quicker to start an IBD after a formatted drive and it is quicker.  However, I highly recommend a backup like above.  Once my IBD was complete I copied the drive for a backup.  I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download.  That made recovery quicker in future crashes.  My hardest part was the IBD.  Once done my system is now running much better.  

I have low trust in the reliability of the included microsd card.  The original is possibly a much older 16GB microsd.   I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find.  I flashed it and find it more stable than the included card was.


An unexpected issue occurring upon system startup.

The NVME SSD is not mounting. It's not detected in Disks, or GParted, or command line prompts like -lsblk.

The node will start upon -reindex with the data-dir at /media/nvme/bitcoin, but that data is existing on the SD card. The NVME SSD remains unreachable.

Might this be something to address in BIOS settings?

The SSD itself is in working order and will mount via USB in another Ubuntu laptop.

If you have access to media/nvme/Bitcoin, then you have access to your nvme drive, that is your nvme drive.  You may have to reformat the nvme card within the Apollo GUI.  Wait for the message, completed as it takes some time to format with no indicator its working on it.  The microsd is the main drive for system files.  Please clarify which drive you are talking about.  SD card to me is microsd and no bitcoin data is stored there other than apollo program files.

I had a corrupted chainstate file recently.  My best solution was to delete the chainstate files, which is done by reindex-chainstate anyway, and copy the old chainstate files from my backup from a month ago.  My database files were ok.  the node updated the chainstate and caught up to the current blocks.  I then backed up the nvme with the newest block set.
my node and miner have been running non-stop for 7 days with no errors.

The reformat option in the UI will give me the "success" message and states the node will restart. But it will not start and sync.

The computer does not detect the NVME SSD at all it seems. To further explore this I restarted the system without any NVME connected at all. The machine restarts and when I pass the -reindex command, the location /media/nvme/bitcoin will populate with the correct default files and the node will start and begin to sync. With no SSD attached, I guess I conclude this is going onto the microSD. I've done this with the current Apollo OS and the original OS.

With an adapter, the NVME SSD can be detected on the Apollo and on another linux laptop.

Seems like it could be an internal NVME connector hardware problem in the Apollo. But if anything else comes to mind please advise.
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 21/11/2024, 21:36:57 UTC
You need to format the new 2TB drive with the format command in settings. Don't format your old data drive.  Just to make sure all is good.   I did that with my new drive.  Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive.  takes about 45 mins.  then shutdown, swap and reboot and it should work fine.  THat's my experience.  Keep the 1TB as a backup.  That's what I have.

I did the reindex-chainstate , took longer.  I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate.  Also lack of ram slows the process.    Seems to actually be quicker to start an IBD after a formatted drive and it is quicker.  However, I highly recommend a backup like above.  Once my IBD was complete I copied the drive for a backup.  I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download.  That made recovery quicker in future crashes.  My hardest part was the IBD.  Once done my system is now running much better.  

I have low trust in the reliability of the included microsd card.  The original is possibly a much older 16GB microsd.   I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find.  I flashed it and find it more stable than the included card was.


An unexpected issue occurring upon system startup.

The NVME SSD is not mounting. It's not detected in Disks, or GParted, or command line prompts like -lsblk.

The node will start upon -reindex with the data-dir at /media/nvme/bitcoin, but that data is existing on the SD card. The NVME SSD remains unreachable.

Might this be something to address in BIOS settings?

The SSD itself is in working order and will mount via USB in another Ubuntu laptop.
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 13/11/2024, 20:24:11 UTC
A follow up question about doing IBD and overcoming what seems to be too much stress for the RAM & processor.

I've got a backup NVME with about the first-half of the IBD on it. I would like to see if there's advice on the procedures for starting a node (Apollo BTC installing 2.0.5) by using the backed-up blockchain data.

Its a 2TB NVME drive in the node, with a 1TB NVME connected via USB and a flashed micro SD to install the system.

Questions are things like which folders need to go over and in what order should steps be taken from initial boot. Thank you!
[/quote]

/blocks  &  /chainstate
OK I haven’t done this before but I have been reading about copying the Bitcoin Core blockchain to another system and this is what I plan to do when I receive my Apollo II later this week.
I have a fully synched v22 Bitcoin Core node running on an Ubuntu PC that I’ve been playing with and I will copy it over to the new 2 TB SSD to avoid re-downloading the entire blockchain again, which might take me a week.
Bitcoin is installed on my Ubuntu PC in the home directory in the hidden folder .bitcoin. There are three subfolders within .bitcoin,   /blocks, /chainstate  & /wallets.
/blocks is 699.6 GB
/chainstate is 12.5 GB
I will not be moving over the /wallets folder or the individual files in the .bitcoin folder, files like bitcoin.conf mempool.dat, peers.dat... These are specific to that PC install and I believe the ones on the Apollo II system will already be in place or will be created on statrtup.
So basically I am moving over just two folders under the .bitcoin folder,  /blocks  &  /chainstate. That’s it.
Here’s what I plan to do when I receive the system.
Connect a monitor, keyboard and mouse. Power on and log into the Apollo system with minimum configurations settings. Stop the miner and node if they are running. Use a file manager on the desktop to make sure the file structure is the same on the SSD,  “cd /media/nvme/bitcoin” to look for the blocks and chainstate folders. If they are there then rename them to oldblocks and oldchainstate just to save them for now. Shutdown the system, remove the SSD and put on a USB/pcie adapter into my Ubuntu PC. I will put a fan blowing on the SSD during this copy as this will probably be the most work this SSD will ever experience, copying 700+ GB to it in one go. Obviously the Bitcoin Core node will not be running on my PC to ensure the files are all closed properly. After a successful copy, shutdown the PC, move the SSD back over to the Apollo II system and power it on and complete the setup.

I think it will work. Maybe someone else can chime in if this process looks reasonable or if I’ve left something out. Hope this helps. Good luck mining...

[/quote]

Thanks for this. Its what I'll be attempting. Except I'll have the drives connected to the Apollo rather than a different PC.
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 13/11/2024, 15:51:05 UTC
You need to format the new 2TB drive with the format command in settings. Don't format your old data drive.  Just to make sure all is good.   I did that with my new drive.  Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive.  takes about 45 mins.  then shutdown, swap and reboot and it should work fine.  THat's my experience.  Keep the 1TB as a backup.  That's what I have.

I did the reindex-chainstate , took longer.  I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate.  Also lack of ram slows the process.    Seems to actually be quicker to start an IBD after a formatted drive and it is quicker.  However, I highly recommend a backup like above.  Once my IBD was complete I copied the drive for a backup.  I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download.  That made recovery quicker in future crashes.  My hardest part was the IBD.  Once done my system is now running much better.  

I have low trust in the reliability of the included microsd card.  The original is possibly a much older 16GB microsd.   I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find.  I flashed it and find it more stable than the included card was.



A follow up question about doing IBD and overcoming what seems to be too much stress for the RAM & processor.

I've got a backup NVME with about the first-half of the IBD on it. I would like to see if there's advice on the procedures for starting a node (Apollo BTC installing 2.0.5) by using the backed-up blockchain data.

Its a 2TB NVME drive in the node, with a 1TB NVME connected via USB and a flashed micro SD to install the system.

Questions are things like which folders need to go over and in what order should steps be taken from initial boot. Thank you!
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 04/11/2024, 21:22:19 UTC
Aha this may work. Lets see, its processing.

screen -dmS node /opt/apolloapi/backend/node/bitcoind -reindex -datadir=/media/nvme/Bitcoin -conf=/opt/apolloapi/backend/node/bitcoin.conf


Yep, next release has a "Reindex node" option before the formate node drive as away to recover the node database without going to the extreme of wiping the drive in case of hard shutdowns etc



Hi fellow Apollo node-runners. Long time follower here with a first time question, possibly on this issue above.

Updating my Apollo BTC MCU2 unit to a 2TB nvme, and also updating to 2.0.5.

Node stops sync and refuses connection, alerting disk space full. Log shown below.

The nvme drive isn't showing up when checking lsblk in command line, but the drive is functioning when the node connects, at least initially.

The -reindex command will allow node to reconnect. And also re-flashed, confirming checksum. But it will refuse connection shortly after all of this.

Would -reindex-chainstate command make a difference here? Maybe the micro SD is damaged in some way?

Please advise if anything looks familiar.

Code:
2024-11-02T02:47:19Z UpdateTip: new best=0000000000000000cfef544b24af88f6552deaea28be61cf96b10d5ccefb576c height=286202 version=0x00000002 log2_work=76.626933 tx=33033093 date='2014-02-16T15:44:31Z' progress=0.032903 cache=434.2MiB(3180596txo)
2024-11-02T02:47:19Z *** Disk space is too low!
2024-11-02T02:47:19Z Error: Disk space is too low!
2024-11-02T02:47:19Z ERROR: SaveBlockToDisk: FindBlockPos failed
2024-11-02T02:47:19Z ERROR: ProcessNewBlock: AcceptBlock FAILED (AcceptBlock: Failed to find position to write new block to disk)
2024-11-02T02:47:19Z tor: Thread interrupt
2024-11-02T02:47:19Z Shutdown: In progress...
2024-11-02T02:47:19Z opencon thread exit
2024-11-02T02:47:19Z torcontrol thread exit
2024-11-02T02:47:19Z addcon thread exit
2024-11-02T02:47:19Z net thread exit
2024-11-02T02:47:19Z UPNP_DeletePortMapping() returned: 0
2024-11-02T02:47:19Z mapport thread exit
2024-11-02T02:47:19Z UpdateTip: new best=0000000000000000860990bd046f2d7635cefc0519aaef94c3251a448e4df5e2 height=286203 version=0x00000002 log2_work=76.627072 tx=33033574 date='2014-02-16T15:49:05Z' progress=0.032904 cache=434.2MiB(3180630txo)
2024-11-02T02:47:19Z msghand thread exit
2024-11-02T02:47:20Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2024-11-02T02:47:21Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.90s)
2024-11-02T02:47:21Z scheduler thread exit
2024-11-02T02:47:21Z Writing 0 unbroadcast transactions to disk.
2024-11-02T02:47:21Z Dumped mempool: 0.00189343s to copy, 0.0098008s to dump
2024-11-02T02:47:21Z Flushed fee estimates to fee_estimates.dat.
2024-11-02T02:48:56Z *** Disk space is too low!
2024-11-02T02:48:56Z Error: Disk space is too low!
2024-11-02T02:48:56Z ForceFlushStateToDisk: failed to flush state (Disk space is too low!)
2024-11-02T02:48:56Z *** Disk space is too low!
2024-11-02T02:48:56Z Error: Disk space is too low!
2024-11-02T02:48:56Z ForceFlushStateToDisk: failed to flush state (Disk space is too low!)
2024-11-02T02:49:03Z Shutdown: done




You need to format the new 2TB drive with the format command in settings. Don't format your old data drive.  Just to make sure all is good.   I did that with my new drive.  Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive.  takes about 45 mins.  then shutdown, swap and reboot and it should work fine.  THat's my experience.  Keep the 1TB as a backup.  That's what I have.

I did the reindex-chainstate , took longer.  I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate.  Also lack of ram slows the process.    Seems to actually be quicker to start an IBD after a formatted drive and it is quicker.  However, I highly recommend a backup like above.  Once my IBD was complete I copied the drive for a backup.  I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download.  That made recovery quicker in future crashes.  My hardest part was the IBD.  Once done my system is now running much better.  

I have low trust in the reliability of the included microsd card.  The original is possibly a much older 16GB microsd.   I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find.  I flashed it and find it more stable than the included card was.

Cool, thank you. Before picking up a USB / pcie adapter I'm trying a cache size increase. That seems to be the size error I keep hitting.
Post
Topic
Board Hardware
Re: Official FutureBit Apollo II/BTC Software/Image and Support thread
by
MegatronOHMICAVT
on 02/11/2024, 18:43:40 UTC
Aha this may work. Lets see, its processing.

screen -dmS node /opt/apolloapi/backend/node/bitcoind -reindex -datadir=/media/nvme/Bitcoin -conf=/opt/apolloapi/backend/node/bitcoin.conf


Yep, next release has a "Reindex node" option before the formate node drive as away to recover the node database without going to the extreme of wiping the drive in case of hard shutdowns etc



Hi fellow Apollo node-runners. Long time follower here with a first time question, possibly on this issue above.

Updating my Apollo BTC MCU2 unit to a 2TB nvme, and also updating to 2.0.5.

Node stops sync and refuses connection, alerting disk space full. Log shown below.

The nvme drive isn't showing up when checking lsblk in command line, but the drive is functioning when the node connects, at least initially.

The -reindex command will allow node to reconnect. And also re-flashed, confirming checksum. But it will refuse connection shortly after all of this.

Would -reindex-chainstate command make a difference here? Maybe the micro SD is damaged in some way?

Please advise if anything looks familiar.

Code:
2024-11-02T02:47:19Z UpdateTip: new best=0000000000000000cfef544b24af88f6552deaea28be61cf96b10d5ccefb576c height=286202 version=0x00000002 log2_work=76.626933 tx=33033093 date='2014-02-16T15:44:31Z' progress=0.032903 cache=434.2MiB(3180596txo)
2024-11-02T02:47:19Z *** Disk space is too low!
2024-11-02T02:47:19Z Error: Disk space is too low!
2024-11-02T02:47:19Z ERROR: SaveBlockToDisk: FindBlockPos failed
2024-11-02T02:47:19Z ERROR: ProcessNewBlock: AcceptBlock FAILED (AcceptBlock: Failed to find position to write new block to disk)
2024-11-02T02:47:19Z tor: Thread interrupt
2024-11-02T02:47:19Z Shutdown: In progress...
2024-11-02T02:47:19Z opencon thread exit
2024-11-02T02:47:19Z torcontrol thread exit
2024-11-02T02:47:19Z addcon thread exit
2024-11-02T02:47:19Z net thread exit
2024-11-02T02:47:19Z UPNP_DeletePortMapping() returned: 0
2024-11-02T02:47:19Z mapport thread exit
2024-11-02T02:47:19Z UpdateTip: new best=0000000000000000860990bd046f2d7635cefc0519aaef94c3251a448e4df5e2 height=286203 version=0x00000002 log2_work=76.627072 tx=33033574 date='2014-02-16T15:49:05Z' progress=0.032904 cache=434.2MiB(3180630txo)
2024-11-02T02:47:19Z msghand thread exit
2024-11-02T02:47:20Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2024-11-02T02:47:21Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.90s)
2024-11-02T02:47:21Z scheduler thread exit
2024-11-02T02:47:21Z Writing 0 unbroadcast transactions to disk.
2024-11-02T02:47:21Z Dumped mempool: 0.00189343s to copy, 0.0098008s to dump
2024-11-02T02:47:21Z Flushed fee estimates to fee_estimates.dat.
2024-11-02T02:48:56Z *** Disk space is too low!
2024-11-02T02:48:56Z Error: Disk space is too low!
2024-11-02T02:48:56Z ForceFlushStateToDisk: failed to flush state (Disk space is too low!)
2024-11-02T02:48:56Z *** Disk space is too low!
2024-11-02T02:48:56Z Error: Disk space is too low!
2024-11-02T02:48:56Z ForceFlushStateToDisk: failed to flush state (Disk space is too low!)
2024-11-02T02:49:03Z Shutdown: done