log☇︎
86700+ entries in 0.046s
a111: Logged on 2018-07-12 04:23 trinque: other than that, I'd be curious why the hell the kernel wasn't capable of pulling an adult root up itself. usually this is because the kernel was again, built for allcomers, or more specifically for linux users afraid of configuring a kernel (present company excluded, of course). this ends.
asciilifeform: the uuid thing would not be needed then.
asciilifeform: bios bootsector loader certainly gives this info
asciilifeform: trinque: i was thinking, lilo oughta be able to be cured , to know what the hell it booted from on a given boot, and mount root there
trinque: build here meaning run the script, not hand-roll
a111: Logged on 2018-07-12 13:36 asciilifeform: 1 of the things i'd like to do, supposing trinque hasn't yet already made it, is to replace the horrid gui-laden boot usb stick currently in pizarro bilge, with a cuntoo stick.
trinque: http://btcbase.org/log/2018-07-12#1833783 << indeed, and users ought to be able to build own, so we've got a clear chain of custody going straight back into classical gentoo ☝︎
trinque: will need others, can't have too many
a111: Logged on 2018-07-12 13:32 asciilifeform: hats off to trinque , pretty great item. ( as i understand , we will still need a troo tmsr tarballs mirror, and coupla other things. but it's a good start, 100% musltronic gentoo. )
trinque: http://btcbase.org/log/2018-07-12#1833782 << mirror needed indeed. I have a pizarro box racked with giant platters for this ☝︎
trinque: (there are probably fixes also needed to the binpkg system, such that i.e. timestamps of the build are not in there, ruining bit-identity)
trinque: back on the bin-packages, these become much more interesting with a reproducible-build gcc. I understand ave1's to be very close, if not there already
trinque: /cuntoo dir is what I continue to work on. vtronic portage will sit in there. when released, diana_coman can replace the whole /cuntoo dir with the final item
asciilifeform: i left it as-is, in the interest of authenticity.
asciilifeform: however must note that it contains install.sh with asciilifeform's mistakes ( see log ) .
asciilifeform: diana_coman can delete if she needs the ~1GB .
a111: Logged on 2018-07-12 11:24 asciilifeform: hey trinque , is it safe to delete 'cuntoo' dir ( contains copy of distfiles, etc, could free ~1G ) or does it get used ?
trinque: http://btcbase.org/log/2018-07-12#1833743 << that dir is the infection vector, and builds packages so infection can be swift. packages can be deleted, and perhaps distfiles too if the user is going to keep them elsewhere (i.e. off box) ☝︎
trinque: this and the number of cpus, and perhaps others as args, yes
mod6: ^ that'd be cool, then can have both ways
asciilifeform: really oughta be toggleable imho.
a111: Logged on 2018-07-12 11:36 asciilifeform: trinque's original also does something i consider ugly, it allows lilo to refer to disks/partitions by 'uuid' rather than device path, imho this should not be done ( it resembles poettering's warcrime against nic device names, and makes hand-tuning needlessly difficult )
trinque: http://btcbase.org/log/2018-07-12#1833748 << this I did to allow building the system as a USB-attached external drive, which could later be plugged in as primary hd and still boot. recall I started my gentoo experiments with "infectious gentoo" as a target ☝︎
BingoBoingo: Anyone care to guess what refrigerant is coursing through the new Panavox 100 liter fridge Carlos Gutiarrez just dropped off?
asciilifeform: ( granted, nobody actually knows, these folx are fold of printing identical legend and keeping same vendor:usbid while fiddling something or other )
asciilifeform: BingoBoingo: interesting. these are both chinese pl2303 , nominally identical.
BingoBoingo: On this box one of the FG cables is the blue guy that came with my personal FG, the other is the new style black snake ☟︎
asciilifeform: diana_coman: ty for putting it in the log, i'd like to find the answer to the riddle.
asciilifeform: ( btw if anybody discovers a viable replacement for the pl2303 snake that dun cost an arm and leg and dun include flashable chips, i'd like to hear about it )
diana_coman: asciilifeform, yes, I will certainly carry out the tests ofc but this was what I observed atm
asciilifeform: ( above 7, pl2303 driver starts doing something odd, the boxes still work but several times slower )
asciilifeform: i've operated up to 7 on 1 linux box simultaneously , without problems ( the linux usb tweak from section 2 of operating manual http://nosuchlabs.com/hardware.html is required if using 3 or greater )
asciilifeform: i have my box set to stty... both on boot, so i never observed this effect. possible quirk of the pl2302 driver. i recommend , as in any battlefield installation of FG, to carry out the s.nsa-recced tests.
diana_coman: yes, now they both work, hence my wtf
asciilifeform: diana_coman: we'll have to ask BingoBoingo to open the lid and inspect the lights on both FG .
diana_coman: brazilish, register a key if you want to be any sort of person around here
diana_coman: nope, no such thing as usual brazilian guy
diana_coman: asciilifeform, BingoBoingo access to box & config confirmed; FG on ttysUSB0 had a wobble at first and I don't understand why: I ran the stty -F /dev/ttyUSB0 115200 raw -echo -echoe -echok and then tried dd iflag=fullblock if=/dev/ttyUSB0 | hexdump -C but nothing came up; then I ran the stty on usb1 as well and tried again and it...worked; any idea wtf was that at first? ☟︎
asciilifeform: i wasn't aware that we had one ?
asciilifeform: but possibly this oughta wait for trinque's return and for the remaining fine-tunings to cuntoo .
asciilifeform: 1 of the things i'd like to do, supposing trinque hasn't yet already made it, is to replace the horrid gui-laden boot usb stick currently in pizarro bilge, with a cuntoo stick. ☟︎
asciilifeform: hats off to trinque , pretty great item. ( as i understand , we will still need a troo tmsr tarballs mirror, and coupla other things. but it's a good start, 100% musltronic gentoo. ) ☟︎
asciilifeform looking forward to building some cuntoo boxen for own experiments.
asciilifeform: BingoBoingo: when diana_coman gives the signal that box is good to work, can remove kvm snakes and boot stick.
BingoBoingo: Do my hands need to do anything to the box? Unplug things, etc?
BingoBoingo waiting for a refrigerator to show up
asciilifeform: diana_coman: at the risk of pedantry -- all of the pasted items, other than (4) , exist on your box's disk , exactly as pasted.
asciilifeform: ( afaik this is the first battlefield test of cuntoo. )
asciilifeform: i expect that trinque will find this thread to be of interest, when he comes back.
asciilifeform: diana_coman: aite. do not hesitate to ask, if the purpose of particular change , or anything else, is unclear.
diana_coman: yes, hence my "I get it that some parts were of public interest too but they can be discussed anyway, with ref to a paste of the stuff if needed "
diana_coman: re vtools fwiw I pressed it fine with traditional vtron
asciilifeform: diana_coman: remember, we are also helping trinque to perfect his cuntoo .
diana_coman: asciilifeform, will do; atm I'm gathering all the stuff from the log; wouldn't it make more sense next time to just send it together with access stuff? I get it that some parts were of public interest too but they can be discussed anyway, with ref to a paste of the stuff if needed
asciilifeform: diana_coman: lemme know if box functions as expected. you will prolly want to install ave1's gnat . but even prior to this, can proceed with emerging eulora deps , and see which ones work under muslism .
asciilifeform: diana_coman: possibly i'm mistaken , will have to actually try the new vtool ( and whether it can be pressed with traditional vtron ) .
asciilifeform: aa lol i forgot . diana_coman feel free to switch it.
diana_coman: ah, you usually use your name so it's first time it saw your nick, hence -> moderating
diana_coman: asciilifeform, it's on, you wrote it while I was writing mine and it got into the moderating queue
asciilifeform submitted comment re above, but i think filter ate it ?
ave1: Some thought about the zero footprint / minimal runtime image.
asciilifeform: diana_coman: http://p.bvulpes.com/pastes/uISuj/?raw=true and plz to confirm.
asciilifeform: 8) the kernel trinque's system ended up building, is preserved in /boot/bk . it boots, but dun see nic or FG, on account of rejecting modulism
asciilifeform: 5) nic config is in /etc/conf.d/net and /etc/resolv.conf , if diana_coman wants to change the former for any reason plz talk to pizarro folk 1st
asciilifeform: ( i dun blame trinque , afaik this is default lilo behaviour nowadays ) but i fixed.
asciilifeform: trinque's original also does something i consider ugly, it allows lilo to refer to disks/partitions by 'uuid' rather than device path, imho this should not be done ( it resembles poettering's warcrime against nic device names, and makes hand-tuning needlessly difficult ) ☟︎
asciilifeform: (3) contains 2 mistakes by asciilifeform re partition map; ergo , i wrote a 4) http://p.bvulpes.com/pastes/A94DS/?raw=true << install-corrected.sh << which reflects necessary changes to partition map ( and removes the console-via-rs232 that remained from trinque's orig experiment )
asciilifeform: 3) http://p.bvulpes.com/pastes/7JDg0/?raw=true << install.sh that was actually used to build the whole orchestra;
asciilifeform: hey trinque , is it safe to delete 'cuntoo' dir ( contains copy of distfiles, etc, could free ~1G ) or does it get used ? ☟︎
asciilifeform: are hardbaked into kernel. trinque as i understand is working on an automatic process for this.
asciilifeform: the 1 non-trinquian component is the kernel, which is bitwise identical to what is on 1) dulap 2) the primary s.mg box. fortunately kernel carries own libc, musltronicity dun affect it. but the trinquian kernel src and my original config is still there, as well as my config for the iron; it is possible for diana_coman to later build the kernel with trinque's gcc, what is needed is to transform my config so that all necessary modules
asciilifeform: trinque's gcc, btw, is exactly as was printed on the crate, x86_64-gentoo-linux-musl 4.9.4 ☟︎
diana_coman: cool, will wait for the summary + access then
a111: Logged on 2018-07-11 22:08 hanbot: http://btcbase.org/log/2018-07-11#1833385 << diana_coman that's a good point; added a note on said post. and y'know, you can just tell me directly, "hey, this is dumb, do x".
diana_coman: http://btcbase.org/log/2018-07-11#1833586 <- need to practice this moar ☝︎
diana_coman: asciilifeform, re ssh key, pizarro already has mine, just use that one; re box: I've read through the logs and in the end I'm still confused as to *what* is in there now - is it musltronic system or not?
mircea_popescu: incidentally... i can't fucking believe the 2010s failed to produce a pornstar named justine beaver.
trinque: thx for trying the item!
asciilifeform: goodnight trinque
asciilifeform: that could be anyffing tho
trinque: will take build machine's /proc/config.gz and cement
trinque: oh, this exists, and is going into my post
asciilifeform: say, builds modular kernel once, then lsmod, parse output, then builds cemented kernel with same parts.
asciilifeform: nah, simpler, would use existing mechanism that loads modules
trinque: some kind of gcov thing?
asciilifeform: i.e. 'this dun run, the pertinent iron aint there'
asciilifeform: 1 very useful thing, that we dun have yet, would be a mechanism for unerringly pointing out deadcoad in a given running kernel.
trinque: so, can install busybox this way, user hand-rolls a script (perhaps from template), and this is as much initramfs as anyone oughta need
trinque: I do in fact have an initramfs tool also sitting on desk. portage makes it rather easy to blast ebuilds into an arbitrary chroot at install
asciilifeform: in the end there is no compelling reason to have modulism on box where iron dev aint happening.
trinque has a kernel baking post coming soon, in response to PeterL
asciilifeform: trinque: i have no prob with your 'cemented' approach to kernel, it is Right Thing; mine simply not caught up yet ( december 2017 build )
trinque: asciilifeform: looking forward to your feedback on the thing, which we'll work into a final product
trinque: other than that, I'd be curious why the hell the kernel wasn't capable of pulling an adult root up itself. usually this is because the kernel was again, built for allcomers, or more specifically for linux users afraid of configuring a kernel (present company excluded, of course). this ends. ☟︎
trinque: as for initramfs-ism, it has its place (i.e. embedded systems with peculiar root, squashfs + overlayfs or the like)
trinque: not bad for running to a flight hours later
trinque: but aside that, pretty fucking cool you stood the thing up, as it was a scrape of my workbench into tarball and sig
trinque: seems upon the man building the kernel for allcomers to justify himself, as my kernels are narrower
a111: Logged on 2018-07-11 22:55 asciilifeform: trinque: lemme get this straight, your script does 0 with kernel modules ? expectation is that there ain't any ?
trinque: http://btcbase.org/log/2018-07-11#1833642 << I am racist against modulism, as long expressed and explicit in the script ☝︎