| diana_coman: | crowncloud_: how about that server? | [05:56] |
| diana_coman: | http://ossasepia.com/2020/04/20/ossasepia-logs-for-10-Oct-2019#1005261 - I'll take a rockchip there if you do it; when would this be available? | [06:15] |
| 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. | [06:15] |
| 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 | [10:03] |
| 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. | [10:30] |
| whaack: | my question is am i mistaken, and did my version of V not validate thoroughly when it pressed? | [10:32] |
| diana_coman: | whaack: o.O what do you think the role of the hashes is there? | [10:38] |
| 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 | [10:40] |
| 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. | [10:45] |
| 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. | [10:48] |
| diana_coman: | whaack: so far so good: there are indeed 2 hashes used in 2 places for 2 different purposes. | [10:49] |
| 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 | [10:50] |
| diana_coman: | whaack: indeed. | [10:51] |
| 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 | [10:52] |
| diana_coman: | whaack: to make it clear: the sig aka gpg use sha512 ; the vdiff uses keccak currently. | [10:52] |
| 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 | [10:53] |
| diana_coman: | so how does it know it patches the right thing if it doesn't check the hash? | [10:53] |
| whaack: | because the files are also referenced by their path | [10:54] |
| 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) | [10:54] |
| 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 | [10:56] |
| 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. | [10:56] |
| 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. http://paste.deedbot.org/?id=-e3B | [10:59] |
| 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. | [11:02] |
| ericbot: | Logged on 2019-10-11 09:15:11 diana_coman: http://ossasepia.com/2020/04/20/ossasepia-logs-for-10-Oct-2019#1005261 - I'll take a rockchip there if you do it; when would this be available? | [11:02] |
| 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. | [11:02] |
| spyked: | http://ossasepia.com/2020/04/20/ossasepia-logs-for-11-Oct-2019#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}? | [11:03] |
| ossabot: | Logged on 2019-10-11 10:54:07 whaack: because the files are also referenced by their path | [11:03] |
| asciilifeform: | http://ossasepia.com/2020/04/20/ossasepia-logs-for-11-Oct-2019#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) | [11:04] |
| 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 | [11:04] |
| spyked: | whaack, also, hashes impose an ordering on patches via the toposort algo described in ben_vulpes' intro to v | [11:06] |
| 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 | [11:08] |
| diana_coman: | oh boy, a trusting V | [11:09] |
| 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. | [11:15] |
| spyked: | perhaps I should add "uniquely" before "identify the file" | [11:16] |
| diana_coman: | myeah and exactly eliminating such ambiguity is one of the aims of V, really. | [11:17] |
| spyked: | 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 | [11:26] |
| spyked: | grrr, *was obtained | [11:29] |
| 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 | [11:29] |
| whaack: | data-integrity check. | [11:29] |
| diana_coman: | the vpatches let you know what the output hash *should be* | [11:31] |
| diana_coman: | nobody can let you know upfront what it *will be*; in general | [11:31] |
| whaack: | is digesting spyked's example | [11:35] |
| 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. | [11:36] |
| whaack: | k i understand your example | [11:56] |
| thimbronion: | 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? | [12:32] |
| thimbronion: | diana_coman: error logs for a request for http://thimbron.com/ fwiw: http://paste.deedbot.org/?id=AAPr | [12:41] |
| diana_coman: | thimbronion: the error logs sound like some php version trouble | [12:43] |
| diana_coman: | thimbronion: the links trouble might be a matter of the permalinks and/or permissions not set properly | [12:43] |
| diana_coman: | thimbronion: what OS are you running there? | [12:44] |
| thimbronion: | centos | [12:44] |
| thimbronion: | php version 5.4.16 | [12:44] |
| diana_coman: | ah, darn, I have my notes for that but not at hand right now | [12:48] |
| whaack: | thimbronion: homepage works for me. | [12:49] |
| thimbronion: | whaack: ah same here from a browser where I'm not logged in. permalinks still broken though. | [12:51] |
| 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 | [12:52] |
| diana_coman: | thimbronion: does it work if you set the format to that default ?page bla? | [12:53] |
| diana_coman: | because if it does, then you either don't have rewrite allowed and/or correct .htaccess | [12:53] |
| diana_coman: | or otherwise your file/folder permissions are not fully set correctly, iirc centos had another requirement after chmod | [12:54] |
| thimbronion: | diana_coman: my .htaccess file in the app root: http://paste.deedbot.org/?id=MHj0 | [12:56] |
| diana_coman: | thimbronion: that looks ok; do you have Apahche set to allow the rewrite though? | [12:57] |
| diana_coman: | it has some conf files too, don't quite recall all+order off the top of my head | [12:57] |
| 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 | [12:57] |
| whaack: | looks like http://thimbron.com/?p=10 redirects to the permalink | [12:58] |
| thimbronion: | diana_coman: not sure what you mean by this: http://ossasepia.com/2020/04/20/ossasepia-logs-for-11-Oct-2019#1005369 | [13:01] |
| 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? | [13:01] |
| diana_coman: | thimbronion: in the blog's dashboard you have at settings the option as to what the links for posts should look like | [13:02] |
| 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 | [13:02] |
| asciilifeform: | diana_coman: update re these -- they're as slow as snails. still waiting for a 'ok, put moneys here' from'em | [13:02] |
| ossabot: | 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. | [13:02] |
| ericbot: | Logged on 2019-10-11 09:15:11 diana_coman: http://ossasepia.com/2020/04/20/ossasepia-logs-for-10-Oct-2019#1005261 - I'll take a rockchip there if you do it; when would this be available? | [13:02] |
| 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. | [13:02] |
| thimbronion: | diana_coman: ok switche to the default and now all title links work. | [13:03] |
| 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 | [13:03] |
| diana_coman: | earlier I had done it on a diff machine but there were all sorts of grief | [13:03] |
| 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 | [13:04] |
| 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 | [13:04] |
| 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. | [13:06] |
| thimbronion: | diana_coman: ok. At least I can read my posts so I can do the review. | [13:07] |
| 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 | [13:39] |
| diana_coman: | as a side note: it also complains about linear instead of lba32 | [13:40] |
| asciilifeform: | diana_coman: does it copy kernel at all into /boot part ? | [13:41] |
| asciilifeform: | this is the shoddiest part of the recipe, it almost certainly needs correction | [13:41] |
| 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 | [13:41] |
| asciilifeform: | diana_coman: possibly needs a make; make modules_install; make install | [13:42] |
| diana_coman: | asciilifeform: ftr I had to correct/adapt the parted too because it complained it was not aligned and then it failed really. | [13:43] |
| diana_coman: | ok, let me try that | [13:43] |
| diana_coman: | but at any rate, I am therefore recompiling it, no? | [13:43] |
| asciilifeform: | diana_coman: only if changed config | [13:43] |
| diana_coman: | well, I didn't change it, but apparently the make anyway proceeded to recompile | [13:44] |
| 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 . | [13:44] |
| 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 | [13:45] |
| ossabot: | (trilema) 2019-10-11 diana_coman: asciilifeform: eh, recompile kernel to fit that, at the very least, no? | [13:45] |
| asciilifeform: | diana_coman: i've a disk ready , and will go through it myself again, on a 'apu1', but unfortunately not until later tonight. | [13:46] |
| diana_coman: | anyways, it will recompile, let's see | [13:46] |
| 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. | [13:46] |
| diana_coman: | asciilifeform: the part I don't get mainly is why no initramfs in /build | [13:47] |
| diana_coman: | ugh, in /boot | [13:47] |
| 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) | [13:48] |
| diana_coman: | asciilifeform: so wait, do I need to do that or what/ | [13:49] |
| diana_coman: | ? | [13:49] |
| 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 | [13:50] |
| 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. | [13:50] |
| diana_coman: | ugh; now since I started the make... | [13:50] |
| asciilifeform: | can abort w/out ill effect | [13:50] |
| diana_coman: | ok, let me see then | [13:50] |
| diana_coman: | I will not modify the config though because the whole idea was to test that indeed "can just work on any amd" | [13:51] |
| asciilifeform: | diana_coman: after genkernel is through, it is expected to display the path where wrote the kernel and initramfs. | [13:51] |
| diana_coman: | at least without adapting the config | [13:51] |
| asciilifeform: | diana_coman: you did not mention any unusual irons (e.g. raid) so yes, is expected to work. | [13:51] |
| diana_coman: | it's not raid, no; nothing special really. | [13:52] |
| 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. | [13:52] |
| 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 | [13:52] |
| asciilifeform: | diana_coman: dulap had no ps kbd | [13:52] |
| diana_coman: | so then why all the ps stuff in the config as far as I see? anyway, not a big thing either way | [13:53] |
| asciilifeform: | this is why said 'not agressively', there is support enabled for certain irons that aint in any of the boxes | [13:53] |
| diana_coman: | ah, kk. | [13:53] |
| asciilifeform: | diana_coman: when you enable absent iron in config, it does no harm but to bloat the kernel. | [13:53] |
| diana_coman: | I know | [13:53] |
| asciilifeform: | hence e.g. 'ps kbd' is not problem. | [13:54] |
| asciilifeform: | support for usb kbd, amd's sata, etc. is enabled in the published config. | [13:54] |
| diana_coman: | asciilifeform: fwiw it is indeed compiling now the correctly-named bzImage | [13:54] |
| diana_coman: | rather less informative re activity than the earlier make but whatevs | [13:55] |
| asciilifeform: | this then matches asciilifeform's paper notes. | [13:55] |
| asciilifeform: | diana_coman: verify after that the kernel and initramfs actually get copied to /boot . | [13:55] |
| diana_coman: | myeah; and now I'll have to change the lilo.conf back too, lolz. | [13:56] |
| asciilifeform: | and after this as root run 'lilo' . aha | [13:56] |
| diana_coman: | anyways the compile seems like it will take a bit so I'll get back when it's done. | [13:56] |
| asciilifeform: | diana_coman: you dun have to use 'lilo' , can if you prefer 'grub', simply i use lilo. | [13:56] |
| diana_coman: | neah, I'm fine with lilo | [13:56] |
| asciilifeform: | aite. | [13:56] |
| diana_coman: | asciilifeform: and it failed with: binary /sbin/mount.zfs could not be found | [13:58] |
| asciilifeform: | zfs ?!! | [13:58] |
| diana_coman: | this is what the thing says, what can I do. | [13:59] |
| asciilifeform: | diana_coman: i must now ask, what didja boot for this procedure ? | [13:59] |
| diana_coman: | asciilifeform: hm? | [13:59] |
| diana_coman: | I booted from a usb stick, gentoo live cd | [14:00] |
| asciilifeform: | what is running on the machine where the chroot was carried out ? | [14:00] |
| asciilifeform: | ah | [14:00] |
| diana_coman: | iirc there was a way to ask no zfs | [14:00] |
| diana_coman: | ugh, wtf was it | [14:00] |
| asciilifeform: | diana_coman: can you paste the last 500ln leading up to the barf plz ? | [14:00] |
| diana_coman: | lemme see on that iron, 1 min | [14:01] |
| diana_coman: | ah, first might need to plug in the network, lolz | [14:01] |
| 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) | [14:02] |
| diana_coman: | it's using config with right name at least ie Dulap-III | [14:03] |
| diana_coman: | 1 min, I'll get a paste out of it | [14:03] |
| asciilifeform: | ty | [14:03] |
| diana_coman: | asciilifeform: http://paste.deedbot.org/?id=O9GU | [14:05] |
| asciilifeform: | looks | [14:05] |
| diana_coman: | there is a --no-zfs | [14:05] |
| diana_coman: | lemme try with that, again | [14:05] |
| asciilifeform: | genkernel --no-zfs --menuconfig all | [14:06] |
| asciilifeform: | aha | [14:06] |
| asciilifeform: | (for some reason wasn't necessary on bv's provided gentoo stick, with which this process to date carried out) | [14:06] |
| diana_coman: | dunno, I've made this bootable stick a while ago when I was trying out Cuntoo really | [14:07] |
| asciilifeform: | cuntoo carries 100\% own bin tooling tho. which is why it -- civilized, and this -- barbaric, yes | [14:07] |
| diana_coman: | if I'm at that I added --no-btrfs too, just-in-case. | [14:09] |
| diana_coman: | I don't see further --no to add, but we'll see | [14:09] |
| diana_coman: | well, at least it compiled now; it has a warning that additional kernel cmdline arguments may be required ie rootfstype=ext3 | [14:11] |
| diana_coman: | and now there is an initramfs in /boot too, let's see | [14:12] |
| asciilifeform: | verify that in /boot actually lie the kernel and initramfs, of the expected names, aha | [14:12] |
| diana_coman: | they seem to be there; lemme document + move on | [14:13] |
| asciilifeform: | ty | [14:13] |
| diana_coman: | lilo worked although it still whined about linear | [14:14] |
| 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. | [14:14] |
| asciilifeform: | never expected anyone would ask for it again. | [14:14] |
| diana_coman: | asciilifeform: tbh I wanted to ask "why not script" but anyway. | [14:15] |
| asciilifeform: | oughta be a script. but thought 'ah, but nao cuntoo' | [14:15] |
| diana_coman: | asciilifeform: uhm, just a bit ago you lashed out that "people not replicating asciilifeform's magic irons" | [14:15] |
| asciilifeform: | diana_coman: this os was proclaimed obsolete / abandoned. so no, did not expect it would have to be replicated again. | [14:16] |
| 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. | [14:16] |
| diana_coman: | asciilifeform: ugh, boot failed with filesystem mounted at /dev/sda2 does not appear to be valid / | [14:17] |
| diana_coman: | hm, fstab comes to mind | [14:17] |
| asciilifeform: | grrr i didn't mention fstab did i !!! | [14:17] |
| diana_coman: | lolz | [14:17] |
| diana_coman: | mk, back to it | [14:17] |
| 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. | [14:18] |
| asciilifeform: | of course fstab. | [14:18] |
| diana_coman: | but hm, my usb kbd is indeed not working, lol | [14:20] |
| asciilifeform: | is only thing not working ? | [14:20] |
| diana_coman: | wait, I need the kbd first to edit fstab, lol | [14:20] |
| diana_coman: | ps kbd to the rescue | [14:21] |
| asciilifeform: | diana_coman: also : when rebooted, was only the new disk present, or both usb booter and the new disk ? | [14:22] |
| asciilifeform: | the one you boot from, generally will appear as 'sda' | [14:22] |
| diana_coman: | asciilifeform: I took out the usb stick | [14:24] |
| asciilifeform: | diana_coman: do you get a command prompt from kernel ? ( when it refuses to mount / on /dev/sda2 ) ? | [14:25] |
| 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 | [14:25] |
| diana_coman: | I can get a shell | [14:25] |
| diana_coman: | ah shit | [14:26] |
| diana_coman: | that's not enough, is it | [14:26] |
| diana_coman: | ugh | [14:26] |
| asciilifeform: | oh fffs | [14:27] |
| asciilifeform: | in the given fstab, there is a disagreement w/the cookbook, diana_coman : | [14:27] |
| asciilifeform: | change the 'reiserfs' to ext4 plz. | [14:28] |
| asciilifeform: | otherwise /dev/sda1 still is /boot, and /dev/sda2 -- root. | [14:28] |
| diana_coman: | asciilifeform: link? | [14:29] |
| asciilifeform: | grr want to paste but paste.deedbot.org not loading here for some reason grrr | [14:29] |
| asciilifeform: | diana_coman: 'the given fstab' being referred to is the one in dulap.tar.gz. | [14:30] |
| asciilifeform: | that you presently have in that disk. | [14:30] |
| diana_coman: | asciilifeform: re paste.deedbot.org it's just that style sheet | [14:30] |
| diana_coman: | cut it out and it will load | [14:31] |
| asciilifeform: | diana_coman: how do i cut it out ? | [14:31] |
| diana_coman: | uhm, even a stop on the browser should do it; depends what you are using exactly | [14:31] |
| asciilifeform: | ok finally timed out. | [14:31] |
| diana_coman: | atm fighting it a bit to boot from stick rather than disk, lol | [14:31] |
| diana_coman: | or that , lol | [14:31] |
| asciilifeform: | so : the given ; | [14:31] |
| asciilifeform: | the desired . | [14:32] |
| asciilifeform: | brb in 10-15m | [14:33] |
| 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. | [14:33] |
| diana_coman: | I'll take a break too. | [14:33] |
| asciilifeform: | back | [14:42] |
| asciilifeform: | answering, grr, phones, may be slower than realtime for next half hr | [14:58] |
| 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 | [15:14] |
| diana_coman: | asciilifeform: any idea? | [15:14] |
| asciilifeform: | banished the phones, available nao for 3+h of gentoocement drill | [15:15] |
| asciilifeform: | diana_coman: waitasec , not boots from stick ?! | [15:15] |
| asciilifeform: | you didn't write to the stick, no ? | [15:16] |
| diana_coman: | asciilifeform: no; but hm, I should check the disk, makes sense | [15:16] |
| diana_coman: | it would be rather weird but anyway; kk, let's check it... | [15:16] |
| 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. | [15:22] |
| asciilifeform: | diana_coman: before you reimage it : | [15:22] |
| 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. | [15:22] |
| asciilifeform: | rather than the new disk. | [15:23] |
| 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. | [15:24] |
| asciilifeform: | ok | [15:24] |
| 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. | [15:25] |
| diana_coman: | asciilifeform: the kernel was written fine, I could even check now | [15:28] |
| 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. | [15:28] |
| diana_coman: | the shell I got mounted in read-only the / | [15:28] |
| diana_coman: | sigh | [15:29] |
| asciilifeform: | diana_coman: right but lilo writes directly to block 0 on the specified device | [15:29] |
| asciilifeform: | bypassing mount | [15:29] |
| diana_coman: | imaging now another stick anyway | [15:29] |
| diana_coman: | the image is 2.2G so apparently dd takes a while | [15:34] |
| asciilifeform: | not going anywhere, awaits output | [15:35] |
| diana_coman: | ok, new stick is ready, booted on it; mounted /dev/sda2 and changed that reiserfs to ext4 | [15:43] |
| diana_coman: | asciilifeform: do I need to do anything else before rebooting? | [15:43] |
| 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 | [15:43] |
| diana_coman: | ugh | [15:43] |
| asciilifeform: | if new-disk-alone dun boot, this will be the culprit. | [15:43] |
| diana_coman: | asciilifeform: so what do you suggest now? | [15:44] |
| 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. | [15:44] |
| asciilifeform: | then ought to be able to boot from the new disk alone. | [15:44] |
| diana_coman: | hm; let me try first and see if it boots, can't hurt anyway | [15:45] |
| asciilifeform: | ok | [15:45] |
| asciilifeform: | will be surprised if does | [15:45] |
| diana_coman: | asciilifeform: myeah, it does not; sigh. | [15:46] |
| asciilifeform: | lilo. | [15:47] |
| 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 ) | [15:48] |
| asciilifeform: | lilo will warn that 'you are not writing to first disk', this is to be expected. | [15:48] |
| diana_coman: | ok; booted now again from usb stick, let me see | [15:51] |
| 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 | [15:52] |
| asciilifeform: | (as it differs from the operational conf) | [15:53] |
| asciilifeform: | you will need to change both 'boot=...' and 'disk=...' . | [15:55] |
| 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 | [15:55] |
| diana_coman: | disk is same | [15:55] |
| asciilifeform: | diana_coman: you booted nao and stick is sdb ?! | [15:55] |
| diana_coman: | asciilifeform: I booted from usb stick; usb stick is still sdb, yes | [15:55] |
| asciilifeform: | but last time around was not ?! | [15:55] |
| diana_coman: | it was; hence why I don't quite get this part | [15:56] |
| asciilifeform: | ah but i get : | [15:56] |
| asciilifeform: | diana_coman: what does 'mount' command return ? | [15:56] |
| diana_coman: | asciilifeform: hm? | [15:56] |
| asciilifeform: | diana_coman: 1s. how is the disk attached to the machine ? | [15:57] |
| asciilifeform: | ( via snake ? i.e. plugged in after boot via stick ? or to sata ? ) | [15:57] |
| diana_coman: | asciilifeform: the usb stick is in usb port; the hard drive is main drive, sata | [15:57] |
| diana_coman: | there is no other drive (/me wanted to keep it simple) | [15:57] |
| asciilifeform: | may be the case that the bios is doing something odd w/ driver ordering on this iron. | [15:57] |
| asciilifeform: | if the ~new~ disk is in fact sda : then can execute 'lilo' with the given config. | [15:58] |
| asciilifeform: | and is to install on the new disk. | [15:58] |
| asciilifeform: | as described in the dox. | [15:58] |
| diana_coman: | well, I suppose I can execute lilo and see if it nukes this second drive too, lol | [15:58] |
| asciilifeform: | ensure that the config is unmodified and then yes. | [15:58] |
| diana_coman: | uhm; now it says fatal: default image doesn't exist; I think I might be getting too tired for this | [16:01] |
| asciilifeform: | diana_coman: before you stop, can you paste the barfola ? | [16:02] |
| asciilifeform: | diana_coman: i'ma repeat the entire process here, while you sleep . | [16:02] |
| diana_coman: | asciilifeform: it's literally just that; it says Added GentooDulap and then Default image doesn't exist | [16:02] |
| asciilifeform: | diana_coman: did you chroot 1st ? | [16:03] |
| diana_coman: | yes | [16:03] |
| diana_coman: | hm, I don't see a default line in lilo.conf, should there be one? | [16:03] |
| asciilifeform: | yes ! | [16:03] |
| asciilifeform: | lemme paste the original | [16:03] |
| asciilifeform: | http://paste.deedbot.org/?id=kSMh . | [16:04] |
| asciilifeform: | ^ is what's in the tarball. | [16:04] |
| asciilifeform: | if your boot aint mounted, then it won't find the kernel img, boot must be mounted. | [16:04] |
| 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. | [16:05] |
| diana_coman: | ok, now it worked | [16:05] |
| asciilifeform: | ok! let's fire it | [16:05] |
| diana_coman: | lilo ran fine; there is still the warning re LINEAR vs LBA32 | [16:06] |
| asciilifeform: | not seen this warn before | [16:07] |
| asciilifeform: | diana_coman: verify that the given image and initrd correspond to what lies inside /boot , and test-fire then. | [16:08] |
| 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; " | [16:08] |
| asciilifeform: | diana_coman: i suspect lba is disabled in your bios | [16:09] |
| asciilifeform: | should not make a diff tho here. | [16:09] |
| 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 / | [16:10] |
| diana_coman: | ugh | [16:10] |
| asciilifeform: | diana_coman: if you have the energy, plox to enable lba2 and try liloizing again | [16:10] |
| asciilifeform: | *lba32 | [16:10] |
| asciilifeform: | diana_coman: i assume you remembered to fix fstab ? | [16:10] |
| diana_coman: | asciilifeform: fixed fstab, yes; at least the usb stick is still working so running lilo was not the problem there | [16:11] |
| diana_coman: | let me see re lba2 | [16:11] |
| asciilifeform: | also i assume you rebooted w/ the usb stick removed, rather than simply used bios bootloader menu to select hdd ? | [16:12] |
| diana_coman: | asciilifeform: stick removed, yes | [16:12] |
| asciilifeform: | ok | [16:12] |
| asciilifeform: | btw given that you got this far, you have a kernel that boots, so lilo per se is prolly not the issue | [16:13] |
| asciilifeform: | diana_coman: how big is the new disk ? if it's >200GB, then iirc in fact demands lba32 to work | [16:14] |
| asciilifeform: | (to mount / , that is , which is to say to see whole disk) | [16:14] |
| diana_coman: | asciilifeform: ah, so that might be it; it's 1TB | [16:15] |
| asciilifeform: | aa! | [16:15] |
| 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) | [16:17] |
| diana_coman: | took stick out and booted, same trouble | [16:17] |
| asciilifeform: | but not mounts / ? | [16:17] |
| diana_coman: | it goes mounting /dev/sda2 as root.... | [16:18] |
| diana_coman: | Using mount -t auto -o ro | [16:18] |
| asciilifeform: | and then..? | [16:18] |
| diana_coman: | and then the filesystem ounted at /dev/sda2 does not appear to be a valid /, try again | [16:18] |
| diana_coman: | mounted* | [16:18] |
| diana_coman: | Could not find the root block device in . | [16:18] |
| diana_coman: | hm | [16:18] |
| asciilifeform: | diana_coman: is sata in ahci mode in bios ? | [16:20] |
| asciilifeform: | or 'legacy' | [16:20] |
| diana_coman: | asciilifeform: seems dubious that it says just "in ." | [16:20] |
| diana_coman: | I'd need to look, I don't remember for this box | [16:21] |
| 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. | [16:21] |
| asciilifeform: | diana_coman: can you paste plz the output of lsmod (when booted from working stick) ? | [16:21] |
| diana_coman: | lemme boot and look | [16:21] |
| asciilifeform: | ty | [16:21] |
| asciilifeform: | diana_coman: but if indeed this so, then if set to 'legacy' then oughta boot. | [16:22] |
| diana_coman: | asciilifeform: http://paste.deedbot.org/?id=t8Ci | [16:25] |
| asciilifeform: | looks | [16:25] |
| asciilifeform: | so it's a 'megaraid' chipset ? | [16:26] |
| diana_coman: | lemme fish out full spec | [16:27] |
| asciilifeform: | ty | [16:27] |
| asciilifeform: | diana_coman: plz meanwhile set 'legacy' in bios and see whether boots ; if yes, that nails the culprit | [16:28] |
| asciilifeform: | ( and then easy fix when i find out which iron is actually in there ) | [16:29] |
| asciilifeform: | errybody wants trimmed kernels, nobody wants ~this~, but it's a genuine dilemma. | [16:29] |
| asciilifeform: | diana_coman: plz also collect output of 'dmesg' on successfully booted stick. | [16:31] |
| asciilifeform: | (and paste.) | [16:31] |
| 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 | [16:31] |
| asciilifeform: | this is enuff, i can look up from the vendor. | [16:32] |
| diana_coman: | let me run dmesg, 1 min | [16:32] |
| asciilifeform: | diana_coman ty | [16:32] |
| diana_coman: | will have to go in 5 minutes so after that | [16:32] |
| 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. | [16:32] |
| diana_coman: | asciilifeform: fwiw indeed yes, sata IS set to ahci mode | [16:34] |
| diana_coman: | asciilifeform: and dmesg output http://paste.deedbot.org/?id=PGJr | [16:34] |
| asciilifeform: | try , before going plz, w/ 'legacy' . | [16:34] |
| 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. | [16:36] |
| asciilifeform: | then can get userland quickly. | [16:36] |
| 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. | [16:37] |
| diana_coman: | where the fuck was that legacy thing in this bios, arrgh | [16:37] |
| asciilifeform: | where 'ahci' is now | [16:37] |
| diana_coman: | lolyes | [16:37] |
| 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. | [16:38] |
| asciilifeform: | i am in newyork time btw. | [16:39] |
| asciilifeform: | brb | [16:39] |
| diana_coman: | asciilifeform: it will have to be laters/tomorrow | [16:40] |
| 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 | [16:59] |
| 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 | [16:59] |
| whaack: | let me know if this is off the mark. in any event gn diana_coman | [17:02] |
| asciilifeform: | starts the process, 1st to prep boot stick... | [17:06] |
| 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. | [20:58] |
| asciilifeform: | diana_coman: it is done!! i have reproduced fully the dulap-baking process. will deedbot the new, corrected and tested recipe, shortly. | [23:40] |
| asciilifeform: | diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-11#1945002 . | [23:50] |
| ossabot: | (trilema) 2019-10-11 asciilifeform: !!deed http://www.loper-os.org/pub/dulap_construction_kit_r2.txt | [23:50] |
| asciilifeform: | diana_coman: would not have taken so long as it did, but this is VERY slow box. kernel compile 2+hrs. | [23:50] |
| asciilifeform: | the test machine booted as-expected on 1st try, and is running now. | [23:53] |
| 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. | [23:55] |
| 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. | [23:58] |
| asciilifeform: | with working box, nao, finally to bed. | [23:58] |
Comments feed: RSS 2.0