#ossasepia | 2019-10-11

Logged on 2019-10-10 06:35:54 diana_coman: lobbes: let me know if you want me to dump somewhere that cobbled-up awk script from when I hunted a line; I don't even recall directly the state of it but problem was solved.

00:51

lobbes

http://logs.ericbenevides.com/log/ossasepia/2019-10-10#1004975 << ty btw

00:51

Logged on 2019-10-10 06:36:09 diana_coman: lobbes: and happy 32nd birthday!

~ 9 hours 5 minutes ~

09:56

crowncloud_: how about that server?

~ 19 minutes ~

10:15

http://logs.ossasepia.com/log/ossasepia/2019-10-10#1005261 - I'll take a rockchip there if you do it; when would this be available?

10:15

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.

~ 3 hours 47 minutes ~

14:03

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

~ 27 minutes ~

14:30

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.

14:32

my question is am i mistaken, and did my version of V not validate thoroughly when it pressed?

14:38

whaack: o.O what do you think the role of the hashes is there?

14:40

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

14:45

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.

14:48

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.

14:49

whaack: so far so good: there are indeed 2 hashes used in 2 places for 2 different purposes.

14:50

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

14:51

whaack: indeed.

14:52

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

14:52

whaack: to make it clear: the sig aka gpg use sha512 ; the vdiff uses keccak currently.

14:53

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

14:53

so how does it know it patches the right thing if it doesn't check the hash?

14:54

because the files are also referenced by their path

14:54

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)

14:56

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

14:56

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.

14:59

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. http://paste.deedbot.org/?id=-e3B

15:02

http://logs.ericbenevides.com/log/ossasepia/2019-10-11#1005314 << i asked'em this morning to open my acct, and iirc they said 'week for arin' so looking slow so far.

15:02

Logged on 2019-10-11 09:15:11 diana_coman: http://logs.ossasepia.com/log/ossasepia/2019-10-10#1005261 - I'll take a rockchip there if you do it; when would this be available?

15:02

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.

15:03

http://logs.ossasepia.com/log/ossasepia/2019-10-11#1005331 <-- 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}?

15:03

Logged on 2019-10-11 10:54:07 whaack: because the files are also referenced by their path

15:04

http://logs.ossasepia.com/log/ossasepia/2019-10-11#1005317 << 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)

15:04

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

15:06

whaack, also, hashes impose an ordering on patches via the toposort algo described in ben_vulpes' intro to v

15:08

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

15:09

oh boy, a trusting V

15:15

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.

15:16

perhaps I should add "uniquely" before "identify the file"

15:17

myeah and exactly eliminating such ambiguity is one of the aims of V, really.

15:26

minimal example illustrating this ambiguity: http://paste.deedbot.org/?id=Auce 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

15:29

grrr, *was obtained

15:29

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

15:29

data-integrity check.

15:31

the vpatches let you know what the output hash *should be*

15:31

nobody can let you know upfront what it *will be*; in general

15:35

*

whaack is digesting spyked's example

15:36

whaack, imho after trying out yourself, it's worth replicating the example using vdiff/vpatch instead of classical diff/patch -- and observing the results.

~ 19 minutes ~

15:56

k i understand your example

~ 35 minutes ~

16:32

diana_coman: thimbron.com is partially working - admin interface works, but posts 404 and the homepage redirects to http://thimbron.com/wp-admin/install.php. wp-config.php matches except for new database name, user and password. Seen this problem before?

16:41

diana_coman: error logs for a request for http://thimbron.com/ fwiw: http://paste.deedbot.org/?id=AAPr

16:43

thimbronion: the error logs sound like some php version trouble

16:43

thimbronion: the links trouble might be a matter of the permalinks and/or permissions not set properly

16:44

thimbronion: what OS are you running there?

16:44

centos

16:44

php version 5.4.16

16:48

ah, darn, I have my notes for that but not at hand right now

16:49

thimbronion: homepage works for me.

16:51

whaack: ah same here from a browser where I'm not logged in. permalinks still broken though.

16:52

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

16:53

thimbronion: does it work if you set the format to that default ?page bla?

16:53

because if it does, then you either don't have rewrite allowed and/or correct .htaccess

16:54

or otherwise your file/folder permissions are not fully set correctly, iirc centos had another requirement after chmod

16:56

diana_coman: my .htaccess file in the app root: http://paste.deedbot.org/?id=MHj0

16:57

thimbronion: that looks ok; do you have Apahche set to allow the rewrite though?

16:57

it has some conf files too, don't quite recall all+order off the top of my head

16:57

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

16:58

looks like http://thimbron.com/?p=10 redirects to the permalink

17:01

diana_coman: not sure what you mean by this: http://logs.ossasepia.com/log/ossasepia/2019-10-11#1005369

17:01

Logged on 2019-10-11 12:53:09 diana_coman: thimbronion: does it work if you set the format to that default ?page bla?

17:02

thimbronion: in the blog's dashboard you have at settings the option as to what the links for posts should look like

17:02

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

17:02

diana_coman: update re these -- they're as slow as snails. still waiting for a 'ok, put moneys here' from'em

17:02

Logged on 2019-10-11 11:02:18 asciilifeform: http://logs.ericbenevides.com/log/ossasepia/2019-10-11#1005314 << i asked'em this morning to open my acct, and iirc they said 'week for arin' so looking slow so far.

17:02

Logged on 2019-10-11 09:15:11 diana_coman: http://logs.ossasepia.com/log/ossasepia/2019-10-10#1005261 - I'll take a rockchip there if you do it; when would this be available?

17:02

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.

17:03

diana_coman: ok switche to the default and now all title links work.

17:03

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

17:03

earlier I had done it on a diff machine but there were all sorts of grief

17:04

diana_coman: i'ma be at the console for prolly longer than you have left awake today, dun hesitate to ask re the griefs

17:04

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

17:06

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.

17:07

diana_coman: ok. At least I can read my posts so I can do the review.

~ 32 minutes ~

17:39

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

17:40

as a side note: it also complains about linear instead of lba32

17:41

diana_coman: does it copy kernel at all into /boot part ?

17:41

this is the shoddiest part of the recipe, it almost certainly needs correction

17:41

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

17:42

diana_coman: possibly needs a make; make modules_install; make install

17:43

asciilifeform: ftr I had to correct/adapt the parted too because it complained it was not aligned and then it failed really.

17:43

ok, let me try that

17:43

but at any rate, I am therefore recompiling it, no?

17:43

diana_coman: only if changed config

17:44

well, I didn't change it, but apparently the make anyway proceeded to recompile

17:44

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 .

17:45

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

17:45

(trilema) 2019-10-11 diana_coman: asciilifeform: eh, recompile kernel to fit that, at the very least, no?

17:46

diana_coman: i've a disk ready , and will go through it myself again, on a 'apu1', but unfortunately not until later tonight.

17:46

anyways, it will recompile, let's see

17:46

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.

17:47

asciilifeform: the part I don't get mainly is why no initramfs in /build

17:47

ugh, in /boot

17:48

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)

17:49

asciilifeform: so wait, do I need to do that or what/

17:49

?

17:50

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

17:50

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.

17:50

ugh; now since I started the make...

17:50

can abort w/out ill effect

17:50

ok, let me see then

17:51

I will not modify the config though because the whole idea was to test that indeed "can just work on any amd"

17:51

diana_coman: after genkernel is through, it is expected to display the path where wrote the kernel and initramfs.

17:51

at least without adapting the config

17:51

diana_coman: you did not mention any unusual irons (e.g. raid) so yes, is expected to work.

17:52

it's not raid, no; nothing special really.

17:52

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.

17:52

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

17:52

diana_coman: dulap had no ps kbd

17:53

so then why all the ps stuff in the config as far as I see? anyway, not a big thing either way

17:53

this is why said 'not agressively', there is support enabled for certain irons that aint in any of the boxes

17:53

ah, kk.

17:53

diana_coman: when you enable absent iron in config, it does no harm but to bloat the kernel.

17:53

I know

17:54

hence e.g. 'ps kbd' is not problem.

17:54

support for usb kbd, amd's sata, etc. is enabled in the published config.

17:54

asciilifeform: fwiw it is indeed compiling now the correctly-named bzImage

17:55

rather less informative re activity than the earlier make but whatevs

17:55

this then matches asciilifeform's paper notes.

17:55

diana_coman: verify after that the kernel and initramfs actually get copied to /boot .

17:56

myeah; and now I'll have to change the lilo.conf back too, lolz.

17:56

and after this as root run 'lilo' . aha

17:56

anyways the compile seems like it will take a bit so I'll get back when it's done.

17:56

diana_coman: you dun have to use 'lilo' , can if you prefer 'grub', simply i use lilo.

17:56

neah, I'm fine with lilo

17:56

aite.

17:58

asciilifeform: and it failed with: binary /sbin/mount.zfs could not be found

17:58

zfs ?!!

17:59

this is what the thing says, what can I do.

17:59

diana_coman: i must now ask, what didja boot for this procedure ?

17:59

asciilifeform: hm?

18:00

I booted from a usb stick, gentoo live cd

18:00

what is running on the machine where the chroot was carried out ?

18:00

ah

18:00

iirc there was a way to ask no zfs

18:00

ugh, wtf was it

18:00

diana_coman: can you paste the last 500ln leading up to the barf plz ?

18:01

lemme see on that iron, 1 min

18:01

ah, first might need to plug in the network, lolz

18:02

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)

18:03

it's using config with right name at least ie Dulap-III

18:03

1 min, I'll get a paste out of it

18:03

ty

18:05

asciilifeform: http://paste.deedbot.org/?id=O9GU

18:05

*

asciilifeform looks

18:05

there is a --no-zfs

18:05

lemme try with that, again

18:06

genkernel --no-zfs --menuconfig all

18:06

aha

18:06

(for some reason wasn't necessary on bv's provided gentoo stick, with which this process to date carried out)

18:07

dunno, I've made this bootable stick a while ago when I was trying out Cuntoo really

18:07

cuntoo carries 100% own bin tooling tho. which is why it -- civilized, and this -- barbaric, yes

18:09

if I'm at that I added --no-btrfs too, just-in-case.

18:09

I don't see further --no to add, but we'll see

18:11

well, at least it compiled now; it has a warning that additional kernel cmdline arguments may be required ie rootfstype=ext3

18:12

and now there is an initramfs in /boot too, let's see

18:12

verify that in /boot actually lie the kernel and initramfs, of the expected names, aha

18:13

they seem to be there; lemme document + move on

18:13

ty

18:14

lilo worked although it still whined about linear

18:14

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.

18:14

never expected anyone would ask for it again.

18:15

asciilifeform: tbh I wanted to ask "why not script" but anyway.

18:15

oughta be a script. but thought 'ah, but nao cuntoo'

18:15

asciilifeform: uhm, just a bit ago you lashed out that "people not replicating asciilifeform's magic irons"

18:16

diana_coman: this os was proclaimed obsolete / abandoned. so no, did not expect it would have to be replicated again.

18:16

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.

18:17

asciilifeform: ugh, boot failed with filesystem mounted at /dev/sda2 does not appear to be valid /

18:17

hm, fstab comes to mind

18:17

grrr i didn't mention fstab did i !!!

18:17

lolz

18:17

mk, back to it

18:18

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.

18:18

of course fstab.

18:20

but hm, my usb kbd is indeed not working, lol

18:20

is only thing not working ?

18:20

wait, I need the kbd first to edit fstab, lol

18:21

ps kbd to the rescue

18:22

diana_coman: also : when rebooted, was only the new disk present, or both usb booter and the new disk ?

18:22

the one you boot from, generally will appear as 'sda'

18:24

asciilifeform: I took out the usb stick

18:25

diana_coman: do you get a command prompt from kernel ? ( when it refuses to mount / on /dev/sda2 ) ?

18:25

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

18:25

I can get a shell

18:26

ah shit

18:26

that's not enough, is it

18:26

ugh

18:27

oh fffs

18:27

in the given fstab, there is a disagreement w/the cookbook, diana_coman :

18:28

change the 'reiserfs' to ext4 plz.

18:28

otherwise /dev/sda1 still is /boot, and /dev/sda2 -- root.

18:29

asciilifeform: link?

18:29

grr want to paste but paste.deedbot.org not loading here for some reason grrr

18:30

diana_coman: 'the given fstab' being referred to is the one in dulap.tar.gz.

18:30

that you presently have in that disk.

18:30

asciilifeform: re paste.deedbot.org it's just that style sheet

18:31

cut it out and it will load

18:31

diana_coman: how do i cut it out ?

18:31

uhm, even a stop on the browser should do it; depends what you are using exactly

18:31

ok finally timed out.

18:31

atm fighting it a bit to boot from stick rather than disk, lol

18:31

or that , lol

18:31

so : the given ;

18:32

the desired .

18:33

*

asciilifeform brb in 10-15m

18:33

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.

18:33

I'll take a break too.

18:42

*

asciilifeform back

~ 16 minutes ~

18:58

*

asciilifeform answering, grr, phones, may be slower than realtime for next half hr

~ 16 minutes ~

19:14

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

19:14

asciilifeform: any idea?

19:15

*

asciilifeform banished the phones, available nao for 3+h of gentoocement drill

19:15

diana_coman: waitasec , not boots from stick ?!

19:16

you didn't write to the stick, no ?

19:16

asciilifeform: no; but hm, I should check the disk, makes sense

19:16

it would be rather weird but anyway; kk, let's check it...

19:22

uhm, wtf, the stick is shot *right now*; wtf; mk, I'll go and write another one + set this to be looked at.

19:22

diana_coman: before you reimage it :

19:22

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.

19:23

rather than the new disk.

19:24

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.

19:24

ok

19:25

1nce you have the test bed again booted w/ new stick, can 1) modify fstab 2) verify that kernel was written to 1st part.

19:28

asciilifeform: the kernel was written fine, I could even check now

19:28

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.

19:28

the shell I got mounted in read-only the /

19:29

sigh

19:29

diana_coman: right but lilo writes directly to block 0 on the specified device

19:29

bypassing mount

19:29

imaging now another stick anyway

19:34

the image is 2.2G so apparently dd takes a while

19:35

*

asciilifeform not going anywhere, awaits output

19:43

ok, new stick is ready, booted on it; mounted /dev/sda2 and changed that reiserfs to ext4

19:43

asciilifeform: do I need to do anything else before rebooting?

19:43

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

19:43

ugh

19:43

if new-disk-alone dun boot, this will be the culprit.

19:44

asciilifeform: so what do you suggest now?

19:44

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.

19:44

then ought to be able to boot from the new disk alone.

19:45

hm; let me try first and see if it boots, can't hurt anyway

19:45

ok

19:45

*

asciilifeform will be surprised if does

19:46

asciilifeform: myeah, it does not; sigh.

19:47

lilo.

19:48

( 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 )

19:48

lilo will warn that 'you are not writing to first disk', this is to be expected.

19:51

ok; booted now again from usb stick, let me see

19:52

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

19:53

(as it differs from the operational conf)

19:55

you will need to change both 'boot=...' and 'disk=...' .

19:55

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

19:55

disk is same

19:55

diana_coman: you booted nao and stick is sdb ?!

19:55

asciilifeform: I booted from usb stick; usb stick is still sdb, yes

19:55

but last time around was not ?!

19:56

it was; hence why I don't quite get this part

19:56

ah but i get :

19:56

diana_coman: what does 'mount' command return ?

19:56

asciilifeform: hm?

19:57

diana_coman: 1s. how is the disk attached to the machine ?

19:57

( via snake ? i.e. plugged in after boot via stick ? or to sata ? )

19:57

asciilifeform: the usb stick is in usb port; the hard drive is main drive, sata

19:57

there is no other drive (/me wanted to keep it simple)

19:57

may be the case that the bios is doing something odd w/ driver ordering on this iron.

19:58

if the ~new~ disk is in fact sda : then can execute 'lilo' with the given config.

19:58

and is to install on the new disk.

19:58

as described in the dox.

19:58

well, I suppose I can execute lilo and see if it nukes this second drive too, lol

19:58

ensure that the config is unmodified and then yes.

20:01

uhm; now it says fatal: default image doesn't exist; I think I might be getting too tired for this

20:02

diana_coman: before you stop, can you paste the barfola ?

20:02

diana_coman: i'ma repeat the entire process here, while you sleep .

20:02

asciilifeform: it's literally just that; it says Added GentooDulap and then Default image doesn't exist

20:03

diana_coman: did you chroot 1st ?

20:03

yes

20:03

hm, I don't see a default line in lilo.conf, should there be one?

20:03

yes !

20:03

lemme paste the original

20:04

http://paste.deedbot.org/?id=kSMh .

20:04

^ is what's in the tarball.

20:04

if your boot aint mounted, then it won't find the kernel img, boot must be mounted.

20:05

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.

20:05

ok, now it worked

20:05

ok! let's fire it

20:06

lilo ran fine; there is still the warning re LINEAR vs LBA32

20:07

*

asciilifeform not seen this warn before

20:08

diana_coman: verify that the given image and initrd correspond to what lies inside /boot , and test-fire then.

20:08

"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; "

20:09

diana_coman: i suspect lba is disabled in your bios

20:09

should not make a diff tho here.

20:10

rebooted: the image label is correct ie lilo seems fine; but still same problem re /dev/sda2 does not appear to be a valid /

20:10

ugh

20:10

diana_coman: if you have the energy, plox to enable lba2 and try liloizing again

20:10

*lba32

20:10

diana_coman: i assume you remembered to fix fstab ?

20:11

asciilifeform: fixed fstab, yes; at least the usb stick is still working so running lilo was not the problem there

20:11

let me see re lba2

20:12

also i assume you rebooted w/ the usb stick removed, rather than simply used bios bootloader menu to select hdd ?

20:12

asciilifeform: stick removed, yes

20:12

ok

20:13

btw given that you got this far, you have a kernel that boots, so lilo per se is prolly not the issue

20:14

diana_coman: how big is the new disk ? if it's >200GB, then iirc in fact demands lba32 to work

20:14

(to mount / , that is , which is to say to see whole disk)

20:15

asciilifeform: ah, so that might be it; it's 1TB

20:15

aa!

20:17

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)

20:17

took stick out and booted, same trouble

20:17

but not mounts / ?

20:18

it goes mounting /dev/sda2 as root....

20:18

Using mount -t auto -o ro

20:18

and then..?

20:18

and then the filesystem ounted at /dev/sda2 does not appear to be a valid /, try again

20:18

mounted*

20:18

Could not find the root block device in .

20:18

hm

20:20

diana_coman: is sata in ahci mode in bios ?

20:20

or 'legacy'

20:20

asciilifeform: seems dubious that it says just "in ."

20:21

I'd need to look, I don't remember for this box

20:21

diana_coman: i want to rule out the possibility that your box has a sata chipset that's commented out in the kernel config.

20:21

diana_coman: can you paste plz the output of lsmod (when booted from working stick) ?

20:21

lemme boot and look

20:21

ty

20:22

diana_coman: but if indeed this so, then if set to 'legacy' then oughta boot.

20:25

asciilifeform: http://paste.deedbot.org/?id=t8Ci

20:25

*

asciilifeform looks

20:26

so it's a 'megaraid' chipset ?

20:27

lemme fish out full spec

20:27

ty

20:28

diana_coman: plz meanwhile set 'legacy' in bios and see whether boots ; if yes, that nails the culprit

20:29

( and then easy fix when i find out which iron is actually in there )

20:29

errybody wants trimmed kernels, nobody wants ~this~, but it's a genuine dilemma.

20:31

diana_coman: plz also collect output of 'dmesg' on successfully booted stick.

20:31

(and paste.)

20:31

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

20:32

this is enuff, i can look up from the vendor.

20:32

let me run dmesg, 1 min

20:32

diana_coman ty

20:32

*

diana_coman will have to go in 5 minutes so after that

20:32

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.

20:34

asciilifeform: fwiw indeed yes, sata IS set to ahci mode

20:34

asciilifeform: and dmesg output http://paste.deedbot.org/?id=PGJr

20:34

try , before going plz, w/ 'legacy' .

20:36

diana_coman: 1 more thing : it should boot if the kernel in /boot were to be literally replaced with the 1 on the stick.

20:36

then can get userland quickly.

20:37

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.

20:37

where the fuck was that legacy thing in this bios, arrgh

20:37

where 'ahci' is now

20:37

lolyes

20:38

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.

20:39

i am in newyork time btw.

20:39

*

asciilifeform brb

20:40

asciilifeform: it will have to be laters/tomorrow

~ 19 minutes ~

20:59

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

20:59

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

21:02