13:20:10 <jwinterm> is there a way to compile or run monerod without huge pages/huge page support?
13:20:12 <jwinterm> https://github.com/wownero/wownero/issues/233
13:28:57 <moneromooo> It's not fatal, it goes on to allocate "normally".
13:29:23 <gingeropolous> jwinterm, there should be... thats sorta the point of the "lite" mode for randomx. im guessing it tries to run it big and then defaults to lite mode
13:29:36 <moneromooo> If it's the spam that's the problem, I think yo need to renmove the first alloc call.
13:29:56 <jwinterm> I think it's the spam that's the problem
13:30:14 <gingeropolous> those INFO messages
13:30:27 <jwinterm> .shrug
13:30:40 <moneromooo> Line 225 in rx-slow-hash.c
13:30:52 <gingeropolous> ima make tshirts. INFO WARN ERROR
13:30:59 <moneromooo> cache = randomx_alloc_cache(flags | RANDOMX_FLAG_LARGE_PAGES);
13:31:05 <moneromooo> Skipping that should do it.
13:31:11 <asymptotically> wasn't there an environment variable to control it?
13:31:33 <gingeropolous> i thought there was too, but i just scanned the help and didn't find a flag
13:31:43 <gingeropolous> oh you mean export=something do magic
13:31:52 <jwinterm> yea I looked at monerod help and didn't see option
13:32:03 <jwinterm> set variable before compile?
13:32:11 <gingeropolous> .dunno
13:32:54 <moneromooo> I remember talk of one, but git grep getenv does not pick up anything in randomx. Maybe only in new versions.
13:33:33 <gingeropolous> i mean, perhaps a user would want to thrash their CPU instead of use a lot of memory
14:35:57 <moneromooo>  /window 27
15:40:28 <gingeropolous> nowindowforyou
17:09:30 <hyc> use MONERO_RANDOMX_UMASK env var
17:10:40 <hyc> you'll need to check randomx.h for what the flag values are
17:11:10 <hyc> jwinterm: ^^
17:14:10 <hyc> https://github.com/monero-project/monero/blob/master/src/crypto/rx-slow-hash.c#L86
22:36:00 <Feuermagier> I ran into an error while importing the chain from file
22:36:17 <Feuermagier> block height: 1959719
22:36:18 <Feuermagier> block height: 1964659
22:36:18 <Feuermagier> block height: 1968799
22:36:18 <Feuermagier> Done scanning bootstrap file
22:36:18 <Feuermagier> Full header length: 1028 bytes
22:36:18 <Feuermagier> Scanned for blocks: 59216999345 bytes
22:36:20 <Feuermagier> Total:              59217000373 bytes
22:36:22 <Feuermagier> Number of blocks: 1968800
22:36:26 <Feuermagier> 2020-03-10 22:07:56.796 I bootstrap file last block number: 1968799 (zero-based height)  total blocks: 1968800
22:36:29 <Feuermagier> Preparing to read blocks...
22:36:31 <Feuermagier> 2020-03-10 22:07:56.842 I bootstrap file recognized
22:36:33 <Feuermagier> 2020-03-10 22:07:56.842 I bootstrap::file_info size: 4
22:36:35 <Feuermagier> 2020-03-10 22:07:56.842 I bootstrap file v0.1
22:36:37 <Feuermagier> 2020-03-10 22:07:56.842 I bootstrap magic size: 4
22:36:42 <selsta> please use paste.debian.net
22:36:43 <Feuermagier> 2020-03-10 22:07:56.842 I bootstrap header size: 1024
22:36:45 <Feuermagier> 2020-03-10 22:07:56.842 I start block: 1696170  stop block: 1968799
22:36:47 <Feuermagier> 2020-03-10 22:07:56.842 I Reading blockchain from bootstrap file...
22:36:49 <Feuermagier> 2020-03-10 22:09:33.873 F ERROR: unexpected end of file: bytes read before error: 0 of chunk_size 30702
22:36:51 <Feuermagier> Bus error
22:37:12 <selsta> the file is corrupted
22:37:30 <selsta> I would sync using monerod, it is way easier
22:37:47 <Feuermagier> https://paste.debian.net/1134399/
22:38:06 <Feuermagier> Yes, I'm trying to do that now.
22:38:09 <Feuermagier> However
22:38:14 <selsta> Did you continue the download somehow?
22:38:39 <Feuermagier> https://paste.debian.net/1134400/
22:38:55 <selsta> Network shares are not supported.
22:39:00 <Feuermagier> Now it complains about a read only database
22:39:13 <selsta> I would recommend to use an SSD + pruning
22:39:20 <selsta> only takes 25GB and fast
22:39:29 <Feuermagier> What is pruning?
22:39:44 <selsta> Reduces the file size from 70GB to 25GB
22:39:50 <Feuermagier> How?
22:40:18 <selsta> You only store 1/7th of some less important data.
22:40:23 <selsta> Your privacy stays the same.
22:40:33 <selsta> And other nodes can sync from your node.
22:40:58 <selsta> `./monerod --prune-blockchain`
22:41:10 <Feuermagier> How do i fix the database-read-only error?
22:41:12 <selsta> but you have use a HDD or SDD
22:41:24 <selsta> you are using a NAS according to the logs
22:41:57 <selsta> oh, you are using a raspberry
22:42:10 <selsta> syncing will be slow :)
22:42:40 <Feuermagier> The RaspberryPi *hosts* the NAS
22:42:52 <Feuermagier> I'm using the same HDD for the chain
22:43:08 <selsta> It looked like a mounted NAS.
22:43:15 <selsta> Same HDD should work.
22:43:30 <Feuermagier> It is a plugged in HDD
22:43:40 <Feuermagier> The error occured after I tried to import the chain from file
22:43:52 <Feuermagier> I had 70% of the chain downloaded already
22:44:05 <Feuermagier> and then started the import of the .raw file
22:44:06 <selsta> you can’t import 70%
22:44:14 <Feuermagier> the 55gb
22:45:11 <selsta> ok, move `/media/NAS/Monero/lmdb` to a different folder and start the daemon again
22:45:27 <Feuermagier> Won't that reset my progress?
22:46:05 <selsta> Just for testing.
22:46:19 <Feuermagier> ok, rebooting the Pi first, sec
22:46:26 <selsta> rename lmdb to lmdb2 and try
22:46:39 <Feuermagier> ok. will do
22:51:07 <Feuermagier> I restarted and am running the daemon again now
22:52:23 <Feuermagier> reboot alone might have fixed it
22:53:51 <Feuermagier> seems to be doing stuff for now at least
22:55:22 <selsta> ok, I’m not sure if it’s going to work
23:00:01 <Feuermagier> It seems to have ignored my attempt to import from file completely and is now continuing it's download: 2020-03-10 22:58:22.802 I Synced 1696210/2051663 (82%, 355453 left)
23:00:26 <selsta> looks good
23:01:00 <selsta> I think it will take a few more days.
23:01:07 <Feuermagier> yep
23:01:24 <Feuermagier> probably 1-2 weeks more
23:01:27 <selsta> v0.15.0.5 will be out soon, you should update then even if the sync is still in progress
23:01:33 <selsta> it includes new checkpoints
23:01:40 <Feuermagier> what are checkpoints?
23:03:05 <selsta> I can’t explain it in technical terms  but the sync will be faster until the last checkpoint.
23:03:56 <selsta> v0.15.0.1 is 3 months old, so the last checkpoint is also 3 months old
23:04:04 <selsta> the last 3 months will be super slow to sync
23:04:17 <Feuermagier> do you have some additional reading on checkpoints and pruning?
23:05:06 <selsta> https://web.getmonero.org/2019/02/01/pruning.html
23:07:06 <Feuermagier> thx. seems interesting. but as I can afford the additional space and it helps the network more i think i'll keep the full chain
23:07:27 <selsta> the difference for the network is minimal
23:07:41 <selsta> I have nothing on checkpoints but usually it is nothing to worry about as a user
23:08:26 <Feuermagier> is it like a checksum for all blocks in a specific period?
23:08:31 <moneromooo> The binary includes a database of known hashes for blocks 0 to N. If a block you get over the network matches the expected one, it skips some validation tests.
23:08:47 <moneromooo> Well, now it's more like the hash of a set of hashes of blocks, since it saves space, but same idea.
23:09:04 <Feuermagier> makes sense
23:09:16 <moneromooo> You can disavle that with --fast-sync 0 IIRC.
23:09:34 <selsta> checkpoints are only for rollbacks?
23:09:48 <selsta> what is the correct name for the database?
23:10:29 <Feuermagier> syncing past 75% definitely seems to go a *lot* slower than 0-50%
23:14:12 <moneromooo> I don't understand selsta.
23:16:05 <selsta> There are checkpoints in checkpoints.cpp and there is the checkpoints.dat with expected_block_hashes_hash[].
23:16:08 <selsta> Are they related?
23:16:46 <moneromooo> In some way I guess, since they're both about checking block hashes.
23:17:11 <moneromooo> It's a bit unfortunate checkpoints.dat is called that but hey.
23:17:27 <selsta> That is what always confused me :D
23:17:35 <Feuermagier> Is there a technical explanation somewhere I can read up on these things?
23:20:40 <selsta> not aware of any