Pages:
Author

Topic: Monero Support - page 10. (Read 82997 times)

jr. member
Activity: 57
Merit: 1
September 15, 2016, 07:03:27 AM
cross post: https://bitcointalksearch.org/topic/m.16256658

Trying to sync monero on linux ubuntu 16.04 and I'm getting so many problems.
I did it normally, started ./bitmonerod and got first 300k blocks nice and reliatively fast. I come back the next day and it's on 320k?
so i wait 3 more days, 380k. something isn't right.

Downloaded the boot strap (took less than 5mins on high speed VPS) and follow instructions blockchain_import
I tried
 ./blockchain_import --database lmdb#nosync --verify 0 --input-file ~/blockchain.raw
 ./blockchain_import --database lmdb#nosync --verify=0 --input-file ~/xmr/blockchain.raw
 ./blockchain_import --verify 0 --input-file ~/xmr/blockchain.raw
 ./blockchain_import --input-file ~/xmr/blockchain.raw

You name it I tried around 10 different combos of those commands and each and every one failed. The "database" command was the fastest, but the last block would not be existent or corrupt and wouldn't allow the daemon to function. Massive PITA.

The rest of them would get to 200-350k blocks and simply start hogging resources and STILL not move anywhere in regard to progress. And then, not even being able to exit blockchain_import or bitmonerod (which ever one I was using and trying to sync with).

does anyone know the fastest way to sync on ubuntu 16.04. This is extremely frustrating.
hyc
member
Activity: 88
Merit: 16
August 17, 2016, 08:42:11 PM
Last I checked, the pi3 still only ships with a 32bit OS. A bit of a waste for a 64bit cpu.

I've been running on a geekbox, 8-core Cortex-A53 with 2GB RAM and a "fast" microSD card. Works fine.
legendary
Activity: 3136
Merit: 1116
August 16, 2016, 03:18:56 PM
I think compiling for arm might be a bit of a pita, haven't actually tried it myself tho
full member
Activity: 211
Merit: 100
August 16, 2016, 03:14:14 PM
I bought a raspberry pi 3 recently and was wondering what kind of sync speeds I could get with one of those fast 90MB/s cards and the pi3's 1.2GHz 64-bit quad-core ARM Cortex-A53 CPU.
It seems like it could be usable for monero but I am not sure if its worth a try if sync speeds take ages or there are some other unwanted reliability, ease of use or whatever other problems.
Full disk encryption seems like a must though, that could slow things down a lot.
You could have a full secure environment with full blown linux environment on a chip the size of a cent bootable from the most cheap and commodity hardware there is.
legendary
Activity: 1260
Merit: 1008
August 11, 2016, 02:40:56 PM
I am running a bitmonerod node, fully synced but my country isn't listed on the Monero Active Nodes Distribution (https://monerohash.com/nodes-distribution.html)
My IP is not public but that should not matter, right?
I checked on https://www.whatismyip.com/ and my country can be identified correctly.
So why is it not on the list?


it takes a while for your nodes presence to be detected on the network. Basically, nodes that connect to you (node A) say "oh hai, now I now you exist, I'm going to write down your number". And then when that node connects to another node (node B), the node B says "hey, how many nodes do you know?" and node A goes "here's my list. They're cool people". And node B goes "ok thanks bye." And then node C connects to node B and goes "yo I needs some nodes to connect to" and node B goes "Oh I gots a list".

So who knows where monerohash.com is on this list of sharing in relation to your node.

It will take a while, but you're on there. Make sure your ports are open too. Check your firewalls and open 18080
full member
Activity: 211
Merit: 100
August 11, 2016, 11:40:25 AM
I am running a bitmonerod node, fully synced but my country isn't listed on the Monero Active Nodes Distribution (https://monerohash.com/nodes-distribution.html)
My IP is not public but that should not matter, right?
I checked on https://www.whatismyip.com/ and my country can be identified correctly.
So why is it not on the list?
legendary
Activity: 1762
Merit: 1011
August 07, 2016, 03:19:08 AM
Was simplewallet --restore-deterministic-wallet, or something related to the following issue, broken in the master as of at least a month ago? I happened to build from the master back on July 10th and I just tried using it to restore a paper wallet, and it gave me a balance of zero. I refreshed, but it still showed a zero balance. I did a rescan_bc, and I noticed it scanned absurdly quickly compared to what I'm used to, but still displayed a zero balance. So, I went back to simplewallet from 0.9.4.0, and after letting it scan from scratch, the correct balance was shown.

Edit: I've just compiled from the latest master, and the problem persists. The scanning from scratch simply doesn't seem to detect any inputs or outputs.
newbie
Activity: 2
Merit: 0
July 29, 2016, 06:35:01 AM
Much appreciate your help for the following matter:

I made a SimpleWallet transfer which got stuck in daemon (Pending). I did rescan_bc and balance in SimpleWallet returned to the stage before the transaction.

However now when i try to make a transfer or transfer_new I'm getting "Error: Reason: double spend". How can this be fixed?

Thank you for your help!

Never mind. 5h later it had cleared out with a successful transfer.
newbie
Activity: 2
Merit: 0
July 29, 2016, 04:47:21 AM
Much appreciate your help for the following matter:

I made a SimpleWallet transfer which got stuck in daemon (Pending). I did rescan_bc and balance in SimpleWallet returned to the stage before the transaction.

However now when i try to make a transfer or transfer_new I'm getting "Error: Reason: double spend". How can this be fixed?

Thank you for your help!
newbie
Activity: 1
Merit: 250
July 17, 2016, 01:36:04 PM
Try the binaries that did get made.

Honestly, I'm growing tired of this answer. Got the same from the dash crowd. Even worse: "blah blah binary download site is the only place where you should get your client" (paraphrased).

This is an opensource project and imo it's important that people build from source habitually.

 I also never use the binaries and I never recommend anyone to use them.

 also compiling from source feels good.
donator
Activity: 2772
Merit: 1019
July 17, 2016, 03:08:01 PM
Try the binaries that did get made.

Honestly, I'm growing tired of this answer. Got the same from the dash crowd. Even worse: "blah blah binary download site is the only place where you should get your client" (paraphrased).

This is an opensource project and imo it's important that people build from source habitually.

dude, I meant the binaries that got made during your compile. When you first commented, there was a bug in unit tests, so the main binaries would compile fine but then there'd be a bunch of errors in the unit tests.

Now head on master compiles file without any errors.

Try the binaries that did get made.

Honestly, I'm growing tired of this answer. Got the same from the dash crowd. Even worse: "blah blah binary download site is the only place where you should get your client" (paraphrased).

This is an opensource project and imo it's important that people build from source habitually.

 I also never use the binaries and I never recommend anyone to use them.

 also compiling from source feels good.

sorry guys, I both misinterpreted what Gingerale said and also overreacted. Apologees.
legendary
Activity: 1260
Merit: 1008
July 17, 2016, 12:51:33 PM
Try the binaries that did get made.

Honestly, I'm growing tired of this answer. Got the same from the dash crowd. Even worse: "blah blah binary download site is the only place where you should get your client" (paraphrased).

This is an opensource project and imo it's important that people build from source habitually.

dude, I meant the binaries that got made during your compile. When you first commented, there was a bug in unit tests, so the main binaries would compile fine but then there'd be a bunch of errors in the unit tests.

Now head on master compiles file without any errors.
donator
Activity: 2772
Merit: 1019
July 17, 2016, 12:16:03 PM
Try the binaries that did get made.

Honestly, I'm growing tired of this answer. Got the same from the dash crowd. Even worse: "blah blah binary download site is the only place where you should get your client" (paraphrased).

This is an opensource project and imo it's important that people build from source habitually.
legendary
Activity: 1260
Merit: 1008
July 15, 2016, 03:53:14 PM
I'm running the 0.9.4 version on Ubuntu 14.04 server64 and simplewallet is running with rpc-bind-port 18082. Are any of these simplewallet error messages something to be concerned about?

2016-Jul-15 16:08:09.822920 Loaded wallet keys file, with public address: 492GF1q6jU61RnTWmKVhkjJbjWpD3KZch6EvCWBkurtqRFMYuk3HUgMcv8Wm3pEXwGh44W2yv3rJLf6 Yr17q9aPyTHqR3v6
2016-Jul-15 16:08:10.515469 ERROR /DISTRIBUTION-BUILD/src/cryptonote_core/cryptonote_format_utils.cpp:148 max_out exceeded
2016-Jul-15 16:08:10.813029 Loaded ok
2016-Jul-15 16:08:10.813380 Binding on 127.0.0.1:18082
2016-Jul-15 16:08:10.813598 Starting wallet rpc server
2016-Jul-15 16:08:10.813665 Run net_service loop( 1 threads)...
2016-Jul-15 16:08:30.858449 [RPC0]failed to deserialize extra field. extra = 01b5cb3dffb77997f32c37a7bc5e707af7b6f8faa2b8084777989288eeca3130bfde209fa65f6f5 20854c9635fbbdc7f81dc1874c92fa77bdb423366adbc69e771310c
2016-Jul-15 16:08:30.858606 [RPC0]Transaction extra has unsupported format: <9e714183c6683d67309759108a634fa87dc96406273af89ad1cf18573569d7af>



they are fine (im 99% sure). The max out is a bug thats fixed in current master, and the "extra field" thing is apparently some minergate nonsense. apparently minergate enjoys stamping their payouts with something weird.
hero member
Activity: 850
Merit: 1000
July 15, 2016, 03:46:03 PM
I'm running the 0.9.4 version on Ubuntu 14.04 server64 and simplewallet is running with rpc-bind-port 18082. Are any of these simplewallet error messages something to be concerned about?

2016-Jul-15 16:08:09.822920 Loaded wallet keys file, with public address: 492GF1q6jU61RnTWmKVhkjJbjWpD3KZch6EvCWBkurtqRFMYuk3HUgMcv8Wm3pEXwGh44W2yv3rJLf6 Yr17q9aPyTHqR3v6
2016-Jul-15 16:08:10.515469 ERROR /DISTRIBUTION-BUILD/src/cryptonote_core/cryptonote_format_utils.cpp:148 max_out exceeded
2016-Jul-15 16:08:10.813029 Loaded ok
2016-Jul-15 16:08:10.813380 Binding on 127.0.0.1:18082
2016-Jul-15 16:08:10.813598 Starting wallet rpc server
2016-Jul-15 16:08:10.813665 Run net_service loop( 1 threads)...
2016-Jul-15 16:08:30.858449 [RPC0]failed to deserialize extra field. extra = 01b5cb3dffb77997f32c37a7bc5e707af7b6f8faa2b8084777989288eeca3130bfde209fa65f6f5 20854c9635fbbdc7f81dc1874c92fa77bdb423366adbc69e771310c
2016-Jul-15 16:08:30.858606 [RPC0]Transaction extra has unsupported format: <9e714183c6683d67309759108a634fa87dc96406273af89ad1cf18573569d7af>

legendary
Activity: 1762
Merit: 1011
July 14, 2016, 03:15:57 AM
Is there a way to run simplewallet without logging? I get the impression that increasing log-level from the default 0 up through 4 just increases verbosity, with 0 still logging stuff.

whats the goal? and what OS?

there are various linux hacks you could use perhaps... like logrotate to decrease the size of simplewallet logs, or directing the logfile to the ramdisk thing (there's some mounted folder thats on RAM, so it dies when you turn off computer)... or just a cronjob to delete the .log files in a given directory every whenever.

as for straight up no logs... i don't think that exists, but thats definitely something you could put as a feature request on the monero github and it would probably be implemented because its probably really easy to do.

Yeah, if I was on Linux, I'd definitely be looking at directing it to /dev/null or the like. I happen to be on Windows, and just figured that if we're suggesting Monero to people as the privacy cryptocurrency, we shouldn't be logging our transaction data or even our public addresses to a plain text file. The less information left around the better when dealing with privacy concerns.
legendary
Activity: 1260
Merit: 1008
July 13, 2016, 11:31:47 PM
Is there a way to run simplewallet without logging? I get the impression that increasing log-level from the default 0 up through 4 just increases verbosity, with 0 still logging stuff.

whats the goal? and what OS?

there are various linux hacks you could use perhaps... like logrotate to decrease the size of simplewallet logs, or directing the logfile to the ramdisk thing (there's some mounted folder thats on RAM, so it dies when you turn off computer)... or just a cronjob to delete the .log files in a given directory every whenever.

as for straight up no logs... i don't think that exists, but thats definitely something you could put as a feature request on the monero github and it would probably be implemented because its probably really easy to do.
legendary
Activity: 1762
Merit: 1011
July 13, 2016, 11:28:04 PM
Is there a way to run simplewallet without logging? I get the impression that increasing log-level from the default 0 up through 4 just increases verbosity, with 0 still logging stuff.
sr. member
Activity: 453
Merit: 500
hello world
May 29, 2016, 12:52:00 AM
bitmonerod is spewing stuff like this every 10s or so:

ERROR   {8} {p1} 2016-05-28 15:25:07.443042 [abstract_tcp_server2.inl+512 ::do_send_chunk] send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
ERROR   {8} {p1} 2016-05-28 15:25:34.447733 [abstract_tcp_server2.inl+512 ::do_send_chunk] send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
ERROR   {4} {p1} 2016-05-28 15:26:14.299694 [abstract_tcp_server2.inl+512 ::do_send_chunk] send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
ERROR   {8} {p1} 2016-05-28 15:26:46.632806 [abstract_tcp_server2.inl+512 ::do_send_chunk] send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection
ERROR   {6} {p1} 2016-05-28 15:27:16.128294 [abstract_tcp_server2.inl+512 ::do_send_chunk] send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(1000), shutting down connection


this is a known issue and you can savely ignore it. it means one connection can not be shut down correctly, all the other connections of your node are probably fine still.
if you get annoyed by it, restart bitmonerod.

personally i only get this error on nodes running inside a VM

should be this one: https://github.com/monero-project/bitmonero/issues/661

---> will be fixed soon as far as i know
sr. member
Activity: 336
Merit: 250
May 28, 2016, 04:54:24 PM
For anyone who finds this thread helpful, please consider supporting this proposal:

https://area51.stackexchange.com/proposals/98617/monero

Eventually it will be an active and easily searchable FAQ site for Monero. It would be nice if whoever controls the OP of this thread could add this link.
Pages:
Jump to: