03:14:10 <chile09[m]> how to troubleshoot not receiving transactions on Whonix
03:16:12 <selsta> first step would be to check the transaction id on xmrchain.net
03:19:23 <chile09[m]> ok it's there
03:22:34 <chile09[m]> sync_info shows target at 43.00%
03:22:59 <chile09[m]> Doesn't look like the entire blockchain is downloaded
03:23:04 <chile09[m]> could that be why?
03:26:03 <chile09[m]> ok now it says 100% but the transaction is not there
03:29:56 <chile09[m]> Do you need to eneter the block height and block hash along with the transaction hash?
03:50:55 <selsta> You will need a fully synced node before the transaction shows up.
03:51:11 <selsta> Alternatively you can connect to a remote node.
04:26:05 <chile09[m]> It showed fully synced but is not showing the transaction
04:27:59 <nioc> daemon needs to be synced and then wallet needs to be synced with the daemon
04:33:30 <chile09[m]> daemon and wallet were both showing as synced but no transaction showing
09:13:09 <selsta> chile09[m]: if you were at 44% previously you won't be fully synced up a couple minutes later
09:13:17 <selsta> please post the output of "status"
14:56:11 <chile09[m]> When running monerod via cli, there is an error message that keeps appearing
14:56:29 <chile09[m]> WARNING: Insufficient free space to extend database !!: 235 MB available, 1024 MB needed
14:57:21 <selsta> maybe it stopped syncing because you are out of disk space?
15:01:32 <chile09[m]> is it related to disk space or RAM
15:01:39 <selsta> disk space
15:25:25 <chile09[m]> its 100 GB?
15:25:37 <selsta> yes, and 30gb pruned
15:25:44 <selsta> you can start monerod with --prune-blockchain to prune it
15:28:28 <chile09[m]> can I delete the existing one to start a fresh d/l of the pruned blockchain?
15:29:03 <selsta> yes
15:39:52 <chile09[m]> is it referring to disk space available with a specific folder or the entire disk
15:40:56 <selsta> do you have specific disk space limits on folders?
15:41:15 <selsta> if it's a VM you have to increase the VM disk space
15:42:23 <chile09[m]> the problem is that it's maxed out
15:42:57 <chile09[m]> it's already at system storage max size which is ~ 10 GB
15:43:32 <chile09[m]> It's asking for 1 GB but I'm not sure if that's the end of it in terms of demand for space
15:44:53 <chile09[m]> I could definitely find 1 GB to clear
15:48:33 <selsta> you need 30GB free space for a pruned node and 100GB for an unpruned one
15:57:00 <selsta> .merges
15:57:00 -xmr-pr- 3379
15:59:11 <bevanoff[m]> Why is QtQmlModels needed for build?
16:01:32 <selsta> https://github.com/monero-project/monero-gui/pull/3332 uses it
17:04:20 <bevanoff[m]> Ah thanks
19:12:14 <chile09[m]> There were 0 blocks in the last 90 minutes, there might be large hash rate changes, or we might be partitioned, cut off from the Monero network or under attack, or your computer's time is off. Or it could be just sheer bad luck.
19:12:26 <chile09[m]> ^what do?^
19:24:11 <chile09[m]> A reboot seems to have fixed it
19:32:47 <chile09[m]> and no it's broken again
19:38:06 <bevanoff[m]> Sounds like your daemon is disconnecting from the network. Prolly need a log to figure out why
19:59:23 <chile09[m]> sync_info returns 100% now but the wallet doesn't show any balance
19:59:47 <selsta> please post the output of "status" or "sync_info"
20:02:12 <chile09[m]> Height: 1151452/1151452 (100.0%) on mainnet, not mining, net hash 28.07 MH/s, v3, 4(out)+0(in) connections, uptime 0d 0h 53m 16s
20:02:21 <chile09[m]> ^status^
20:02:54 * chile09[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/lHmFiVLkRSTXZgbJtmwCiite/message.txt >
20:03:05 <chile09[m]> ^sync_info^
20:03:48 <selsta> you are not at the correct block height
20:04:10 <selsta> you don't have any synced peers
20:04:17 <selsta> so it thinks it is at 100%
20:04:24 <selsta> do you have enough disk space now?
20:05:20 <chile09[m]> yeah I increased the disk space and am not getting any further disk space related errors
20:05:41 <selsta> any monerod error messages?
20:11:16 <chile09[m]> W There were 0 blocks in the last 90 minutes, there might be large hash rate changes, or we might be partitioned, cut off from the Monero network or under attack, or your computer's time is off. Or it could be just sheer bad luck.
20:12:26 <moneromooo> Odd you'd have only peers claiming height 1. Might be the asshole again.
20:14:53 <chile09[m]> what?
20:15:21 <selsta> moneromooo: if the daemon blocks legit peers for whatever reason only height 1 peers would be leftover
20:15:50 <moneromooo> I guess. But I would not expect there to be more htan one or two of these at once.
20:16:21 <moneromooo> chile09[m]: restart with --log-level 1. See if there are errors in the log.
20:16:42 <moneromooo> If so, paste them to some site (matrix.org works).
20:17:22 <chile09[m]> isn't log level 1 less verbose
20:17:26 <chile09[m]> what about level 4
20:18:47 <moneromooo> 1 is enough to se consensus errors. 4 is spammy and unnecessary here.
20:21:03 <chile09[m]> ok
20:21:25 <chile09[m]> what am I looking for here
20:22:11 <moneromooo> Lines with "ERROR" in them.
20:27:49 <chile09[m]> ok its going mach 15 right now
20:33:42 <chile09[m]> W -> warning E-> error
20:36:08 <moneromooo> Yes, the console shortens the messages.
20:37:50 <chile09[m]> sent block ahead of expected height
20:40:00 <moneromooo> Then it's likely the asshole, or a bug... Restart with --log-level 2 and paste the log from the process start till the line sauying "ahead of expected height".
20:44:06 <chile09[m]> the asshole = the source of the problem?
20:44:53 <chile09[m]> Full command -> DNS_PUBLIC=tcp TORSOCKS_ALLOW_INBOUND=1 torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd --prune-blockchain --log-level 2
20:46:33 <moneromooo> Someone's known to spin up many modes lying and sending bad data to try and annoy monero users.
20:53:29 <chile09[m]> there's no blacklist mechanism?
20:55:28 <selsta> --enable-dns-blocklist
20:58:04 <chile09[m]> is that a monerod flag
21:27:56 <selsta> yes
21:42:45 <chile09[m]> seems to be flowing now although I can see % progress
22:11:22 <chile09[m]> can't*
22:18:00 <chile09[m]> will the wallet sync with the daemon
23:06:13 <selsta> chile09[m]: post "sync_info" output again
23:08:33 * chile09[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/YLuNOvooafyzxCMiSUBHHDmt/message.txt >
23:09:58 <selsta> are you sure you added --enable-dns-blocklist?
23:13:16 <chile09[m]> no I didn't why
23:13:22 <chile09[m]> crappy peers again?
23:13:50 <selsta> I don't know why your node loses all good nodes
23:14:00 <selsta> yea, half of your peers are bad peers
23:14:17 <selsta> the others are on height 0
23:14:47 <selsta> ok try adding --enable-dns-blocklist and --out-peers 32
23:16:46 <chile09[m]> what is the --out-peers 32 flag
23:16:58 <chile09[m]> can you explain it
23:16:58 <selsta> your daemon will connect to more peers
23:17:05 <chile09[m]> ok
23:17:18 <selsta> normally all this is not necessary but like I said don't know problem yet
23:19:06 <chile09[m]> could it be the torsocks connection?
23:19:45 <selsta> I don't know, peers can be dropped if the connection speed is too slow
23:19:56 <selsta> but some people synced fine with torsocks
23:25:54 <chile09[m]> this is using whonix
23:25:56 <chile09[m]> btw
23:34:29 <selsta> not familiar with whonix but should be fine