← | Results 10501 ... 10750 found in all logged channels for 'f:diana' | →
(ossasepia) diana_coman: usually for kolhoz sort of thing they do as far as I saw
(ossasepia) diana_coman: about 500M downloaded
(ossasepia) diana_coman: probably, yes; though not necessarily longer than bmore takes to give you a box locally from what I understand
(ossasepia) diana_coman: asciilifeform: do you still plan to send a box to maxim/mivo?
(ossasepia) diana_coman: at any rate, if that's the problem, I'll set up an account for you on younghands or somewhere, lolz
(ossasepia) diana_coman: asciilifeform: why is that box so slow, I don't recall?
(ossasepia) diana_coman: asciilifeform: ok, downloading it
(ossasepia) diana_coman: crowncloud: are you there?
(ossasepia) diana_coman: myeah, I know.
(ossasepia) diana_coman: but I'm trying to keep those differences to a very minimum, ideally 0, ugh.
(ossasepia) diana_coman: sure, on my personal machine, I fuck the kernel whatever way I want; not same for non-personal machines though.
(ossasepia) diana_coman: asciilifeform: I don't think this is very sane though for non-personal machines; precisely because if every machine has to have different kernel conf than it's not all that reproducible
(ossasepia) diana_coman: (it's in my notes somewhere, will get to it when reproducing all stuff anyway)
(ossasepia) diana_coman: iirc there was the need to downgrade via companion or some such shit
(ossasepia) diana_coman: if anything, it would help to check that an FG works well
(ossasepia) diana_coman: so no, not using anymore either
(ossasepia) diana_coman: well, not after the discussion and conclusion, no? otherwise what use is to discuss and conclude, lol
(ossasepia) diana_coman: asciilifeform: I thought iptables was deemed utterly un-necessary?
(ossasepia) diana_coman: thimbronion: was my own text on the role of feelings clearer/easier for you than hanbot's?
(ossasepia) diana_coman: so prolly it will take ~same anyway
(ossasepia) diana_coman: asciilifeform: I didn't set up any, uhm.
(ossasepia) diana_coman: thimbronion: answered.
(ossasepia) diana_coman: asciilifeform: ok, thanks.
(ossasepia) diana_coman: so there is some support to "will work on various amd platforms"
(ossasepia) diana_coman: fwiw at least the recipe worked with same results on a 2nd amd on a gigabyte board
(ossasepia) diana_coman: I did precisely the remount earlier but anyway, didn't fix python otherwise so didn't really want to go ahead with all the rest on it as it is
(ossasepia) diana_coman: asciilifeform: all right; what's the eta re new tarball?
(ossasepia) diana_coman: it but that's your goal, sure.
(ossasepia) diana_coman: whaack: morning; programming ~= controlling computers and if you want to do crypto, you kind of need to actually control your hardware so unless you have something other than existing computers, you need to know stuff around crypto itself as well; that being said, there's no problem in saying that your interest is in crypto really and that's it; ie you will learn anything else you need for & around
(ossasepia) diana_coman: ah, ok re gpt.
(ossasepia) diana_coman: asciilifeform: I was rather surprised at using gpt tbh; and why do you start first partition at 64?
(ossasepia) diana_coman: I'll be away for about 30 minutes and then back at console
(ossasepia) diana_coman: asciilifeform: well, eulora server is a bit of a different thing, hence rather not send unless have-to
(ossasepia) diana_coman: asciilifeform: this is why I'm installing dulaps, no?
(ossasepia) diana_coman: and my backups are of smg data, not of the system
(ossasepia) diana_coman: asciilifeform: the idea is/was that if I'm fine with the backups I have, then disks get destroyed, not sent about
(ossasepia) diana_coman: meanwhile it's on my to-check list, hence ?!
(ossasepia) diana_coman: then again, eulora doesn't actually use any python as such
(ossasepia) diana_coman: asciilifeform: I don't recall having to fix python, no
(ossasepia) diana_coman: morning asciilifeform ; let me know what you find; I'll be around
(ossasepia) diana_coman: at least remount works fine so hm
(ossasepia) diana_coman: mk, I added to boot line rootfstype=ext4 and that at least got read of trying to mount it as ext3; onth, it's STILL read-only, grrr
(ossasepia) diana_coman: I don't get why it's trying to mount it as ext3; fstab clearly say ext4 for /dev/sda2, ugh
(ossasepia) diana_coman: asciilifeform: hm, apparently the recipe though results in / mounted as read-only ?!
(trilema) diana_coman: fwiw: eselect python list shows 3.5 in use and indeed a 2.7 as fallback.
(trilema) diana_coman: asciilifeform: python version on dulap is 3.5.4 though or what happened here?!
(trilema) diana_coman: ah, krankendenken got switched in place in private subscribes too, yee; thank you spyked.
(ossasepia) diana_coman: the sort of thing that works way better when not totally tired like yest.
(ossasepia) diana_coman: and I tweaked an option at kernel compile time so my usual kbd works as well, lolz.
(ossasepia) diana_coman: asciilifeform: done, booted successfully, I'll have to still check everything but will run it also on at least one more amd today
(trilema) diana_coman: so at least one amd successfully en-dulapped
(trilema) diana_coman: asciilifeform: can happily report success on the very same amd fx !
(ossasepia) diana_coman: asciilifeform: thank you for the updated recipe, I'll try it out today.
(ossasepia) diana_coman: whaack: happily for you this time, the post is indeed a list of your interests, not a revision of the previous post, no; outline at this stage sounds ok but it's hard to say much on it at that level (other than you seem perhaps to overwork the classification before you even got in clear exactly what content you have; it generally works the other way around)
(ossasepia) diana_coman: asciilifeform: it will have to be laters/tomorrow
(ossasepia) diana_coman: where the fuck was that legacy thing in this bios, arrgh
(ossasepia) diana_coman: asciilifeform: fwiw indeed yes, sata IS set to ahci mode
(ossasepia) diana_coman will have to go in 5 minutes so after that
(ossasepia) diana_coman: let me run dmesg, 1 min
(ossasepia) diana_coman: wtf can't quite find the thing; the motherboard is Asus M5A78L-M PLUS/USB3 HDMI Motherboard; the cpu is AMD FX-8350 Eight Core to 4.2GHz
(ossasepia) diana_coman: lemme fish out full spec
(ossasepia) diana_coman: lemme boot and look
(ossasepia) diana_coman: I'd need to look, I don't remember for this box
(ossasepia) diana_coman: asciilifeform: seems dubious that it says just "in ."
(ossasepia) diana_coman: Could not find the root block device in .
(ossasepia) diana_coman: and then the filesystem ounted at /dev/sda2 does not appear to be a valid /, try again
(ossasepia) diana_coman: Using mount -t auto -o ro
(ossasepia) diana_coman: it goes mounting /dev/sda2 as root....
(ossasepia) diana_coman: took stick out and booted, same trouble
(ossasepia) diana_coman: ugh, still same; I chrooted, changed in lilo.conf to have LBA32 instead of linear; ran lilo; this time indeed there was no more warning re this (there was still one re video adapter but that doesn't matter really)
(ossasepia) diana_coman: asciilifeform: ah, so that might be it; it's 1TB
(ossasepia) diana_coman: asciilifeform: stick removed, yes
(ossasepia) diana_coman: let me see re lba2
(ossasepia) diana_coman: asciilifeform: fixed fstab, yes; at least the usb stick is still working so running lilo was not the problem there
(ossasepia) diana_coman: rebooted: the image label is correct ie lilo seems fine; but still same problem re /dev/sda2 does not appear to be a valid /
(ossasepia) diana_coman: "linear is deprecated in favor of LBA32: LINEAR specifies 24-bit disk addresses below the 1024 cylinder limit; LBA32 specifies 32-bit disk addresses not subject to cylinder limits on systems with EDD-BIOS extensions; "
(ossasepia) diana_coman: lilo ran fine; there is still the warning re LINEAR vs LBA32
(ossasepia) diana_coman: ok, now it worked
(ossasepia) diana_coman: asciilifeform: ah, no; /me tired indeed; I've changed the label because I wanted to be able to see that it uses this indeed but I forgot to change the default too, derp.
(ossasepia) diana_coman: hm, I don't see a default line in lilo.conf, should there be one?
(ossasepia) diana_coman: asciilifeform: it's literally just that; it says Added GentooDulap and then Default image doesn't exist
(ossasepia) diana_coman: uhm; now it says fatal: default image doesn't exist; I think I might be getting too tired for this
(ossasepia) diana_coman: well, I suppose I can execute lilo and see if it nukes this second drive too, lol
(ossasepia) diana_coman: there is no other drive (/me wanted to keep it simple)
(ossasepia) diana_coman: asciilifeform: the usb stick is in usb port; the hard drive is main drive, sata
(ossasepia) diana_coman: asciilifeform: hm?
(ossasepia) diana_coman: it was; hence why I don't quite get this part
(ossasepia) diana_coman: asciilifeform: I booted from usb stick; usb stick is still sdb, yes
(ossasepia) diana_coman: asciilifeform: what I don't get though: current lilo.conf has boot = /dev/sda which is in fact correct; the usb stick is /dev/sdb
(ossasepia) diana_coman: ok; booted now again from usb stick, let me see
(ossasepia) diana_coman: asciilifeform: myeah, it does not; sigh.
(ossasepia) diana_coman: hm; let me try first and see if it boots, can't hurt anyway
(ossasepia) diana_coman: asciilifeform: so what do you suggest now?
(ossasepia) diana_coman: asciilifeform: do I need to do anything else before rebooting?
(ossasepia) diana_coman: ok, new stick is ready, booted on it; mounted /dev/sda2 and changed that reiserfs to ext4
(ossasepia) diana_coman: the image is 2.2G so apparently dd takes a while
(ossasepia) diana_coman: imaging now another stick anyway
(ossasepia) diana_coman: the shell I got mounted in read-only the /
(ossasepia) diana_coman: asciilifeform: the kernel was written fine, I could even check now
(ossasepia) diana_coman: neah, it didn't; at most I might have fatfingered it at some point and shot it; but no, I won't reimage *this one* now, just another one; this will wait to be looked at.
(ossasepia) diana_coman: uhm, wtf, the stick is shot *right now*; wtf; mk, I'll go and write another one + set this to be looked at.
(ossasepia) diana_coman: it would be rather weird but anyway; kk, let's check it...
(ossasepia) diana_coman: asciilifeform: no; but hm, I should check the disk, makes sense
(ossasepia) diana_coman: asciilifeform: any idea?
(ossasepia) diana_coman: gah, now it won't boot from the stick anymore and the shell from the failed thing doesn't mount /dev/sdb2 to change the fstab, ofc
(ossasepia) diana_coman: I'll take a break too.
(ossasepia) diana_coman: so I had it right, except the shell I got did not manage to write the actual file, ugh; so I need to boot now from the stick.
(ossasepia) diana_coman: atm fighting it a bit to boot from stick rather than disk, lol
(ossasepia) diana_coman: uhm, even a stop on the browser should do it; depends what you are using exactly
(ossasepia) diana_coman: cut it out and it will load
(ossasepia) diana_coman: asciilifeform: re paste.deedbot.org it's just that style sheet
(ossasepia) diana_coman: asciilifeform: link?
(ossasepia) diana_coman: that's not enough, is it
(ossasepia) diana_coman: I can get a shell
(ossasepia) diana_coman: ugh; asciilifeform mind pasting an example of how fstab should look like for the partitions you gave? apparently I didn't get it right or there's more to it
(ossasepia) diana_coman: asciilifeform: I took out the usb stick
(ossasepia) diana_coman: ps kbd to the rescue
(ossasepia) diana_coman: wait, I need the kbd first to edit fstab, lol
(ossasepia) diana_coman: but hm, my usb kbd is indeed not working, lol
(ossasepia) diana_coman: mk, back to it
(ossasepia) diana_coman: hm, fstab comes to mind
(ossasepia) diana_coman: asciilifeform: ugh, boot failed with filesystem mounted at /dev/sda2 does not appear to be valid /
(ossasepia) diana_coman: asciilifeform: uhm, just a bit ago you lashed out that "people not replicating asciilifeform's magic irons"
(ossasepia) diana_coman: asciilifeform: tbh I wanted to ask "why not script" but anyway.
(ossasepia) diana_coman: lilo worked although it still whined about linear
(ossasepia) diana_coman: they seem to be there; lemme document + move on
(ossasepia) diana_coman: and now there is an initramfs in /boot too, let's see
(ossasepia) diana_coman: well, at least it compiled now; it has a warning that additional kernel cmdline arguments may be required ie rootfstype=ext3
(ossasepia) diana_coman: I don't see further --no to add, but we'll see
(ossasepia) diana_coman: if I'm at that I added --no-btrfs too, just-in-case.
(ossasepia) diana_coman: dunno, I've made this bootable stick a while ago when I was trying out Cuntoo really
(ossasepia) diana_coman: lemme try with that, again
(ossasepia) diana_coman: there is a --no-zfs
(ossasepia) diana_coman: 1 min, I'll get a paste out of it
(ossasepia) diana_coman: it's using config with right name at least ie Dulap-III
(ossasepia) diana_coman: ah, first might need to plug in the network, lolz
(ossasepia) diana_coman: lemme see on that iron, 1 min
(ossasepia) diana_coman: ugh, wtf was it
(ossasepia) diana_coman: iirc there was a way to ask no zfs
(ossasepia) diana_coman: I booted from a usb stick, gentoo live cd
(ossasepia) diana_coman: asciilifeform: hm?
(ossasepia) diana_coman: this is what the thing says, what can I do.
(ossasepia) diana_coman: asciilifeform: and it failed with: binary /sbin/mount.zfs could not be found
(ossasepia) diana_coman: neah, I'm fine with lilo
(ossasepia) diana_coman: anyways the compile seems like it will take a bit so I'll get back when it's done.
(ossasepia) diana_coman: myeah; and now I'll have to change the lilo.conf back too, lolz.
(ossasepia) diana_coman: rather less informative re activity than the earlier make but whatevs
(ossasepia) diana_coman: asciilifeform: fwiw it is indeed compiling now the correctly-named bzImage
(ossasepia) diana_coman: so then why all the ps stuff in the config as far as I see? anyway, not a big thing either way
(ossasepia) diana_coman: well, atm I'm not using a ps keyboard so prolly *that* will fail in the end but it's not a huge thing, I can rummage for a ps keyboard afterwards
(ossasepia) diana_coman: it's not raid, no; nothing special really.
(ossasepia) diana_coman: at least without adapting the config
(ossasepia) diana_coman: I will not modify the config though because the whole idea was to test that indeed "can just work on any amd"
(ossasepia) diana_coman: ok, let me see then
(ossasepia) diana_coman: ugh; now since I started the make...
(ossasepia) diana_coman: asciilifeform: so wait, do I need to do that or what/
(ossasepia) diana_coman: asciilifeform: the part I don't get mainly is why no initramfs in /build
(ossasepia) diana_coman: anyways, it will recompile, let's see
(ossasepia) diana_coman: asciilifeform: realise that 1. I am simply stating the grief, as you asked 2. I am pointing re recompile because earlier in #t you went "no" when I said http://logs.ossasepia.com/log/trilema/2019-10-11#1944905
(ossasepia) diana_coman: well, I didn't change it, but apparently the make anyway proceeded to recompile
(ossasepia) diana_coman: but at any rate, I am therefore recompiling it, no?
(ossasepia) diana_coman: ok, let me try that
(ossasepia) diana_coman: asciilifeform: ftr I had to correct/adapt the parted too because it complained it was not aligned and then it failed really.
(ossasepia) diana_coman: asciilifeform: it seems to copy ie the vmlinuz but no initramfs; and if I changed lilo.conf to point to existing name of kernel that part went through but got stuck because no initramfs
(ossasepia) diana_coman: as a side note: it also complains about linear instead of lba32
(ossasepia) diana_coman: asciilifeform: if I just run make install as per step 3-17D it fails because it can't find the image it expects (kernel-genkernel-...) ; in /boot if I look there is instead a vmlinuz-4.14.7-gentooDulap-III and no initramfs either though lilo.conf seems to expect one
(ossasepia) diana_coman: thimbronion: unless you are done with all the rest of stuff you can do atm, I'd say leave it for now with that default option and get back to it later.
(ossasepia) diana_coman: thimbronion: myeah, so it is what I think it is but I can't recall for the life of me the magic incantation and I have just taken out the hdd with all sorts including the notes on this, argh
(ossasepia) diana_coman: earlier I had done it on a diff machine but there were all sorts of grief
(ossasepia) diana_coman: asciilifeform: I see; fwiw atm I'm trying to go again through those dulap-instructions to put on an amd fx-8350, writing down everything
(ossasepia) diana_coman: the default setting is to make them look like thimbron.com/?page=smth ; the permalinks are used if you want anything else, namely some more informative url such as date/name
(ossasepia) diana_coman: thimbronion: in the blog's dashboard you have at settings the option as to what the links for posts should look like
(ossasepia) diana_coman: it has some conf files too, don't quite recall all+order off the top of my head
(ossasepia) diana_coman: thimbronion: that looks ok; do you have Apahche set to allow the rewrite though?
(ossasepia) diana_coman: or otherwise your file/folder permissions are not fully set correctly, iirc centos had another requirement after chmod
(ossasepia) diana_coman: because if it does, then you either don't have rewrite allowed and/or correct .htaccess
(ossasepia) diana_coman: thimbronion: does it work if you set the format to that default ?page bla?
(ossasepia) diana_coman: ah, darn, I have my notes for that but not at hand right now
(ossasepia) diana_coman: thimbronion: what OS are you running there?
(ossasepia) diana_coman: thimbronion: the links trouble might be a matter of the permalinks and/or permissions not set properly
(ossasepia) diana_coman: thimbronion: the error logs sound like some php version trouble
(trilema) diana_coman: mp_en_viaje: yes; I'll start today and hopefully it won't take *that* long (no real idea though).
(trilema) diana_coman: this freenode-issue is to my eyes quite close to the isp-issue really
(trilema) diana_coman: mp_en_viaje: I'll run it, as promised on all amd around, at the very least; will at least have *something* to say after that, I guess.
(trilema) diana_coman: asciilifeform: why do you keep going on about the FG. Nobody said the FG were the trouble, wtf.
(trilema) diana_coman: mp_en_viaje: I am hesitating re my exhaustion because I'm not sure that is much of a measure otherwise; sure, I can and will try it at least on what I already have and if it works, there is at least that data.
(trilema) diana_coman: now ofc how the fuck to "test to exhaustion" here, not like I have the full range of amd and I'm not living in a dc either, ugh.
(ossasepia) diana_coman: nobody can let you know upfront what it *will be*; in general
(ossasepia) diana_coman: the vpatches let you know what the output hash *should be*
(trilema) diana_coman: asciilifeform: if I got this straight, you say the "specific" here is simply "any amd" , right?
(trilema) diana_coman: hm, I suppose now I'll have to test it on various amd I have around
(trilema) diana_coman: asciilifeform: eh, recompile kernel to fit that, at the very least, no?
(trilema) diana_coman: asciilifeform: yes, but I need to get precisely same hardware too, that opteron etc.
(ossasepia) diana_coman: myeah and exactly eliminating such ambiguity is one of the aims of V, really.
(ossasepia) diana_coman: oh boy, a trusting V
(trilema) diana_coman: mp_en_viaje: tbh the way I see it is that commercial enterprise may rely on "custom-made" only to the extent that it owns that production line since otherwise sooner or later it's bound to find itself stranded as far as I can tell.
(trilema) diana_coman: I suppose in the best-ideal-great path, I could say : map all dependencies and make the move to cuntoo but this is essentially taking on another mountain of work with unclear everything.
(trilema) diana_coman: so while I have backups of both production and test systems and code and all that, I don't really know what to aim for here exactly
(trilema) diana_coman: 4. previously, with pizarro, BOTH servers essentially ran on very specific, alf-made hardware + system
(trilema) diana_coman: 3. for as long as CS esp is not yet *fully* excised out of the dev/test server, that might *also * need non-Cuntoo
(trilema) diana_coman: 2. current production server will NOT run on cuntoo either, even if available (because still needs dynamic + CS & Cal3d that are iffy)
(trilema) diana_coman: 1. we don't actually have a running and tested + everything needed Cuntoo yet
(trilema) diana_coman: to give an idea of what's the issue here:
(trilema) diana_coman: mp_en_viaje: what shall we do with the s.mg servers hw+system-wise?
(ossasepia) diana_coman: fwiw I am not aware of any V version that just ignores the hashes but I can't say I know *all* versions there are; plus I can't tell from here what code you are running there.
(ossasepia) diana_coman: whaack: while you could ofc skip any and all steps, that sounds like a sort of "well, can as well not clean the boots *every day*", how should I put this
(ossasepia) diana_coman: whaack: at any rate: 1. you should be able to tell if your V uses keccak or sha512 2. you can even make a quick test ie pressing some old vpatches (iirc the trb ones are NOT keccak, still)
(ossasepia) diana_coman: so how does it know it patches the right thing if it doesn't check the hash?
(ossasepia) diana_coman: whaack: I doubt it really; and it's a matter of *what* to patch ie the hashes in the vpatch file are meant to *identify* the file
(ossasepia) diana_coman: whaack: to make it clear: the sig aka gpg use sha512 ; the vdiff uses keccak currently.
(ossasepia) diana_coman: whaack: indeed.
(ossasepia) diana_coman: whaack: so far so good: there are indeed 2 hashes used in 2 places for 2 different purposes.
(ossasepia) diana_coman: whaack: o.O what do you think the role of the hashes is there?
(ossasepia) diana_coman: asciilifeform: fwiw re dulap construction kit so far I think there are only a few missing bits at the mount cmds point 3-16C since the stuff is not in /mnt/usb directly but rather something like /mnt/usb/mnt/gentoo/dev etc
(trilema) diana_coman: girlattorney: for that matter you can see the logs of the chan too on any of the working loggers.
(trilema) diana_coman: girlattorney: younghands.club has it in the about page really; the thing is that this is not really the best place for any & all talk.
(trilema) diana_coman: girlattorney: maybe pop over in #o for a bit
(trilema) diana_coman: pretty much the first hurdle is wot and invoice via deedbot
(trilema) diana_coman: if he can't/won't do that, then the rest doesn't matter, there's no need to waste time
(trilema) diana_coman: girlattorney: the main thing is re interoperation with republican systems and standards
(trilema) diana_coman: if on the other hand he is busy with something else, there's no need to bother, let him do whatever he is busy with.
← | →
Download hourly DB snapshot | Get Source Code