mircea_popescu: well, that linuxba thing turned out to be pretty retarded.
mircea_popescu: the more patient sinophiles are invited to squeeze the rock for butter at their leisure, my interest's exhausted.
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".
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
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.
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: possible you ran it previously (when it worked) on an unmount that supports -R ? whereas the one using now doesn't ?
hanbot: mount from util-linux 2.22.1 (libmount 2.22.0: debug)
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.
deedbot: lobbes_field voiced for 30 minutes.
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 ?
☟︎ hanbot: nop. i'm running screen but screen -ls shows 1 socket.
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: from the other pov, the jbd2/sdb3-8 thing is typically the kernel doing journalling.
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!
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.
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.
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 )
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.