Well, less than 30 days and this POS is ded. WTF? Apollo II, 1 TB. Came home and it was off. Won't power back on. Unplugged, let it sit, plugged it back in, nothing. Any ideas?
I wonder if the PSU went out? Should be covered under warranty
Topic: Official FutureBit Apollo BTC Software/Image and Support thread - page 2. (Read 48543 times)
November 18, 2024, 06:37:57 AM
I wonder if the PSU went out? Should be covered under warranty
November 18, 2024, 12:22:27 AM
Well, less than 30 days and this POS is ded. WTF? Apollo II, 1 TB. Came home and it was off. Won't power back on. Unplugged, let it sit, plugged it back in, nothing. Any ideas?
November 17, 2024, 08:22:03 PM
@ Any Apollo II Gurus,
I have a question about what should have been a simple configuration but it stumped me nonetheless . . .
Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .
Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username:) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .
Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?
Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?
Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?
Cheers!
I have a question about what should have been a simple configuration but it stumped me nonetheless . . .
Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .
Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username:
Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?
Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?
Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?
Cheers!
Has anyone come up with any ideas on the above issues? How about you jstefanop? Am I overlooking something simple?
Cheers!
November 17, 2024, 08:11:48 PM
@ Any Apollo II Gurus,
I have a question about what should have been a simple configuration but it stumped me nonetheless . . .
Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .
Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username:) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .
Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?
Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?
Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?
Cheers!
I have a question about what should have been a simple configuration but it stumped me nonetheless . . .
Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .
Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username:
Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?
Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?
Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?
Cheers!
Has anyone come up with any ideas on the above issues? How about you jstefanop? Am I overlooking something simple?
Cheers!
November 16, 2024, 01:34:27 PM
samsung pro plus sdxc 128gb was on sale at the local BB store.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.
I picked up the same micro card mentioned. Thursday. I have a PC with two SD card slots. What program did you use to clone the old card to the new please?
follow the futurebit instructions online.
https://www.futurebit.io/flashing-sd-card
It went smooth sailing!! I made sure to back up the sittings first. After flashing the new microSD card to the firmware and changing it, I just restored the settings and a few minutes later was back up to 32/32 connections.
November 16, 2024, 06:41:59 AM
Can you check the node on bitnodes.io? I tried every address config I could think of, and it keeps saying not a valid address?
edit: I got it and it shows up
It's strange as I can not access bitnodes.io from my network that I am running the apollo node on. I get a not authorize with my IP address. So i had to use my cell phone with the wifi turned off and enter my IP address (the ID not authorized) and it says my futurebit apollo node is found and working.
edit: I got it and it shows up
It's strange as I can not access bitnodes.io from my network that I am running the apollo node on. I get a not authorize with my IP address. So i had to use my cell phone with the wifi turned off and enter my IP address (the ID not authorized) and it says my futurebit apollo node is found and working.
November 15, 2024, 10:42:41 PM
Good day all
I am some what a newbie in this field and would like proper steps to take ie solo mine with Apollo 2 full node.I've had the Apollo 2 since its first batch released.The various times my node stops running with a note to direct the Apollo to a solo mine pool hence my confusion isn't the unit a full node solo mine setup guide never directed me to connect to a solo pool the forum is very explanatory for pool mines but for Apollo 2 full node solo miners kind feel like I am hanging out to dry.Most times I have reboot it may continue to solo mine but most of the time I have to reformat the node all this began when I naively updated to v2.0.5 this node situation occurs every 5-6 days and the system disk usage is at 13/14 gb practically full any help would be greatly appreciated.
I am some what a newbie in this field and would like proper steps to take ie solo mine with Apollo 2 full node.I've had the Apollo 2 since its first batch released.The various times my node stops running with a note to direct the Apollo to a solo mine pool hence my confusion isn't the unit a full node solo mine setup guide never directed me to connect to a solo pool the forum is very explanatory for pool mines but for Apollo 2 full node solo miners kind feel like I am hanging out to dry.Most times I have reboot it may continue to solo mine but most of the time I have to reformat the node all this began when I naively updated to v2.0.5 this node situation occurs every 5-6 days and the system disk usage is at 13/14 gb practically full any help would be greatly appreciated.
November 15, 2024, 02:35:50 PM
RE: stuck blocks
Have you checked your debug.log in the bitcoin directory and are there error messages or is it finding and counting blocks? There is a real time counter of events in UTC that should have reports at least every 30 seconds.
is your bitcoind daemon running If its not then it crashed for some reason.
RE : crashing node
My experience from receipt of an apollo II is to make sure you have a fresh formatted pcie memory card. Once the node gets running close all non essential browsers and stop mining. They say you can mine in eco mode but I had more bitcoind crashes with the miner running than not.
I also replaced the microsd supplied with a new card and flashed The supplied microsd card seemed to be less stable than a new faster card
The flaw is the raspberry PI base that this system is built on from research in other forums on the rapsberry pi running nodes. The system is very sensitive.
I monitor the node remotely as it only requests core data that does not load the CPU and memory of the raspberry PI.
the IBD(Initial Blockchain Download) consumes a lot of CPU usage and the bitcoind is sensitive to timing and other apps consuming memory or processor time seems to crash the bitcoind program more often in my case.
Once the IDB is complete(make a backup of your bitcoin database to a second drive), my node v2.0.5 is rather stable and solo mining in normal mode works fine.
Also, heat, i turn my apollo sideways hdmi pointed up. for better airflow and my fan speed drops. It needs a regulated ups. any types of power surges in the electric line can crash the node. If that happens it can crash the database in a possible write event.
pay attention to the debug.log after any system pause. That's your key to what happened. Sometimes when it just drops off you can just restart the node and it continues as expected. If you stop the node half way through IDB and you get a successful stop on the node in the log with no errors you could backup the database to an external usb to pcie memory card to save a point in the download.
every 2 weeks i am backing up my node database to my 2nd drive. you have to stop the node and miner before backing up the data.
Have you checked your debug.log in the bitcoin directory and are there error messages or is it finding and counting blocks? There is a real time counter of events in UTC that should have reports at least every 30 seconds.
is your bitcoind daemon running If its not then it crashed for some reason.
RE : crashing node
My experience from receipt of an apollo II is to make sure you have a fresh formatted pcie memory card. Once the node gets running close all non essential browsers and stop mining. They say you can mine in eco mode but I had more bitcoind crashes with the miner running than not.
I also replaced the microsd supplied with a new card and flashed The supplied microsd card seemed to be less stable than a new faster card
The flaw is the raspberry PI base that this system is built on from research in other forums on the rapsberry pi running nodes. The system is very sensitive.
I monitor the node remotely as it only requests core data that does not load the CPU and memory of the raspberry PI.
the IBD(Initial Blockchain Download) consumes a lot of CPU usage and the bitcoind is sensitive to timing and other apps consuming memory or processor time seems to crash the bitcoind program more often in my case.
Once the IDB is complete(make a backup of your bitcoin database to a second drive), my node v2.0.5 is rather stable and solo mining in normal mode works fine.
Also, heat, i turn my apollo sideways hdmi pointed up. for better airflow and my fan speed drops. It needs a regulated ups. any types of power surges in the electric line can crash the node. If that happens it can crash the database in a possible write event.
pay attention to the debug.log after any system pause. That's your key to what happened. Sometimes when it just drops off you can just restart the node and it continues as expected. If you stop the node half way through IDB and you get a successful stop on the node in the log with no errors you could backup the database to an external usb to pcie memory card to save a point in the download.
every 2 weeks i am backing up my node database to my 2nd drive. you have to stop the node and miner before backing up the data.
Placed mine on its side and temp dropped 2-3 degrees. I guess by blowing the hot air up there is less of a chance for it to get drawn back in. Thanks for the tip!
November 15, 2024, 11:20:42 AM
RE: stuck blocks
Have you checked your debug.log in the bitcoin directory and are there error messages or is it finding and counting blocks? There is a real time counter of events in UTC that should have reports at least every 30 seconds.
is your bitcoind daemon running If its not then it crashed for some reason.
RE : crashing node
My experience from receipt of an apollo II is to make sure you have a fresh formatted pcie memory card. Once the node gets running close all non essential browsers and stop mining. They say you can mine in eco mode but I had more bitcoind crashes with the miner running than not.
I also replaced the microsd supplied with a new card and flashed The supplied microsd card seemed to be less stable than a new faster card
The flaw is the raspberry PI base that this system is built on from research in other forums on the rapsberry pi running nodes. The system is very sensitive.
I monitor the node remotely as it only requests core data that does not load the CPU and memory of the raspberry PI.
the IBD(Initial Blockchain Download) consumes a lot of CPU usage and the bitcoind is sensitive to timing and other apps consuming memory or processor time seems to crash the bitcoind program more often in my case.
Once the IDB is complete(make a backup of your bitcoin database to a second drive), my node v2.0.5 is rather stable and solo mining in normal mode works fine.
Also, heat, i turn my apollo sideways hdmi pointed up. for better airflow and my fan speed drops. It needs a regulated ups. any types of power surges in the electric line can crash the node. If that happens it can crash the database in a possible write event.
pay attention to the debug.log after any system pause. That's your key to what happened. Sometimes when it just drops off you can just restart the node and it continues as expected. If you stop the node half way through IDB and you get a successful stop on the node in the log with no errors you could backup the database to an external usb to pcie memory card to save a point in the download.
every 2 weeks i am backing up my node database to my 2nd drive. you have to stop the node and miner before backing up the data.
Have you checked your debug.log in the bitcoin directory and are there error messages or is it finding and counting blocks? There is a real time counter of events in UTC that should have reports at least every 30 seconds.
is your bitcoind daemon running If its not then it crashed for some reason.
RE : crashing node
My experience from receipt of an apollo II is to make sure you have a fresh formatted pcie memory card. Once the node gets running close all non essential browsers and stop mining. They say you can mine in eco mode but I had more bitcoind crashes with the miner running than not.
I also replaced the microsd supplied with a new card and flashed The supplied microsd card seemed to be less stable than a new faster card
The flaw is the raspberry PI base that this system is built on from research in other forums on the rapsberry pi running nodes. The system is very sensitive.
I monitor the node remotely as it only requests core data that does not load the CPU and memory of the raspberry PI.
the IBD(Initial Blockchain Download) consumes a lot of CPU usage and the bitcoind is sensitive to timing and other apps consuming memory or processor time seems to crash the bitcoind program more often in my case.
Once the IDB is complete(make a backup of your bitcoin database to a second drive), my node v2.0.5 is rather stable and solo mining in normal mode works fine.
Also, heat, i turn my apollo sideways hdmi pointed up. for better airflow and my fan speed drops. It needs a regulated ups. any types of power surges in the electric line can crash the node. If that happens it can crash the database in a possible write event.
pay attention to the debug.log after any system pause. That's your key to what happened. Sometimes when it just drops off you can just restart the node and it continues as expected. If you stop the node half way through IDB and you get a successful stop on the node in the log with no errors you could backup the database to an external usb to pcie memory card to save a point in the download.
every 2 weeks i am backing up my node database to my 2nd drive. you have to stop the node and miner before backing up the data.
November 15, 2024, 10:22:50 AM
Good day all
I am some what a newbie in this field and would like proper steps to take ie solo mine with Apollo 2 full node.I've had the Apollo 2 since its first batch released.The various times my node stops running with a note to direct the Apollo to a solo mine pool hence my confusion isn't the unit a full node solo mine setup guide never directed me to connect to a solo pool the forum is very explanatory for pool mines but for Apollo 2 full node solo miners kind feel like I am hanging out to dry.Most times I have reboot it may continue to solo mine but most of the time I have to reformat the node all this began when I naively updated to v2.0.5 this node situation occurs every 5-6 days and the system disk usage is at 13/14 gb practically full any help would be greatly appreciated.
bless day family !!
I am some what a newbie in this field and would like proper steps to take ie solo mine with Apollo 2 full node.I've had the Apollo 2 since its first batch released.The various times my node stops running with a note to direct the Apollo to a solo mine pool hence my confusion isn't the unit a full node solo mine setup guide never directed me to connect to a solo pool the forum is very explanatory for pool mines but for Apollo 2 full node solo miners kind feel like I am hanging out to dry.Most times I have reboot it may continue to solo mine but most of the time I have to reformat the node all this began when I naively updated to v2.0.5 this node situation occurs every 5-6 days and the system disk usage is at 13/14 gb practically full any help would be greatly appreciated.
bless day family !!
November 15, 2024, 09:24:16 AM
just received an apollo 2. why does my node say max btc block is 168,473?
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
It should not be stuck? mine would show ( eg) 253000/870397, first number should grow slowly every few mins as it sync's with the blockchain and second number as new blocks are found, is either one changing? f your also show 0% thats not right. are you mining with it? are you using Wi-Fi or Ethernet cable?
yes, it should say 168,473/870397, or some such number. its not growing. and i just got up and still at 168,473. i have it plugged in to ethernet. yes, im mining, but i know it prob doesnt matter since it cant mine if its not on the right block lol
Your miner should still be mining to which ever pool you set up. You just can't solo mine thru your node until it's sync 100% with the block chain. You should be able to check your miner on the pool page to check on it. I think I would shut down the unit by using the button on your miner page so it shuts down properly and make sure both crds are seated in and restart the unit. If your going to mine make sure on Eco only.
yeah im solo mining. yeah ive done all the shut down stuff, reboot, it just comes back and is still 168,473.
i just did a support ticket. not a great day1 on the apollo2 for me lol
November 15, 2024, 08:21:19 AM
just received an apollo 2. why does my node say max btc block is 168,473?
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
It should not be stuck? mine would show ( eg) 253000/870397, first number should grow slowly every few mins as it sync's with the blockchain and second number as new blocks are found, is either one changing? f your also show 0% thats not right. are you mining with it? are you using Wi-Fi or Ethernet cable?
yes, it should say 168,473/870397, or some such number. its not growing. and i just got up and still at 168,473. i have it plugged in to ethernet. yes, im mining, but i know it prob doesnt matter since it cant mine if its not on the right block lol
Your miner should still be mining to which ever pool you set up. You just can't solo mine thru your node until it's sync 100% with the block chain. You should be able to check your miner on the pool page to check on it. I think I would shut down the unit by using the button on your miner page so it shuts down properly and make sure both crds are seated in and restart the unit. If your going to mine make sure on Eco only.
November 15, 2024, 08:07:18 AM
just received an apollo 2. why does my node say max btc block is 168,473?
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
It should not be stuck? mine would show ( eg) 253000/870397, first number should grow slowly every few mins as it sync's with the blockchain and second number as new blocks are found, is either one changing? f your also show 0% thats not right. are you mining with it? are you using Wi-Fi or Ethernet cable?
yes, it should say 168,473/870397, or some such number. its not growing. and i just got up and still at 168,473. i have it plugged in to ethernet. yes, im mining, but i know it prob doesnt matter since it cant mine if its not on the right block lol
November 15, 2024, 07:25:45 AM
samsung pro plus sdxc 128gb was on sale at the local BB store.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.
I picked up the same micro card mentioned. Thursday. I have a PC with two SD card slots. What program did you use to clone the old card to the new please?
follow the futurebit instructions online.
https://www.futurebit.io/flashing-sd-card
November 15, 2024, 06:19:00 AM
samsung pro plus sdxc 128gb was on sale at the local BB store.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.
I picked up the same micro card mentioned. Thursday. I have a PC with two SD card slots. What program did you use to clone the old card to the new please?
November 15, 2024, 05:49:15 AM
just received an apollo 2. why does my node say max btc block is 168,473?
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
It should not be stuck? mine would show ( eg) 253000/870397, first number should grow slowly every few mins as it sync's with the blockchain and second number as new blocks are found, is either one changing? f your also show 0% thats not right. are you mining with it? are you using Wi-Fi or Ethernet cable?
November 14, 2024, 11:06:26 PM
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
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
Could you please clarify the instructions for this? I'm only moderately experienced with this but I am having the same issue but only getting about 25% synced before I hit the error message.
Looking at the debug.log in the bitcoin directory is the most important item to monitor actively. An error message on the node GUI doesn't show you what's going on behind the scenes. Did the node abruptly stop? what errors? chainstate corrupt?
Do you have the browser open on the Node? I close the browser and have minimal items on the node open to monitor the logs. The node IBD performed better on my system with these closed. I stopped the miner until download complete. I monitor remotely as this only grabs basic data from the node. saves RAM
with the system monitor check the operating processes. Sometimes the bitcoind process may still be running even though the system looks paused. only when this process disappears is the node completely stopped. You can get an error message in the logs that memory buffer exceeded limits and the bitcoind then writes the data to the chainstate database and continues on. There is a pause when this happens.
November 14, 2024, 10:41:14 PM
ok, so itll be stuck at 0% for a while, then itll kick in. so check in am?
thx bro
thx bro
November 14, 2024, 10:37:30 PM
just received an apollo 2. why does my node say max btc block is 168,473?
also shouldnt ut take a bit to load node?
thx
also shouldnt ut take a bit to load node?
thx
I got mine last week and it took about 3-4 days to load the blockchain up.
November 14, 2024, 10:11:10 PM
just received an apollo 2. why does my node say max btc block is 168,473?
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
also shouldnt ut take a bit to load node?
thx
its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%
Jump to: