[07:01] <deffrag> Hello! Is <sudo cat /dev/sda5 | md5sum> the right way to get md5sum for sda5 partition? Or what exactly will the command do?
[13:46] <ryant5000> how would I go about building a 3.4 kernel on/for Amazon EC2? i'm on Precise, and I grabbed a clone of the git repo, but i don't see how to build the "virtual" flavour
[15:36] <bjf> ryant5000, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel , down in the "Building the Kernel" section substitute "binary-virtual" for "binary-generic"
[15:37] <bjf> ryant5000, i just kicked one off myself, if that doesn't work, i'll know in a little bit
[15:37] <ryant5000> bjf: hm, i tried that, but it said it couldn't find binary-virtual
[15:37] <ryant5000> bjf: where did you get your sources?
[15:38] <ryant5000> bjf: i was building from a tag in git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
[15:39] <ryant5000> bjf: i got the impression that somehow the sources i had didn't include a virtual flavour
[15:43] <bjf> ryant5000, i did: fakeroot debian/rules clean; fakeroot debian/rules binary-virtual
[15:44] <bjf> ryant5000: and it's building as we speak
[15:44] <ryant5000> hm, ok; and was your source from that same git repo?
[15:45] <bjf> ryant5000: i am building precise which was cloned from the ubuntu precise repo
[15:45] <ryant5000> bjf: ok, i guess maybe it was a mistake to check out a tag; i'll give it a try from master
[15:46] <bjf> ryant5000: which tag did you use ?
[15:46] <ryant5000> bjf: i don't recall exactly, but i think it was the latest tag with a 3.4 version number
[15:47] <bjf> ryant5000: that should work
[15:47] <bjf> ryant5000: um, actually ... 3.4? precise is based on 3.2
[15:48] <ryant5000> bjf: right :) i was hoping to upgrade
[15:48] <ryant5000> bjf: i'd like to use a couple of features from the new kernel
[15:49] <bjf> ryant5000: so you have a different option, use the "lts backport" kernel which is a quantal kernel built to run on precise userspace
[15:49] <ryant5000> bjf: ah, ok; i think i recall seeing that branch
[15:49] <bjf> ryant5000: it's not really a "backport" just what we call it
[15:49] <ryant5000> bjf: right; makes sense
[15:49] <bjf> ryant5000: there's one all built
[15:50] <bjf> ryant5000: it is built everytime the regular quantal kernel is built
[15:50] <ryant5000> bjf: oh, can i just grab the deb? i'm not trying to do anything fancy, just a stock 3.4 or later kernel
[15:50] <ryant5000> (i did try searching for it, but I wasn't able to find it)
[15:50] <bjf> ryant5000: yes, or it's in a ppa ... one sec
[15:52] <bjf> ryant5000: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[15:53] <bjf> ryant5000: there are other packages there but you want "linux-lts-quantal"
[15:53] <ryant5000> ok, cool
[15:53] <ryant5000> bjf: thanks; i'll give that a shot
[15:54] <bjf> ryant5000: easier than building your own (though that isn't too bad)
[15:55] <ryant5000> bjf: yeah, definitely; the build process is way easier than the last time i tried (years ago)
[16:30] <ryant5000> bjf: so, that backports ppa doesn't seem to have the -virtual packages either
[16:30] <ryant5000> bjf: if i'm going to build myself, should i be building out of the precise or quantal repositories?
[17:47] <bjf> ryant5000: in quantal the virtual flavour was eliminated
[17:47] <ryant5000> bjf: hm; so i guess i'll have to tell pv-grub to take the generic flavour
[17:48] <ryant5000> bjf: it says something about ignoring the generic kernel when it updates grub
[17:48] <ryant5000> maybe i'll just run on the quantal daily for a while
[18:55] <dileks> hi
[18:55] <dileks> I used a quantal kernel-config as base for my linux-next kernel
[18:56] <dileks> diff: http://paste.ubuntu.com/1091987/
[18:56] <dileks> now there are new variables CONFIG_MEDIA_*_SUPPORT to sort camera|tv|radio|rc
[18:57] <dileks> what I did was a 'yes "" | make oldconfig'
[18:58] <dileks> as CONFIG_MEDIA_*_SUPPORT=n turned off all dvb|radio|rc|camera modules/built-in stuff
[18:59] <dileks> any other magic make-option where I can keep old media-configs?
[19:33] <deffrag_> Hello! I've a question related to ARM. As mentioned in line comment 23-28 here - http://lxr.free-electrons.com/source/arch/arm/kernel/kprobes-common.c - R15 gives PC+8 in the first cycle of an instruction then PC
[19:49] <deffrag_> Oops! R15 gives PC+8 in the first cycle of an instruction then PC+12 in subsequent cycles. What is the reason for that?