22700+ entries in 0.061s
mod6: <+trinque> mod6: what'd that ext error end up being? << i needed to add the correct AKI to the AMI created from the Volume Snapshot.
mod6: mircea_popescu: ty :]
mod6: lol, i didn't emerge sudo
mod6: gentoo stage3, amd64, hardened, nomultilib
mod6: root 1 0.2 0.0 4248 1508 ? Ss 13:33 0:01 init [3]
mod6: ec2-user@ip-172-31-7-151 ~ $ ps aux | grep "init"
mod6: Linux ip-172-31-7-151 3.18.11-gentoo #1 SMP Sun May 3 14:58:30 CDT 2015 x86_64 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz GenuineIntel GNU/Linux
mod6: ec2-user@ip-172-31-7-151 ~ $ uname -a
mod6: got it working, logged into gentoo instance built with my own stage3 ami
mod6: <+jurov> mod6 if the guest does have /etc/rc.conf then it's not systemd, tha'ts ruled out << ok *whew*. so yeah, both the parent and the chroot *have* /etc/rc.conf
mod6: ok jurov: got the log; I don't see any reference to systemd in there -- but keep in mind this is the parent system.
mod6: <+jurov> mod6 try looking into /var/log/rc.log << there is no rc.log
mod6: and under /etc/systemd there is one directory, 'network', which has nothing in there.
mod6: there are a bunch of scripts in /etc/init.d
mod6: <+jurov> iirc systemd does not do /etc/local.d << ok so yeah, i have these: 00_getsshkey.start 00_getsshkey.stop in /etc/local.d
mod6 is not a linux ninja
mod6: hmm. now that, i do not know. once I get it up and going, i'll have to see what kinda clown cars are spinning in there.
mod6: <+jurov> anyway, mod6 has to check /etc/init.d whether clud init is there << i would check on the target environment, but i can't even get in there. I'll check in the chroot'd to-be-ami'd fs.
mod6: So when it asked me, I picked a keypair that I already had in use. just expected it to let me use that... but guess not.
mod6: the good news is, I got my gentoo-stage3 to boot without a kernel panic. the bad news seems to be that i can't seem to login... something went sideways with the pubkey auth
mod6: but overnight my nmon capture died :<
mod6: 187980 << im at this block
mod6: so about 10x that much eh
mod6: ;;calc 50655817/1024000
mod6: anyway, if my grub looks good, then maybe it's my kern. but it could be something else... not quite sure.
mod6: <+trinque> and otherwise if all else fails I'll be putting my own build script together before long << ok sweet!
mod6: <+trinque> may help; that's a working gentoo kernel out on ec2 << i'll try this out tomorrow
mod6: # ./bitcoind -datadir=/mnt/btc-dev/.bitcoin getblockcount
mod6: yeah isn't that what i have in grub? ^^^
mod6: oh well, i guess we can pick it back up tomorrow.
mod6: has the same error in the System Log.
mod6: trinque: same thing :/
mod6: trinque: from grub??
mod6: (in `make menuconfig`)
mod6: well, i guess I didn't have EXT3 enabled, just: "Use ext4 for ext2/ext3 file systems" under "Filesystems"
mod6: trinque: where can I add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot params? I don't see anything thing like that in the kernel config -- except where I've already enabled EXT4 and EXT3
mod6: I should re-iterate that I'm still waiting on a pogo to come to me...so this v0.5.3.1+OrphanageNuke test is running on AWS deb6 (amd64)
mod6: it's fine, I just didn't realize that in the filename, the turdolator uses SHA1
mod6: 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78 asciilifeform_orphanage_thermonuke.patch
mod6: # sha512sum asciilifeform_orphanage_thermonuke.patch
mod6: ok bitcoin-v0_5_3_1 + Orphanage Nuke is running with `nmon -f -s3` & `vmstat 1`, so we should have some good metrics when complete.
☟︎ mod6: i try it with that...
mod6: i thought that one thing said that I didn't need Grub unless i was using hvm or whatever.
mod6: i guess I can rebuild again and stick that in there.
mod6: i had build this kernel yesterday. i don't see anything about "ROOTSTYPE" in my config that I used... (posted above)
mod6: that's for the kernel config right?
mod6: no fails 1/2 checks, kernel panic'd
mod6: i'll post my build steps.
mod6: mine matches just fine too. thx for digging that up.
mod6: ah sha1, see, derp derperton
mod6 builds new instance with AMI
mod6: sweet, new ami complete.
mod6: what purpose would it serve?
mod6: otherwise, why do it?
mod6: yeah, shoudn't being the key word there; in my mind, it certainly should match.
mod6: The hash referenced inthe email was for the bitcoin-v0_5_3_1-RELEASE.tar.gz tarball, which is correct.
mod6: i thought it /was/ supposed to be the same. but, maybe im just derp derperton tonight.
mod6: ok gotcha. just need some clairification from jurov on that.
mod6: s/files/and sig files/
mod6: if not, see if they came out same as mine from my dpaste
mod6: yep, got that too... but check the sha256's of the dl'd patch files, see if they match the checksums that the ml inserted into the file name.
mod6: ... taking gentoo snapshot for 3rd AMI attempt.
mod6: -rw-r--r-- 1 root root 4007 May 5 00:19 asciilifeform_orphanage_thermonuke.patch
mod6: mircea_popescu: anyway, yeah, agreed. I did look it over, and is matching from website as far as I can tell. & byte count is the same.
mod6: these are the commands I ran:
mod6: i wonder if I did something wrong... jurov?
mod6:
http://dpaste.com/1NHSMPB.txt << patched into bitcoin-v0_5_3_1-RELEASE, sig looks good, although the hash's didn't match what the filename was changed to on btc-dev ml
mod6: that may help too. i'll let you know how it goes. much appreciated.