log☇︎
169300+ entries in 0.103s
asciilifeform: see, it may seem to mod6 that asciilifeform is simply being difficult, whereas what asciilifeform found was that WE NEVER ACTUALLY FIXED 168K ☟︎
asciilifeform: weigh the 2 kernels, you'll see why.
mod6: I'm confused, are you saying that you're not interested in making a Cuntoo then?
asciilifeform: naively thought 'i'll start with the smallest trb node!'
asciilifeform: i'd like to get OFF linux.
mod6: I just rolled in, gimme some time to catch up and figure out whats what.
mod6: so run on linux then
asciilifeform: if i am mistaken, mod6 et al plox to say when and where it was resolved.
asciilifeform: went away on linux ( and apparently openbsd ) from locks patch, and that was the end of the thread
a111: Logged on 2015-07-23 01:10 mod6: we saw stuff like that before with the 168`001 Verify Signature fail too. most of the time it failed for us... the three of us who were independantly testing it. But sometimes, it'd pass. Maybe 30% of the time. I was pulling my hair out.
asciilifeform: http://btcbase.org/log/2015-07-23#1210108 << afaik this was never actually resolved in the logs ☝︎
asciilifeform: i am using literally the same deps dir as for past 2y.
mod6: take it easy. just asking as it was indicated to be source of previous 168k wedge issue.
a111: Logged on 2015-07-05 05:36 assbot: Logged on 05-02-2015 00:36:21; mod6: seems to be: 2c2314f353 VerifySignature failed ... invalid block=0000000000000a40136b height=168001
asciilifeform: and it goes on, and on, the invalidchainfound index marches on and on, then reorg fails, then ... etc
asciilifeform: http://wotpaste.cascadianhacker.com/pastes/GWzyh/?raw=true << the pattern, in short. ☟︎
asciilifeform: http://nosuchlabs.com/pub/liquishit.txt << representative sample of the interesting part. (warning -- 20MB!)
asciilifeform: ^ whole debug log since t=0
asciilifeform: all this time i thought there were reproducibles. but it is nonsense to speak of reproducibles in 200Mb of liquishit dep that does whatever the fuck it wants
phf: until you can actually reproduce the nature of locks patch vs. block (or whatever wedges)
asciilifeform: i am increasingly of the notion that i can't rreason about ANY of it
asciilifeform: my suspicion is that the bdb locks patch somehow has no effect when bdb built on netbsd ☟︎
phf: you replay to 167998, you then let it run till 168000 on the network. if it doesn't wedge with that setup, than you have two possibilities. it is either a heisenbug, or you need to replay to an earlier block, say 167000 and let that run on the wild network, etc. ☟︎
deedbot: http://www.contravex.com/2017/08/05/the-bitcoin-crash-fork-failure-chronology/ << » Contravex: A blog by Pete Dushenski - The Bitcoin Crash fork failure chronology.
phf: if it consistently wedges at 168000 across various machines and settings then it's not a question of wild sewage
asciilifeform: nor the timings.
asciilifeform: eatblock doesn't replicate the unknown stream of wild sewage that thing ate.
phf: split the current blocks, eat block until 167998, then on each restart copy the 167998 state folder over the settings folder
phf: well, if i were approaching this, i'd replay to 167998 or so, setup a script to ensure that every time i start trb it starts from that state. i would then see if on forward play it would wedge. i would then investigate what is the nature of wedging, and slowly instrument the code along the various paths to tell me where exactly it decides to stop doing the right thing, etc.
phf: i don't remember every suggesting anything remotely similar. my suggestion would be to debug it, and solve the problem, rather than "mp's fix somehow magically resolves it"
asciilifeform: anyway phf mod6 BingoBoingo et al taking suggestions ( other than the beneath-contempt nonsense of 'reboot and jiggle the handle blindly until it works and forget about cement fleet ' )
a111: Logged on 2017-03-28 04:32 asciilifeform: mod6: imho manual knobs ~for unwedging~ are a fundamental mistake. nodes shouldn't be wedgeable, period. and the only use for a wedged node is to learn why it wedged and to make said scenario impossible in the future.
asciilifeform: BingoBoingo: i was reading plusminusweek of each of those search res for past 2h
asciilifeform: phf: there was a bdb idiocy iirc that wedged at 168k
BingoBoingo: last sync test WAS trb on linux
phf: that's a nice round number too, 168000
asciilifeform: BingoBoingo: the absolute most total nogood.jog
asciilifeform: ( and where if the addnode people get hiccupped it will pick a rando scum to rely on, and never drop him no matter how many hours, days, WEEKs without newblock incoming)
asciilifeform: i duneven know if to blame bsd ( how..? ) or the imbecile's sync algo where all depends on who first node syphilitically fucks on warmup
asciilifeform: fucking disgrace, is what this is
asciilifeform: i walked the logs , found no record of a nailed root cause or finalsolution
phf: i remember people wedging around there, but i didn't personally observe it
asciilifeform: i seem to recall.
asciilifeform: ( this ain't an ancient liquishit press )
BingoBoingo: <asciilifeform> worth a comparison << Aha someone steps up to duplicate my December 2016 to May 2017 experiment!
asciilifeform: http://btcbase.org/log/2017-08-05#1694293 << i dun like relying on contents of rotten hdd any more than i have to ☝︎
mod6: <+phf> that's because you didn't try to simply use the patch to makefile that i posted on the list << i've had a trb openbsd since you posted this yes.
mod6: <+asciilifeform> zoolag live as of now at ye olde 108.31.170.49 . << thanks for the update. ☟︎
asciilifeform: also at some point i'ma document this build and put own seal on phf's quite useful bsd fix.
asciilifeform: gentlemen, if anybody wants his wire back, write in. but it won't do you much good until the thing is synced.
asciilifeform: ACHTUNG PANZERS , welcome back the new zoolag
asciilifeform: ...fixed. the docs lied re default route
asciilifeform: why would it demand a working network PRIOR to assignment of static ip ?!!!!
asciilifeform: motheFUCKER 'route: writing to routing socket: Network is unreachable' when rebooted with the by-the-book static ip config.
asciilifeform: about to put zoolag back in service. it will sync, for some days.
trinque: so the encrypted item is both the hex string and what you told the bot to do.
asciilifeform: you have nfi whether it is actually a last year's hex string, fed back to you again.
trinque: the challenge includes the request
asciilifeform: what's there to inspect ? ☟︎
trinque: that yes, user has to be careful, not automate response, inspect the item in his hands before !!v
asciilifeform: i do not know of anything that would qualify as a final solution for this.
asciilifeform: however one of the things that i always had ill ease about re pgp challenge-responsetrons , is that enemy who somehow substituted one, can get you to decrypt a message of his choice. (e.g. last year's launch codes.)
asciilifeform: trinque: this looks neato
deedbot: http://trinque.org/2017/08/05/otp-bot-services/ << trinque - Towards a Reliable OTP Mechanism for Bot Services ☟︎
phf: which reminds me that i need to regrind my shiva swank patch, which is broken
asciilifeform: incidentally i have nfi how you got bdb to build, bsd libtool seems to be broken , tries to write to /include and barfs ( rather than to the demanded local dir )
asciilifeform: dunno -- possibly because it never turned into a proper vpatch ..?
asciilifeform: phf: the result runs ?
phf: and the most important part is to replace -l pthread with "-Wl,--whole-archive -lpthread -Wl,--no-whole-archive" which in fact should be happening on all os
asciilifeform: yes indeed this is exactly it.
asciilifeform: phf: ty
asciilifeform: phf: remember by any chance when/where this was ?
phf: that's because you didn't try to simply use the patch to makefile that i posted on the list
phf: that memory is incorrect, the correct memory would be of ~you~ barfing at the then suggestion of supporting bsd :> ☟︎
asciilifeform: i have this memory of phf barfing
asciilifeform: phf: didja do this at some point ?
asciilifeform attempts a build of traditional stator trb inside netbsd ( as rotor is unnecessary there, there is no drepper glibc )
phf: tramp when it sets up remove ssh scaffolding, sends small inline scripts which defensively retranslate what emacs wants, rather then doing "ssh foo ls"
phf: emacs for example with their tramp has layers of fallback (oh you don't have perl? it's ok, we'll do it with toothpicks, but takes 2x longer)
asciilifeform: does weird things, doesn't see home dir on login via fish, and if manually put there, refuses to write
asciilifeform: still no fish though
phf: binds bunch of keys to "users come to expect", including tab completion to ^I
asciilifeform: i have busybox-based linux2.4 shitboxes with 8M of disk that behave better than this.
asciilifeform: if somebody knows how to make it behave like white man os -- plz to write in.
asciilifeform: midnight/'fish' dun work with the heathen shell either, i end up having to tar up whatevers and sftp'em in/out , takes 100x as long ☟︎
asciilifeform: if i had to pick b/w not having indoor shitter and not having tab completion, i'd pick the former. ☟︎
asciilifeform: i have nfi why anyone still tolerates this sort of thing.
asciilifeform: no shell with tabcompletion, even. pure agony to so much as work on the thing.
asciilifeform discovers that NOTHING AT ALL works under netbsd for ~building~ ( i had 2yrs ago build a 'stator' FOR netbsd, UNDER linux, worked... )
asciilifeform: ( no trb yet, but enough to re-pour the cement... )
a111: Logged on 2017-08-05 17:39 asciilifeform: later on i'ma pull the drive & try guessing the magic params and writing'em in on other box.
asciilifeform: http://btcbase.org/log/2017-08-05#1694208 << in other noose, this worked. ☝︎
asciilifeform: lobbes: plz examine what you sent , because i dun see anything of the sort.
a111: Logged on 2017-08-05 16:41 asciilifeform: !~later tell lobbes should show up some time today or mon.
lobbes: http://btcbase.org/log/2017-08-05#1694201 << eh? Reread message I sent (maybe I can't word things). There was a mistake that benefits me, not you :) ☝︎
deedbot: http://phuctor.nosuchlabs.com/gpgkey/456A734E6DDFB53A731F4AEF83BD5E7FC76183C407E172C8CF9D85EBF8967751 << Recent Phuctorings. - Phuctored: 1653...9993 divides RSA Moduli belonging to '46.171.47.62 (ssh-rsa key from 46.171.47.62 (13-14 June 2016 extraction) for Phuctor import. Ask asciilifeform or framedragger on Freenode, or email fd at mkj dot lt) <ssh...lt>; ' (pbv62.internetdsl.tpnet.pl. PL)
deedbot: http://phuctor.nosuchlabs.com/gpgkey/456A734E6DDFB53A731F4AEF83BD5E7FC76183C407E172C8CF9D85EBF8967751 << Recent Phuctorings. - Phuctored: 1405...6307 divides RSA Moduli belonging to '46.171.47.62 (ssh-rsa key from 46.171.47.62 (13-14 June 2016 extraction) for Phuctor import. Ask asciilifeform or framedragger on Freenode, or email fd at mkj dot lt) <ssh...lt>; ' (pbv62.internetdsl.tpnet.pl. PL)
asciilifeform: later on i'ma pull the drive & try guessing the magic params and writing'em in on other box. ☟︎
asciilifeform: literally doesn't need usb for ANYTHING but the config
a111: Logged on 2017-08-04 23:12 asciilifeform: it dun need replacement per se, was dead disk. i took the downtime as chance to try netbsd on same iron, when new disk came. iirc i explained this upstack.