feedbot: http://trilema.com/2019/angels-with-dirty-faces-2/ << Trilema -- Angels with Dirty Faces
asciilifeform: mircea_popescu: i translated the chinesium, it's 100% snoar, some kinda fiatological dark-age #b-a
mircea_popescu: i got ~same impression.
asciilifeform: 20y ago it was still possib to hear something interesting at a linux usergroup ( asciilifeform , for instance, in iirc 2004 went to local 1 and met a half-mad greybeard who 'mark my words, nsa boobytraps in the nic bios' , 1st mention in asciilifeform's memory of subj ) but certainly not today.
asciilifeform: today -- prolly they discuss which ver of systemd to use.
mircea_popescu: hey, i recall a time in the 90s irc was for dating. fulla exactly the kinda gal you'd like to meet, bash & fuck on 1st "date".
asciilifeform: prolly this was back when black sea was still swimmable in..
mircea_popescu: certainly.
BingoBoingo: <asciilifeform> today -- prolly they discuss which ver of systemd to use. << Nah, more likely they discuss how great the version they are ordered to use is
mircea_popescu: "il net e multo peggiorato" "ufa! de maniera verticale!" to pastiche sorrentino
mircea_popescu: btw, spyked lobbes either of you feel like implementing a http://btcbase.org/log/2019-03-04#1900358 thing ?
a111: Logged on 2019-03-04 19:29 mircea_popescu: https://img.vim-cn.com/ << check them out. we prolly want something like this actually huh.
mircea_popescu: minus the "Alipay and Wechat Pay are supported currently:" shockingly idiotic bs, of course.
mircea_popescu: if volume is a concern, can limit it to so many bytes / time interval / ip. add command to your bot to whitelist ips by their being claimed by l2 people, then you can even invoice them.
feedbot: http://trilema.com/2019/minigame-smg-february-2019-statement/ << Trilema -- MiniGame (S.MG), February 2019 Statement
hanbot: so check this out: on new attempt to run cuntoo bootstrap.sh, i get this error: "umount: invalid option -- 'R'". whereas man umount shows no uppercase R option (lowercase r makes sense, remount read-only). and moreover, first bootstrap.sh run moved past this no prob, not like the script *changed*, wth?
mircea_popescu: hanbot -R is recursive unmount.
mircea_popescu: possible you ran it previously (when it worked) on an unmount that supports -R ? whereas the one using now doesn't ?
hanbot: 0.o
mircea_popescu: mount -V
hanbot: mount from util-linux 2.22.1 (libmount 2.22.0: debug)
mircea_popescu: iirc only introduced recently-ish.
mircea_popescu: come to think of it, prolly also requires root. are you not root ?
hanbot: mircea_popescu am root
mircea_popescu: hanbot anyway, the same effect can be obtained by simply umount-ing all the partitions.
hanbot: aite. ty!
lobbesbot: !!up lobbes_field
deedbot: lobbes_field voiced for 30 minutes.
feedbot: http://trilema.com/2019/luci-del-varieta/ << Trilema -- Luci del varieta
lobbes_field: http://btcbase.org/log/2019-03-05#1900506 << sadly, I've got a neglected hopper to attend to first
a111: Logged on 2019-03-05 18:23 mircea_popescu: btw, spyked lobbes either of you feel like implementing a http://btcbase.org/log/2019-03-04#1900358 thing ?
lobbes_field: To update: Now that I have a bootable Cuntoo, a hand-rolled Gentoo, and a proper keccak v setup (with ave1-gnat), the only item left in my 'remedial' hopper is to read and sign Spyked's keccak regrind of logbot_command_router_python >> http://blog.lobbesblog.com/2019/01/hopper-update-january-2019/
lobbes_field: Then, I'm back to attacking http://blog.lobbesblog.com/2018/11/conveyor-outlook-now-to-feb-2019/ (which, I've -completely- missed my deadline on)
lobbes_field back to meat
lobbesbot: !!down lobbes_field
deedbot: lobbesbot may not $down lobbes_field.
hanbot: continuing my mounting woes, i can't unmount sdb3 partition on target drive from initial cuntoo bootstrap.sh (target is busy); offending process from 'lsof | grep sdb3' looks like /proc/4693/exe ("txt, unknown"), no response from kill -9, no idea how it zombied out or why, what am i gonna do?
hanbot: ps -aux | grep sdb3 meanwhile lists pid 4693, [jbd2/sdb3-8]
mircea_popescu: asciilifeform btw, were you saying you can't find write-only sdcards ?
mircea_popescu: hanbot do you have a file open somewhere ?
hanbot: nop. i'm running screen but screen -ls shows 1 socket.
mircea_popescu: hanbot cat /proc/4693/status says what ?
feedbot: http://pizarroisp.net/2019/03/05/pizarro-february-2019-report/ << PizarroISP -- Pizarro February 2019 Report
hanbot: mircea_popescu p.bvulpes.com/pastes/YtSVG/?raw=true
mircea_popescu: should show the parent. basically, the way this whole thing works is as follows : 1. linux is organized around "processes", which are a sort of agents let's say. they're listed in /proc/ ; 2. any process can spawn other processes, the whole menagerie's spawned by the kernel (which in systemd thing is also process 1, hence the whole http://btcbase.org/log/2018-10-19#1863880 thing ). 3. a process can close, or be terminated, ki
a111: Logged on 2018-10-19 01:52 mircea_popescu: provided of course "pid eins" is somehow involved also.
mircea_popescu: lled, whatever, at which point its parent, ie, whoever spawned it, waits on it and cleans it up. 4. until such a thing happens, the ~process table~ still lists it, even though it is no longer able to ~do~ anything. this is a "zombie", process existing in listings only, not yet cleaned up by its parent. (it can, unfortunately, block unmounting).
mircea_popescu: so your thing here is to figure out who the fuck is the parent, why the fuck is it not cleaning up its dead kids, and possibly kill it too, and it's stupid father in turn until presumably you end up with the kernel which WILL clean them all up.
mircea_popescu: does that make any sense ?
mircea_popescu: from the other pov, the jbd2/sdb3-8 thing is typically the kernel doing journalling.
asciilifeform: http://btcbase.org/log/2019-03-05#1900534 << lol, ~read~ only. did find that there's a supposedly-write-once ro bit that one can set ( appears to work, but naturally i've no way to verify that there aint a magick undocumented sequence that resets it somehow )
a111: Logged on 2019-03-05 20:42 mircea_popescu: asciilifeform btw, were you saying you can't find write-only sdcards ?
mircea_popescu: asciilifeform i have a bunch here, which have a tab! you switch it to permit writing or not!
mircea_popescu: like ye olde diskettes!
asciilifeform: mircea_popescu: they all have the tab. the behaviour relies on the reader tho, not the card
hanbot: mircea_popescu yes, makes sense. quandry is whether figuring out process lineage or ordering reboot and re-prepping for bootstrap will take the larger amt of time, but then former path comes with figuring out new (to me) shit, so...prolly best.
asciilifeform: and most baked-into-iron readers seem to ignore the rw line
mircea_popescu: asciilifeform ah
mircea_popescu: hanbot tried umount -f (force) ?
mircea_popescu: asciilifeform i didn't dig into it, but noticed the little tab looking at them. now that i think about it, i seem to recall this was actually discussed in log.
hanbot: mircea_popescu i haven't, based on noting various unknown webderps reporting it hung/killed their session
mircea_popescu: i dunno anything else you could try instead of a reboot anyway.
mircea_popescu: honestly a sane box should not end up in the state you described, short of doing things to it like alf's easy bake oven.
asciilifeform: mircea_popescu: aha in log, http://btcbase.org/log/2018-05-17#1814763 , possib. elsewhere
a111: Logged on 2018-05-17 15:34 asciilifeform: ( and, lulzily, classical sd card ~does not support write protect~, it has the same usg.nonsensical 'software read writeprotect tab' as old floppies )
asciilifeform brb,meats
mircea_popescu: meanwhile in even more http://btcbase.org/log/2019-03-01#1900068 lulz : turns out, i fucking had it also.
a111: Logged on 2019-03-01 23:04 mircea_popescu: meanwhile in other http://btcbase.org/log/2019-01-25#1889862 slash http://btcbase.org/log/2014-12-08#948046 lulz : the dork i used above for a source for the commie radio pictures (not that he originates them, they actually come from http://www.latrecut.ro/2006/05/ric-stramoshul-ipod-ului/ which is significantlly better contextually, but I was lazy) not only passes himself as a "Ministrul Cyberculturii | Recenzii, cronici, cr
mircea_popescu: this laziness.
feedbot: http://qntra.net/2019/03/rsas-shamir-did-not-receive-us-visa-for-rsa-conference/ << Qntra -- RSA's Shamir Did Not Receive US Visa For "RSA Conference"
trinque: hanbot: the reason for the recursive unmount is that the build mounts /proc /dev and /sys in the build target
trinque: these have to be unmounted from within build dir before umounting build
trinque: could try umount build/*; umount build
trinque: the script runs this umount for you at the beginning of each attempt to clean up after any prior build attempt. it wont bother with the umounts if they're already gone.
trinque: mod6: ack, handled
trinque: also congrats on your cuntoo boot
trinque: in related news, I have trashed my cuntoo build drive with repeated builds!
trinque goes to procure another
trinque: lets all plan on smashing through this path bug in the vpatch this weekend. I'll be available for it.
trinque: df -h
trinque: pffflol
mod6: trinque: thx! and yah, it was nice to get that going.
mod6: I'll do what I can this weekend, time-permitting.
mod6: Just let me know.
trinque: I'd like to get it done saturday afternoon if that works.
mod6: My availability is pretty limited that day, during the day. Probably will be around later that evening, or more for sure on Sunday.
mod6: Eitherway, I'll read logs and catch up if you proceed without me, of course.