02:20:51 <winter> <selsta> didn't they just have a security release a couple days ago? <-- you may be thinking of the pre-advisory for this
06:08:03 <reminder> hi
06:08:51 <reminder> Why -30 here use_2021_scaling = use_fork_rules(HF_VERSION_2021_SCALING, -30 * 1);
10:51:46 <nassau> hello
10:54:55 <nassau> I have a  error  Unexpected hard fork version v16 at height Make sure your wallet is up to date. Blocks received:
11:00:01 <moneromooo> Did you make sure your wallet is up to date ?
11:00:17 <moneromooo> (also daemon, always use matching versions if possible)
11:02:14 <nassau> Yes i did
11:02:27 <nassau> All updated with latest version
11:03:13 <moneromooo> Is your wallet software monero-wallet-cli ?
11:04:26 <nassau> yes
11:04:38 <moneromooo> What does "status" report in monero-wallet-cli ?
11:12:20 <nassau> Refreshed 1/1, synced, daemon RPC v11.11, SSL
11:16:45 <moneromooo> What does "status" report in monerod ?
11:18:13 <nassau> Height: 1/1 (100.0%) on mainnet, not mining,  v16, 11(out)+11(in) connections, uptime 0d 0h 5m 50s
11:18:43 <moneromooo> What does "version" say in both monero-wallet-cli and monerod ?
11:19:46 <nassau> 0.18.1.0-c9cfa251
11:20:02 <moneromooo> Same for both ?
11:20:08 <nassau> Yes
11:20:15 <moneromooo> Did you change the code ?
11:20:24 <nassau> Not
11:20:36 <moneromooo> Did you run with --regtest ?
11:20:42 <nassau> Not
11:20:52 <moneromooo> Then... it's bizarre...
11:21:12 <moneromooo> The daemon is not syncing at all, and it should be v1 at that point.
11:21:27 <moneromooo> I do not understand why it'd be v16 without code changes nor regtest :/
11:21:54 <moneromooo> Can you paste the output of "sync_info" to paste.debian.net ?
11:21:57 <moneromooo> (monerod)
11:25:49 <nassau> This is the output from monero-wallet
11:25:51 <nassau>  "Unexpected hard fork version v" + std::to_string(hf_version) + " at height " + std::to_string(height) + ". " +
11:26:27 <nassau> If i install old monero version i have no problems
11:27:41 <moneromooo> Both old and new will use the same db, so if the new monerod reports height 1, the old also should.
13:15:53 <selsta> nassau: try to compile the latest version
13:16:02 <selsta> (I know they left already)
14:10:08 <linuxperia> Hi all. I am a monero newbie. after i synced the monero blockchain db and run p2pool in parallel somehow i crashed the monero db. i am getting always this error message now here when i try to start the monerod => "W Failed to find txpool tx blob to match metadata" "Exception in main! Failed to find txpool tx blob to match metadata" I checked the lmdb database using the "mdb_stat -fff lmdb/" command and it segfault with this message here => 
14:10:08 <linuxperia> "Freelist Status
14:10:08 <linuxperia>   Tree depth: 2
14:10:08 <linuxperia>   Branch pages: 1
14:10:10 <linuxperia>   Leaf pages: 12
14:10:12 <linuxperia>   Overflow pages: 0
14:10:14 <linuxperia>   Entries: 336
14:10:16 <linuxperia>     Transaction 23, 5 pages, maxspan 4
14:10:18 <linuxperia>       36554021
14:10:20 <linuxperia>       36554027[4]
14:10:22 <linuxperia>     Transaction 24, 6 pages, maxspan 4
14:10:24 <linuxperia>       36554022
14:10:26 <linuxperia>       36554024
14:10:28 <linuxperia>       36554033[4]
14:10:32 <linuxperia>     Transaction 6720514773099737224, 3 pages, maxspan 1
14:10:34 <linuxperia>       35700948
14:10:36 <linuxperia>       35708585
14:10:38 <linuxperia>       35728040
14:10:40 <linuxperia> Segmentation fault
14:10:42 <linuxperia> "
14:15:57 <linuxperia> need to get my monero blockchain synced again without that i download the whole blockchain again as it will wear down my mlc ssd. How can this problem be fixed. Monero DB looks very instable compared to other much more advanced key/value blockchain databases
14:39:43 <moneromooo> You can try running monerod once with --db-salvage.
14:39:56 <moneromooo> If it does not work, I don't think you can avoid a full resync.
14:41:14 <moneromooo> hyc: mdb_stat crash above, if there's info you'd like to ask linuxperia.
14:41:48 <moneromooo> linuxperia: did your computer crash/wedge ?
14:42:05 <linuxperia> i just restarted p2pool severaltimes in parallel
14:42:09 <moneromooo> Windows is known to be shit at preserving filesystem data when it does.
14:42:31 <moneromooo> If it happens again, you may want to run monerod with --db-sync-mode safe (IIRC).
14:43:03 <moneromooo> I assume this means "no" ?
14:43:24 <linuxperia> it does not work with --db-sync-mode
14:43:29 <linuxperia> i will try again
14:45:16 <linuxperia> moneromoo: tryed both options --db-sync-mode safe --db-salvage it does not help :-(
14:45:33 <linuxperia> looks like need to resync :-( very bad
14:45:56 <linuxperia> thanks still for the tips moneromooo
14:49:23 <moneromooo> hyc: if there's a txn bug in monerod, can it lead to mdb_stat crash ? I'd think it'd just lead to semantically inconsistent data, but still with a synctactically valid db.
14:54:43 <linuxperia> i was able to do a more verbose log output. it provides much more info now what happens before the crash. its quite long. will try upload it to a paste website. 1 moment
15:00:49 <linuxperia> its 1.8 MB big and most pastebins refuse such a long log. need split it up. 1 minute
15:05:13 <linuxperia> moneromoo: hyc: here is the crash log of monerod => https://pastebin.com/raw/NfDyKgNp
15:09:01 <hyc> moneromooo: correct, a bug in monerod cannot cause an invalid DB.
15:35:44 <moneromooo> So it looks like a possible lmdb bug if this happened without an OS/HW crash.
15:36:07 <moneromooo> Or OS bug I suppose.
15:36:21 <hyc> nah. from discussion in other channel, he's using a weak SSD
15:36:44 <moneromooo> Ah.
15:42:07 <linuxperia> moneromooo: hyc: i think p2pool destroyed the database as it uses the database of monerod too. overall think main problem happens when several programms at the same time in parallel try to use the monero database happens such problems. other have reported also problems with the database. see here. => https://www.reddit.com/r/monerosupport/comments/oop0yo/does_anyone_know_a_solution_for_the_error_failed/ yeah it happened without a hw Crash. I just 
15:42:07 <linuxperia> Started and Stoped p2pool very fast in parallel
15:42:40 <hyc> yeah that's false. 
15:42:46 <hyc> p2pool doesn't touch the monerod database
15:43:03 <hyc> and LMDB is rock solid with multiple process use. but that's not the situation here.
15:44:21 <hyc> as for the error message you linked above - that happens routinely, doesn't mean anything
15:44:31 <hyc> in particular doesn't mean the DB is broken
15:48:04 <linuxperia> hyc: okey just checked the which programm i started in parallel very fast and used the lmdb databse of monero and it is xmrblocks it require direct access to the lmdb data abse for this i created a symlink to the database as follow on the ssd "xmrblocks/lmdb/data.mdb -> /ssd-data/monero/lmdb/data.mdb" so it was not p2pool but xmrblocks
15:48:34 <hyc> I dunno what xmrblocks is
15:49:02 <linuxperia> its a monero explorer that you can run local
15:49:58 <linuxperia> xmrblocks => https://github.com/moneroexamples/onion-monero-blockchain-explorer
15:53:26 <hyc> is monerod always active when xmrblocks starts? why does xmrblocks start/stop "very fast in parallel" ?
15:56:49 <linuxperia> i changed the html template so it looks much better and needed to restart xmrblocks. yes monerod runs always in background. it could be that however i stoped monerod too then restarted it and in parallel run after this xmrblocks too. it may xmrblocks blocked monerod. i rember i had to restart xmrblocks as i did not see my html changes in xmrblocks and thinked its becouse of some cach so when i restar it may go away.
15:57:52 <linuxperia> but then the monerod database crash happened after this restarts
15:58:04 <linuxperia> and nothing worked anymore
16:03:05 <linuxperia> now ofcourse i only try to start monerod alone without p2pool and xmrblocks are running but it fails
16:03:33 <hyc> do the mdb_dump and mdb_load.
16:04:09 <linuxperia> aww okey let me look into it. need to lookup the snytax of this two command. use it for the first time
16:13:26 <linuxperia> hyc: it does the dump right now. used this command here => "mdb_dump -a -f 20220929.backup lmdb"
16:15:16 <hyc> does it succeed?
16:15:55 <linuxperia> it still works. its about 130 GB. will write as soon the dump finish
16:24:10 <linuxperia> hyc: i see lot of io on the ssd so something is going on but it still not finished see picture => https://pasteboard.co/NUWFdp0XfcUk.png
16:31:04 <linuxperia> hyc: it dumped about 75GB till now so about 50% of the work is done
16:42:20 <linuxperia> hyc: the monero lmdb has a size of 149725786112 Sep 29 14:50 data.mdb and the dump that is still not finished is allready over 160GB => 160902246400 Sep 29 16:41 20220929.backup hope it finish soon :-(
16:45:13 <hyc> it dumps in hex, so it will be at least 2x larger than original file
16:47:21 <hyc> on a fresh build of xmrblocks, it always SEGVs on exit https://paste.debian.net/1255451/
16:47:30 <hyc> this is built with monero masster
16:49:25 <linuxperia> hyc: thank you very much for the information. good to know the size of the dump will be 2x asked me allready how big it will be
16:52:37 <linuxperia> hyc: ahh the segfault of xmrblock yeah it could be yes. i installed xmrblocks so i can check the blockchain localy direct with my monerod blockchain wihout to use the internet or other websites. xmrblocks is really great but i think it bites with monero especially when you restart it a lot. it could be even that i used two ssh sessesions to stop and run it so something with parallel access to the blockchain lmdb database of monero got wrecked.
16:54:21 <linuxperia> here some websites that use xmrblocks to provide a monero blockchain explorer => https://github.com/moneroexamples/onion-monero-blockchain-explorer#explorer-hosts aka see => https://monerohash.com/explorer/
16:54:26 <rbrunner> That sounds strange somehow, because you would expect that a block explorer only reads anyway, which *should* be quite harmless
16:59:12 <linuxperia> rbrunner: yes think also like this but i experienced a problem with the lock file i think in lmdb they both use the lock file if i am not wrong to write
17:00:15 <revuoxmr> Revuo Monero. Issue 139: September 22 - 29, 2022. http://revuo-xmr.com/issue-139.html
17:03:11 <linuxperia> hyc: YEAAYYYY it Finished :happy:
17:03:31 <linuxperia> now trying to load the dump then. aww lets hope it will work
17:04:48 <linuxperia> hyc: you was absolute righ with the 2 time size of the dump. so whenever someone need to do a backup dump he need to have two time free space on disk than the lmdb file size. okey going to do the dump load now
17:06:22 <hyc> yeah they all have to use the lockfile to coordinate
17:07:02 <hyc> anyway it makes no sense to start xmrblocks multiple times in parallel. it acquires a single listener port, so only one can succeed.
17:12:04 <linuxperia> yes did not start it multiple times becouse i was not able to access it but becouse after i changed the html template files ( it come with own webserver ) it did not delivered the changes but showed the old version so thinked it my be a cache problem. restarted it 1 time checked the browser nothing. then repeated it several times and things got broke
17:18:00 <linuxperia> i am getting this output here right now with mdb_load: asking me if mdb_dump really worked good. checking the files size of monero lmdb looks like its growing instead of staying same. looks like mdb_dump did dumped some wrong data mdb_load: line 7: unrecognized keyword ignored: db_pagesize
17:18:00 <linuxperia> mdb_load: line 16: unrecognized keyword ignored: duplicates
17:18:00 <linuxperia> mdb_load: line 20: unrecognized keyword ignored: db_pagesize
17:18:00 <linuxperia> mdb_load: line 5420013: unrecognized keyword ignored: duplicates
17:18:01 <linuxperia> mdb_load: line 5420017: unrecognized keyword ignored: db_pagesize
17:19:30 <hyc> "ignored" - doesn't matter.
17:21:01 <linuxperia> okey thanks a lot for the info. if mdb_dumps works it is really the prefered solution than resynching everything from scratch.will write again when mdb_load finish
17:21:58 <hyc> did you alsu use -a flag on mdb_load?
17:22:07 <hyc> should speed things up a little
17:22:45 <hyc> and you must delete the original DB before running mdb_load
17:23:25 <linuxperia> no it does not has the -a flag from what i saw in the docs => https://www.systutorials.com/docs/linux/man/1-mdb_load/ but i will check right now. ohh thinked i can write direct over it without to delete it
17:23:33 <linuxperia> looks like it append the data then
17:23:36 <linuxperia> okey aborting
17:26:28 <hyc> you should only trust the documentation bundled in the monero source tree
17:26:43 <hyc> looks like the doc you linked is for an older version
17:26:58 <linuxperia> hyc: thanks a lot for the helpful tips. doing a new dump_load now. asked me allready why the lmdb grows in size instead that it should overwrite the data and stay same size.
17:27:01 <linuxperia> good
17:27:38 <linuxperia> okey all good now
17:27:45 <linuxperia> thumbs up :-)
17:31:57 <linuxperia> lmdb is absolute new to me. will need do more research about it in the future. downloaded allready some php librarys to access lmdb and it works. could do direct read access to lmdb over php as in recent versions lmdb was integrated into lmdb. See the last row in the table about the lmdb in php here => https://www.php.net/manual/en/dba.requirements.php
17:34:45 <hyc> be careful about using other LMDB modules. must always link against the same liblmdb.a that monerod uses.
17:36:07 <hyc> any distro-provided liblmdb.so is nearly always several versions out of date
17:37:34 <linuxperia> yeah true. especially on lts long term support version they quite outdated. thanks again for the tip.
17:58:30 <linuxperia> i will write back after a few hours back or maybe even come back tomorrow. it looks like mdb_load works slower then the mdb_dump. load progress at the moment passed 1% right now so it will take some time. thank you all for helping me as a monero newbie out. you really all amazing here. big compliments to all of you especially hyc moneromooo!