Young Hands
1h 42m2h 20m4h 5m7h 53m1d 16h 37m12h 25m2h

diana_coman: crowncloud_: how about that server?
diana_coman: - I'll take a rockchip there if you do it; when would this be available?
ossabot: Logged on 2019-10-10 16:19:35 asciilifeform: diana_coman: i am considering to house 4u of irons incl. new rk plant experimentally in bmor at own risk & expense. will see whether anyone wants in, otherwise will e.g. trb.
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
whaack: good afternoon diana_coman. a q re your comment to thimbronion about v yesterday. i pressed with a 2015 version that i understand is pre-keccak. from my understanding the pressing function of V does not need to know about the hash function used in the vpatches.
whaack: my question is am i mistaken, and did my version of V not validate thoroughly when it pressed?
diana_coman: whaack: o.O what do you think the role of the hashes is there?
whaack: well i think that i may have discovered a big gap in my understanding of V. one sec while i articulate my point of confusion
whaack: so there are two places where hashes are being used. The first is in the sigs of the vpatches. Each vpatch is a signed file, so to obtain that signature gpg first hashes the .vpatch file and then performs RSA on the resulting hash.
whaack: the second is that each vpatch has a list of diffs of files. The diffs reference the previous files by their hash and also show the new hash that will be obtained after performing the diff.
diana_coman: whaack: so far so good: there are indeed 2 hashes used in 2 places for 2 different purposes.
whaack: now to answer my own question, when V is pressing, at the start of applying a new patch it should ensure that each file it already has pressed hashes to the hash reference in the new vpatch, which would require V to know about keccak
diana_coman: whaack: indeed.
whaack: however, this step ~could~ be skipped, since if you trusted each previous vpatch up to and including the genesis, you would not need to actually check that the resulting hashes were correct. and i think this step is skipped in mod6's older version in 2015
diana_coman: whaack: to make it clear: the sig aka gpg use sha512 ; the vdiff uses keccak currently.
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
diana_coman: so how does it know it patches the right thing if it doesn't check the hash?
whaack: because the files are also referenced by their path
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)
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
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.
whaack: it is here if you would like to see. it identifies the file by looking at the hash output of the previous patch and the hash input of the current patch, but i dont think it hashes the files at any point itself.
asciilifeform: << i asked'em this morning to open my acct, and iirc they said 'week for arin' so looking slow so far.
ericbot: Logged on 2019-10-11 09:15:11 diana_coman: - I'll take a rockchip there if you do it; when would this be available?
ossabot: Logged on 2019-10-10 16:19:35 asciilifeform: diana_coman: i am considering to house 4u of irons incl. new rk plant experimentally in bmor at own risk & expense. will see whether anyone wants in, otherwise will e.g. trb.
spyked: <-- let's say you apply patches p1, p2 which (both) modify file /f1; now, let's say you only apply p1. how do you know file /f1@{p1} is different from /f1@{p1,p2}?
ossabot: Logged on 2019-10-11 10:54:07 whaack: because the files are also referenced by their path
asciilifeform: << if you have a corrected version ( did you succeed in installing ? ) i will sign. (otherwise also happy to make the req'd corrections with own hand, from log, and ditto)
ossabot: Logged on 2019-10-11 10:03:17 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
spyked: whaack, also, hashes impose an ordering on patches via the toposort algo described in ben_vulpes' intro to v
whaack: spyked << you're right i am mistaken there. the files need to be referenced by their hashes and not just there paths. the reason the V i'm using works is because the patches also list the output hash so V can use that and just trust that they are correct hashes without checking
diana_coman: oh boy, a trusting V
spyked: whaack, problem is that classical diff/patch leave room for ambiguity, i.e. in principle it's possible to (cleanly) apply a single hashless patch to different files, which results in different presses. so hashes are needed in order to identify the file (not only path/name, which is only metadata required for retrieval) as it is before/after applying the patch.
spyked: perhaps I should add "uniquely" before "identify the file"
diana_coman: myeah and exactly eliminating such ambiguity is one of the aims of V, really.
spyked: minimal example illustrating this ambiguity: example1.patch was obtain by diffing a and b, but I can apply it on c, which is different from a. if this were possible in v, then this could conceivably lead to malformed presses
spyked: grrr, *was obtained
whaack: got it, i understand that the hashes are needed to identify the files. but regarding hashing the files yourself after every patch, the vpatches already let you know what the output hash will be. so if you trust the vpatch to the point where you're going to run the code outputted by it, then you should trust its claim of what the output of the hash would be. hashing the output files yourself after every patch then becomes more of a
whaack: data-integrity check.
diana_coman: the vpatches let you know what the output hash *should be*
diana_coman: nobody can let you know upfront what it *will be*; in general
whaack is digesting spyked's example
spyked: whaack, imho after trying out yourself, it's worth replicating the example using vdiff/vpatch instead of classical diff/patch -- and observing the results.
whaack: k i understand your example
thimbronion: diana_coman: is partially working - admin interface works, but posts 404 and the homepage redirects to wp-config.php matches except for new database name, user and password. Seen this problem before?
thimbronion: diana_coman: error logs for a request for fwiw:
diana_coman: thimbronion: the error logs sound like some php version trouble
diana_coman: thimbronion: the links trouble might be a matter of the permalinks and/or permissions not set properly
diana_coman: thimbronion: what OS are you running there?
thimbronion: centos
thimbronion: php version 5.4.16
diana_coman: ah, darn, I have my notes for that but not at hand right now
whaack: thimbronion: homepage works for me.
thimbronion: whaack: ah same here from a browser where I'm not logged in. permalinks still broken though.
BingoBoingo: thimbronion: Your best bet is probably going to involve building php 5.6 as its where the V tree has taken mp-wp. I strongly suspect we are going to end up standardizing on php 5.6 because php failed to do backwards or forwards compatibility
diana_coman: thimbronion: does it work if you set the format to that default ?page bla?
diana_coman: because if it does, then you either don't have rewrite allowed and/or correct .htaccess
diana_coman: or otherwise your file/folder permissions are not fully set correctly, iirc centos had another requirement after chmod
thimbronion: diana_coman: my .htaccess file in the app root:
diana_coman: thimbronion: that looks ok; do you have Apahche set to allow the rewrite though?
diana_coman: it has some conf files too, don't quite recall all+order off the top of my head
thimbronion: diana_coman: that I don't know. I haven't touche httpd.conf except maybe to default to look for index.php instea of index.html
whaack: looks like redirects to the permalink
thimbronion: diana_coman: not sure what you mean by this:
ossabot: Logged on 2019-10-11 12:53:09 diana_coman: thimbronion: does it work if you set the format to that default ?page bla?
diana_coman: thimbronion: in the blog's dashboard you have at settings the option as to what the links for posts should look like
diana_coman: the default setting is to make them look like ; the permalinks are used if you want anything else, namely some more informative url such as date/name
asciilifeform: diana_coman: update re these -- they're as slow as snails. still waiting for a 'ok, put moneys here' from'em
ossabot: Logged on 2019-10-11 11:02:18 asciilifeform: << i asked'em this morning to open my acct, and iirc they said 'week for arin' so looking slow so far.
ericbot: Logged on 2019-10-11 09:15:11 diana_coman: - I'll take a rockchip there if you do it; when would this be available?
ossabot: Logged on 2019-10-10 16:19:35 asciilifeform: diana_coman: i am considering to house 4u of irons incl. new rk plant experimentally in bmor at own risk & expense. will see whether anyone wants in, otherwise will e.g. trb.
thimbronion: diana_coman: ok switche to the default and now all title links work.
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
diana_coman: earlier I had done it on a diff machine but there were all sorts of grief
asciilifeform: diana_coman: i'ma be at the console for prolly longer than you have left awake today, dun hesitate to ask re the griefs
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
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.
thimbronion: diana_coman: ok. At least I can read my posts so I can do the review.
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
diana_coman: as a side note: it also complains about linear instead of lba32
asciilifeform: diana_coman: does it copy kernel at all into /boot part ?
asciilifeform: this is the shoddiest part of the recipe, it almost certainly needs correction
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
asciilifeform: diana_coman: possibly needs a make; make modules_install; make install
diana_coman: asciilifeform: ftr I had to correct/adapt the parted too because it complained it was not aligned and then it failed really.
diana_coman: ok, let me try that
diana_coman: but at any rate, I am therefore recompiling it, no?
asciilifeform: diana_coman: only if changed config
diana_coman: well, I didn't change it, but apparently the make anyway proceeded to recompile
asciilifeform: diana_coman: it's been 1.5y since i myself carried out this incantation, and by all rights oughta have walked the recipe myself prior to publishing, but diana_coman did ask 'plz asap' so posted .
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
ossabot: (trilema) 2019-10-11 diana_coman: asciilifeform: eh, recompile kernel to fit that, at the very least, no?
asciilifeform: diana_coman: i've a disk ready , and will go through it myself again, on a 'apu1', but unfortunately not until later tonight.
diana_coman: anyways, it will recompile, let's see
asciilifeform: diana_coman: it was snapshotted iirc with .o's litter still in the kernel build dir, so i do not know why insists to recompile. will have to examine w/ magnifying glass.
diana_coman: asciilifeform: the part I don't get mainly is why no initramfs in /build
diana_coman: ugh, in /boot
asciilifeform: diana_coman: ok i looked in notes, and have answer : i used 'genkernel --menuconfig all' to build, it builds initramfs (which otherrwise has to be built manually)
diana_coman: asciilifeform: so wait, do I need to do that or what/
diana_coman: ?
asciilifeform: in /usr/src/linux , 'genkernel --menuconfig all' (after ensuring that /boot is mounted ) ; also examine the config that it displays to see that it matches your iron, at same time
asciilifeform: this is how the orig. was built. and asciilifeform mistaken , turns out, that 'make install' would have same effect. the recipe will have to be rewritten.
diana_coman: ugh; now since I started the make...
asciilifeform: can abort w/out ill effect
diana_coman: ok, let me see then
diana_coman: I will not modify the config though because the whole idea was to test that indeed "can just work on any amd"
asciilifeform: diana_coman: after genkernel is through, it is expected to display the path where wrote the kernel and initramfs.
diana_coman: at least without adapting the config
asciilifeform: diana_coman: you did not mention any unusual irons (e.g. raid) so yes, is expected to work.
diana_coman: it's not raid, no; nothing special really.
asciilifeform: diana_coman: i trimmed that config, but not very aggressively, will be very surprised if not worx on plain 'fx' w/ the built-in sata.
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
asciilifeform: diana_coman: dulap had no ps kbd
diana_coman: so then why all the ps stuff in the config as far as I see? anyway, not a big thing either way
asciilifeform: this is why said 'not agressively', there is support enabled for certain irons that aint in any of the boxes
diana_coman: ah, kk.
asciilifeform: diana_coman: when you enable absent iron in config, it does no harm but to bloat the kernel.
diana_coman: I know
asciilifeform: hence e.g. 'ps kbd' is not problem.
asciilifeform: support for usb kbd, amd's sata, etc. is enabled in the published config.
diana_coman: asciilifeform: fwiw it is indeed compiling now the correctly-named bzImage
diana_coman: rather less informative re activity than the earlier make but whatevs
asciilifeform: this then matches asciilifeform's paper notes.
asciilifeform: diana_coman: verify after that the kernel and initramfs actually get copied to /boot .
diana_coman: myeah; and now I'll have to change the lilo.conf back too, lolz.
asciilifeform: and after this as root run 'lilo' . aha
diana_coman: anyways the compile seems like it will take a bit so I'll get back when it's done.
asciilifeform: diana_coman: you dun have to use 'lilo' , can if you prefer 'grub', simply i use lilo.
diana_coman: neah, I'm fine with lilo
asciilifeform: aite.
diana_coman: asciilifeform: and it failed with: binary /sbin/mount.zfs could not be found
asciilifeform: zfs ?!!
diana_coman: this is what the thing says, what can I do.
asciilifeform: diana_coman: i must now ask, what didja boot for this procedure ?
diana_coman: asciilifeform: hm?
diana_coman: I booted from a usb stick, gentoo live cd
asciilifeform: what is running on the machine where the chroot was carried out ?
asciilifeform: ah
diana_coman: iirc there was a way to ask no zfs
diana_coman: ugh, wtf was it
asciilifeform: diana_coman: can you paste the last 500ln leading up to the barf plz ?
diana_coman: lemme see on that iron, 1 min
diana_coman: ah, first might need to plug in the network, lolz
asciilifeform: ZFS="no" in the config ; but also must make sure genkernel is actually using the provided config, and not somehow default (if you e.g. 'make clean'-d, may be using default)
diana_coman: it's using config with right name at least ie Dulap-III
diana_coman: 1 min, I'll get a paste out of it
asciilifeform: ty
diana_coman: asciilifeform:
asciilifeform looks
diana_coman: there is a --no-zfs
diana_coman: lemme try with that, again
asciilifeform: genkernel --no-zfs --menuconfig all
asciilifeform: aha
asciilifeform: (for some reason wasn't necessary on bv's provided gentoo stick, with which this process to date carried out)
diana_coman: dunno, I've made this bootable stick a while ago when I was trying out Cuntoo really
asciilifeform: cuntoo carries 100% own bin tooling tho. which is why it -- civilized, and this -- barbaric, yes
diana_coman: if I'm at that I added --no-btrfs too, just-in-case.
diana_coman: I don't see further --no to add, but we'll see
diana_coman: well, at least it compiled now; it has a warning that additional kernel cmdline arguments may be required ie rootfstype=ext3
diana_coman: and now there is an initramfs in /boot too, let's see
asciilifeform: verify that in /boot actually lie the kernel and initramfs, of the expected names, aha
diana_coman: they seem to be there; lemme document + move on
asciilifeform: ty
diana_coman: lilo worked although it still whined about linear
asciilifeform: diana_coman: i now wish i had thought to formalize and scriptize this item, but will admit that i wrote it off as dead when cuntoo was published.
asciilifeform: never expected anyone would ask for it again.
diana_coman: asciilifeform: tbh I wanted to ask "why not script" but anyway.
asciilifeform: oughta be a script. but thought 'ah, but nao cuntoo'
diana_coman: asciilifeform: uhm, just a bit ago you lashed out that "people not replicating asciilifeform's magic irons"
asciilifeform: diana_coman: this os was proclaimed obsolete / abandoned. so no, did not expect it would have to be replicated again.
asciilifeform: if i were asked to make erry single thing i ever wrote and put in garbage can properly documented, would need to live for 400 years.
diana_coman: asciilifeform: ugh, boot failed with filesystem mounted at /dev/sda2 does not appear to be valid /
diana_coman: hm, fstab comes to mind
asciilifeform: grrr i didn't mention fstab did i !!!
diana_coman: lolz
diana_coman: mk, back to it
asciilifeform: diana_coman: you already have better picture in your head of this mechanism than is illustrated in the ' asciilifeform writes cookbook in 15min from memory ' ha.
asciilifeform: of course fstab.
diana_coman: but hm, my usb kbd is indeed not working, lol
asciilifeform: is only thing not working ?
diana_coman: wait, I need the kbd first to edit fstab, lol
diana_coman: ps kbd to the rescue
asciilifeform: diana_coman: also : when rebooted, was only the new disk present, or both usb booter and the new disk ?
asciilifeform: the one you boot from, generally will appear as 'sda'
diana_coman: asciilifeform: I took out the usb stick
asciilifeform: diana_coman: do you get a command prompt from kernel ? ( when it refuses to mount / on /dev/sda2 ) ?
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
diana_coman: I can get a shell
diana_coman: ah shit
diana_coman: that's not enough, is it
diana_coman: ugh
asciilifeform: oh fffs
asciilifeform: in the given fstab, there is a disagreement w/the cookbook, diana_coman :
asciilifeform: change the 'reiserfs' to ext4 plz.
asciilifeform: otherwise /dev/sda1 still is /boot, and /dev/sda2 -- root.
diana_coman: asciilifeform: link?
asciilifeform: grr want to paste but not loading here for some reason grrr
asciilifeform: diana_coman: 'the given fstab' being referred to is the one in dulap.tar.gz.
asciilifeform: that you presently have in that disk.
diana_coman: asciilifeform: re it's just that style sheet
diana_coman: cut it out and it will load
asciilifeform: diana_coman: how do i cut it out ?
diana_coman: uhm, even a stop on the browser should do it; depends what you are using exactly
asciilifeform: ok finally timed out.
diana_coman: atm fighting it a bit to boot from stick rather than disk, lol
diana_coman: or that , lol
asciilifeform: so : the given ;
asciilifeform: the desired .
asciilifeform brb in 10-15m
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.
diana_coman: I'll take a break too.
asciilifeform back
asciilifeform answering, grr, phones, may be slower than realtime for next half hr
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
diana_coman: asciilifeform: any idea?
asciilifeform banished the phones, available nao for 3+h of gentoocement drill
asciilifeform: diana_coman: waitasec , not boots from stick ?!
asciilifeform: you didn't write to the stick, no ?
diana_coman: asciilifeform: no; but hm, I should check the disk, makes sense
diana_coman: it would be rather weird but anyway; kk, let's check it...
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.
asciilifeform: diana_coman: before you reimage it :
asciilifeform: diana_coman: if you can mount it on a working linux box, find whether somehow the new kernel , image, etc. ended up written to the usb.
asciilifeform: rather than the new disk.
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.
asciilifeform: ok
asciilifeform: 1nce you have the test bed again booted w/ new stick, can 1) modify fstab 2) verify that kernel was written to 1st part.
diana_coman: asciilifeform: the kernel was written fine, I could even check now
asciilifeform: oh ffs i reread the gentoo docs, and found why diana_coman's usb stick nuked. in the lilo.conf, before run 'lilo' as root to install the lilo loader on mbr, must actually set boot=.... to ~where new disk is atm~ and ~then~ modify after successfully booted w/ new disk alone.
diana_coman: the shell I got mounted in read-only the /
diana_coman: sigh
asciilifeform: diana_coman: right but lilo writes directly to block 0 on the specified device
asciilifeform: bypassing mount
diana_coman: imaging now another stick anyway
diana_coman: the image is 2.2G so apparently dd takes a while
asciilifeform not going anywhere, awaits output
diana_coman: ok, new stick is ready, booted on it; mounted /dev/sda2 and changed that reiserfs to ext4
diana_coman: asciilifeform: do I need to do anything else before rebooting?
asciilifeform: diana_coman: i strongly suspect that you do not have a working lilo bootloader on the new disk, that it got written to the (previous) usb
diana_coman: ugh
asciilifeform: if new-disk-alone dun boot, this will be the culprit.
diana_coman: asciilifeform: so what do you suggest now?
asciilifeform: perform the chroot steps so as to operate on the new disk. change sda to sdb (where new disk is presently hanging) in lilo.conf, and run 'lilo' as root.
asciilifeform: then ought to be able to boot from the new disk alone.
diana_coman: hm; let me try first and see if it boots, can't hurt anyway
asciilifeform: ok
asciilifeform will be surprised if does
diana_coman: asciilifeform: myeah, it does not; sigh.
asciilifeform: lilo.
asciilifeform: ( as described in this doc, in section 'lilo', except that you are setting up on an actual hdd as your 'second disk' rather than vice-versa, but same process )
asciilifeform: lilo will warn that 'you are not writing to first disk', this is to be expected.
diana_coman: ok; booted now again from usb stick, let me see
asciilifeform: diana_coman: tip: lilo can be run as 'lilo -C /etc/lilo-xyz.conf' if you want to make a copy of the conf for installation
asciilifeform: (as it differs from the operational conf)
asciilifeform: you will need to change both 'boot=...' and 'disk=...' .
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
diana_coman: disk is same
asciilifeform: diana_coman: you booted nao and stick is sdb ?!
diana_coman: asciilifeform: I booted from usb stick; usb stick is still sdb, yes
asciilifeform: but last time around was not ?!
diana_coman: it was; hence why I don't quite get this part
asciilifeform: ah but i get :
asciilifeform: diana_coman: what does 'mount' command return ?
diana_coman: asciilifeform: hm?
asciilifeform: diana_coman: 1s. how is the disk attached to the machine ?
asciilifeform: ( via snake ? i.e. plugged in after boot via stick ? or to sata ? )
diana_coman: asciilifeform: the usb stick is in usb port; the hard drive is main drive, sata
diana_coman: there is no other drive (/me wanted to keep it simple)
asciilifeform: may be the case that the bios is doing something odd w/ driver ordering on this iron.
asciilifeform: if the ~new~ disk is in fact sda : then can execute 'lilo' with the given config.
asciilifeform: and is to install on the new disk.
asciilifeform: as described in the dox.
diana_coman: well, I suppose I can execute lilo and see if it nukes this second drive too, lol
asciilifeform: ensure that the config is unmodified and then yes.
diana_coman: uhm; now it says fatal: default image doesn't exist; I think I might be getting too tired for this
asciilifeform: diana_coman: before you stop, can you paste the barfola ?
asciilifeform: diana_coman: i'ma repeat the entire process here, while you sleep .
diana_coman: asciilifeform: it's literally just that; it says Added GentooDulap and then Default image doesn't exist
asciilifeform: diana_coman: did you chroot 1st ?
diana_coman: yes
diana_coman: hm, I don't see a default line in lilo.conf, should there be one?
asciilifeform: yes !
asciilifeform: lemme paste the original
asciilifeform: .
asciilifeform: ^ is what's in the tarball.
asciilifeform: if your boot aint mounted, then it won't find the kernel img, boot must be mounted.
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.
diana_coman: ok, now it worked
asciilifeform: ok! let's fire it
diana_coman: lilo ran fine; there is still the warning re LINEAR vs LBA32
asciilifeform not seen this warn before
asciilifeform: diana_coman: verify that the given image and initrd correspond to what lies inside /boot , and test-fire then.
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; "
asciilifeform: diana_coman: i suspect lba is disabled in your bios
asciilifeform: should not make a diff tho here.
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 /
diana_coman: ugh
asciilifeform: diana_coman: if you have the energy, plox to enable lba2 and try liloizing again
asciilifeform: *lba32
asciilifeform: diana_coman: i assume you remembered to fix fstab ?
diana_coman: asciilifeform: fixed fstab, yes; at least the usb stick is still working so running lilo was not the problem there
diana_coman: let me see re lba2
asciilifeform: also i assume you rebooted w/ the usb stick removed, rather than simply used bios bootloader menu to select hdd ?
diana_coman: asciilifeform: stick removed, yes
asciilifeform: ok
asciilifeform: btw given that you got this far, you have a kernel that boots, so lilo per se is prolly not the issue
asciilifeform: diana_coman: how big is the new disk ? if it's >200GB, then iirc in fact demands lba32 to work
asciilifeform: (to mount / , that is , which is to say to see whole disk)
diana_coman: asciilifeform: ah, so that might be it; it's 1TB
asciilifeform: aa!
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)
diana_coman: took stick out and booted, same trouble
asciilifeform: but not mounts / ?
diana_coman: it goes mounting /dev/sda2 as root....
diana_coman: Using mount -t auto -o ro
asciilifeform: and then..?
diana_coman: and then the filesystem ounted at /dev/sda2 does not appear to be a valid /, try again
diana_coman: mounted*
diana_coman: Could not find the root block device in .
diana_coman: hm
asciilifeform: diana_coman: is sata in ahci mode in bios ?
asciilifeform: or 'legacy'
diana_coman: asciilifeform: seems dubious that it says just "in ."
diana_coman: I'd need to look, I don't remember for this box
asciilifeform: diana_coman: i want to rule out the possibility that your box has a sata chipset that's commented out in the kernel config.
asciilifeform: diana_coman: can you paste plz the output of lsmod (when booted from working stick) ?
diana_coman: lemme boot and look
asciilifeform: ty
asciilifeform: diana_coman: but if indeed this so, then if set to 'legacy' then oughta boot.
diana_coman: asciilifeform:
asciilifeform looks
asciilifeform: so it's a 'megaraid' chipset ?
diana_coman: lemme fish out full spec
asciilifeform: ty
asciilifeform: diana_coman: plz meanwhile set 'legacy' in bios and see whether boots ; if yes, that nails the culprit
asciilifeform: ( and then easy fix when i find out which iron is actually in there )
asciilifeform: errybody wants trimmed kernels, nobody wants ~this~, but it's a genuine dilemma.
asciilifeform: diana_coman: plz also collect output of 'dmesg' on successfully booted stick.
asciilifeform: (and paste.)
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
asciilifeform: this is enuff, i can look up from the vendor.
diana_coman: let me run dmesg, 1 min
asciilifeform: diana_coman ty
diana_coman will have to go in 5 minutes so after that
asciilifeform: diana_coman: me too, the coffee is already on the table, but after that in 15m will come back, and do all of this that we did, on a box here on desk.
diana_coman: asciilifeform: fwiw indeed yes, sata IS set to ahci mode
diana_coman: asciilifeform: and dmesg output
asciilifeform: try , before going plz, w/ 'legacy' .
asciilifeform: diana_coman: 1 more thing : it should boot if the kernel in /boot were to be literally replaced with the 1 on the stick.
asciilifeform: then can get userland quickly.
asciilifeform: i unfortunately do not have your exact mb here, but will , if you dun get nao a running box, repeat the entire procedure with 'apu1' and write down actual cookbook to eliminate all other possible mistakes.
diana_coman: where the fuck was that legacy thing in this bios, arrgh
asciilifeform: where 'ahci' is now
diana_coman: lolyes
asciilifeform: ok i'ma go and drink that cup, diana_coman . if i find that you did not get liftoff, will do as above described while you sleep and write the chronicle.
asciilifeform: i am in newyork time btw.
asciilifeform brb
diana_coman: asciilifeform: it will have to be laters/tomorrow
whaack: a little update on my interests post. first, i thought this was understood but i want to clarify with you diana_coman that this post is not supposed to be a continuation of previous/future tmsr work but instead a list of the things that i am personally interested in. (that would be aeparate post that will come later.) second, i've come up with six categories: pr
whaack: ogramming, cryptography, reading, spanish, guitar, and surfing. (Although i think programming/cryptography should be combined) From there I categorize the first 4 into academic/tmsr and the last 2 into non-academic/relaxation. then as mentioned before i list for each one my i) history 2) why i'm interested and 3) future goals
whaack: let me know if this is off the mark. in any event gn diana_coman
asciilifeform starts the process, 1st to prep boot stick...
asciilifeform: diana_coman: update : building kernel, etc. and updating cookbook. tester is a 'amd e350', is prior to your 'fx' but similar chipset. will post result.
asciilifeform: diana_coman: it is done!! i have reproduced fully the dulap-baking process. will deedbot the new, corrected and tested recipe, shortly.
asciilifeform: diana_coman: .
ossabot: (trilema) 2019-10-11 asciilifeform: !!deed
asciilifeform: diana_coman: would not have taken so long as it did, but this is VERY slow box. kernel compile 2+hrs.
asciilifeform: the test machine booted as-expected on 1st try, and is running now.
asciilifeform: diana_coman: i did not use 'apu1' , as it req's a serial port console to be config'd, and not applicable for your use case. but in the coming days i'ma replicate on a 'apu1' for own use.
asciilifeform: diana_coman: the basic process, nao 100% proven to work as printed in the new recipe. if it so happens that your irons need kern config changes, i'ma help to walk through this tomorrow.
asciilifeform with working box, nao, finally to bed.

Random(ossasepia) | Download daily DB snapshot | Get Source Code