[10:01] <jussi> Hi peoples. Im on Raring and my kernel wont install - is it known? and are you fixing it? :D
[10:07] <jussi> http://paste.ubuntu.com/5712775/
[10:13] <smb> gzip: stdout: No space left on device
[10:14] <smb> jussi, That you have to fix on your own ;)
[10:15] <ogra_> smb, nah, its your fault, make smaller kernels !
[10:15] <ogra_> :)
[10:16] <smb> ogra_, :-P
[10:19] <ppisati> apw: so, given the same hw but two different kernels, the two kernels generate different uuids for the same partition
[10:19] <ppisati> apw: what could it be?
[10:19] <ogra_> are you sure its the kernel ? UUIDs are usually a userspace thing, no ?
[10:19] <ogra_> tied to the filesystem
[10:27] <ppisati> ogra_: same hw but two different kernels
[10:27] <ppisati> ogra_: if the kernel is the only variable to change, and uuids change
[10:27] <ppisati> ogra_: it must be kernel related
[10:28] <ogra_> well, then i would look at the filesystem code 
[10:28] <ogra_> theoretically it cant be since the UUID is stamped into the filesystem though 
[10:28] <ppisati> eh
[10:29] <ppisati> but truste me it just happened to me :)
[10:29] <ogra_> heh, yeah, i dont deny that :)
[10:30] <ogra_> so if you see them differently with i.e. the blkid command, looking at what this calls  and then crawl into the kernel might help
[10:31] <ppisati> ls -la /dev/disk/by-uuid/
[10:31] <ppisati> show same partitions, but different uuids
[10:31] <ogra_> and blkid does the same ?
[10:31] <ogra_> iirc it asks the kernel directly
[10:32] <ppisati> ogra_: 99% i think it does the same
[10:32] <ppisati> ogra_: didn't strace it yet
[10:41] <apw> ppisati, those are often calculated from disk serial numbers and the like, if there was a change there it could change the uuids
[10:41] <apw> ppisati, it would be highly undesirable of couse
[10:41] <ppisati> apw: yeah
[10:41] <ppisati> apw: never mind anyway...
[10:43] <apw> ppisati, did you suss it out ?
[10:43] <ppisati> apw: yes, and it wasn't a kernel config... don't let me say anything... :)
[10:43] <apw> heh ok :)
[11:00] <apw> zequence, your uploads are reviewed and sponsored into the kernel ppa, sorry for the delay
[11:01] <apw> ogra_, we have a specifiic initrd configuration for the nexus images, what makes that different
[11:01] <apw> ogra_, (i am assuming you were involved :)
[11:11] <ogra_> apw, the size limit and plkymouth bugs
[11:12] <ogra_> the combo of kernel and initrd cant be bigger than 8M ...
[11:12] <ogra_> and plymouth halts the system if console-setup didnt tun before it starts
[11:14] <ogra_> *run
[11:18] <ogra_> apw, the code for that  is in ubuntu-defaults-nexus7 and in ac100-tarball installler 
[11:28] <apw> ogra_, great ... i want to see if we can elide the filesystem modules we know we do not need
[11:29] <ogra_> well, keep them but use MODULES=list for the initrd (and indeed dont supply a list)
[11:30] <ogra_> so you end up without modules in there but have them on the fs
[11:30] <ogra_> (we should probably just patch initramfs-tools one day to accept MODULES=none for such cases)
[11:37] <apw> ogra_, i was thinking the same, move to list, and don't specify any
[11:38] <ogra_> i do that since years for arm stuff :)
[11:38] <ogra_> the android based devices usually have a limited partition for kernel/initrd
[11:40]  * ppisati -> out for lunch
[11:49] <zequence> apw: Thanks
[12:12] <apw> ogra_, so i think you are saying that something like this would be reasonable for the n7 images: http://paste.ubuntu.com/5712980/
[12:12] <apw> ogra_, not of course that that helps any with how the phablet images are built yet
[12:12] <ogra_> COMPRESS=lzma helps too 
[12:13] <ogra_> and FRAMEBUFFER=Y in case we will ever use plymouth (we dont currently)
[12:14] <ogra_> but yeah, MODULES=list is essential 
[12:14] <ogra_> note that ac100-tarball-installer puts that in place during the nexus7 install
[12:15] <apw> ogra_, we seem to have FRAMBUFFER=y in another, file, COMPRESS=lzma sounds like a good plan
[12:15] <ogra_> ogra@anubis:~/Devel/packages/ac100-tarball-installer-0.45$ cat conf.d/ac100-installer 
[12:15] <ogra_> MODULES=list
[12:15] <ogra_> BOOT=installer
[12:15] <ogra_> COMPRESS=lzma
[12:15] <apw> ogra_, it does, it is not on my image, but perhaps it is too old, 
[12:15] <ogra_> thats what we use during install
[12:15] <apw> ogra_, it does? was what i mean
[12:16] <ogra_> oh
[12:16] <ogra_> no it *should* but it doesnt 
[12:16] <apw> ogra_, or am i conflating this with ac100 and n7
[12:16] <ogra_> it does it for ac100 ... no idea why i didnt add it for nexus7 too
[12:17] <apw> ogra_, ahh, so i'll let you fix that :)
[12:17] <ogra_> i'm sure it is somewhere in the install 
[12:17] <ogra_> let me dig 
[12:17] <ogra_> else our initrd wouldnt work 
[12:17] <apw> ogra_, i see modules getting sucked up into my initramfs's
[12:17] <ogra_> k
[12:17] <apw> ogra_, it is only that the n7 kernel has a lot turned off we don't get too big
[12:17] <ogra_> then soemthing is wrong 
[12:18] <apw> indeed when i harmonize the filesystems it immediatly is too big
[12:18] <apw> but my image might be older, if you have recent install you could check
[12:18] <ogra_> i dont
[12:19] <apw> ok
[12:19] <ogra_> hmm, yeah, seems to be no code for it at all
[12:19] <ogra_> so yeah, add yours :)
[12:19] <ogra_> though probably not to /etc
[12:20] <ogra_> use /usr/share/initramfs-tools/conf.d/  for packaged configs ... /etc is for admins to override
[12:20] <ogra_> (or for hacks that arent properly packaged) 
[12:23] <apw> ogra_, ok
[13:00] <rtg> ogasawara, yesterday I realized that the module config work on the N[47] kernels is next to impossible to test on the touch image until rsalveti swaps Ubuntu with Android to run as the boot O/S. Android cannot use the Ubuntu /lib/modules.
[13:01] <ogasawara> rtg: ack, I'll just push them out a bit
[13:01] <rtg> I think the initrd works OK since it gets flashed along with the kernel
[13:02] <apw> rtg, do we know if they are going to definatly do that even ?
[13:02] <rtg> apw, I think he's qorking on it
[13:02] <rtg> working*
[13:02] <apw> rtg, actually is that true in the sense at least the kernel outside if taken from our source is built outside too
[13:02] <apw> obviously from an update point of view it is true
[13:03] <rtg> apw, huh? cannot parse.
[13:03] <apw> in the image generation, if the builder takes our deb as 'source' and takes the binaries from there, they would be outside in the android world so modules would be ok there i think
[13:04] <apw> but ... on update from us, the modules are trapped so it _is_ a problem then
[13:04] <rtg> apw, only those in the initrd
[13:04] <apw> nasty
[13:05] <rtg> apw, oh, I see what you're saying. perhaps that might work but we'd have to craft an update that works under Android
[13:05] <apw> right and we don't have that now for sure
[13:05]  * rtg -> bbias
[13:05] <apw> though, if you are root in our chroot, what stops you probing the chroot modules into the kernel
[13:22] <rtg> apw, nothing stops you, but it is not currently automatic. the ubuntu chroot is not started by default.
[13:34] <ogra_> rtg, the android initrd (As we use it now) doesnt contain any modules ... its only a few bytes big .... the current prob is that we would need to update the android one and cant use the ubuntu one ... 
[13:35] <ogra_> and its still not clear that we can actually flip the container models
[13:35] <rtg> ogra_, ack
[13:35] <ogra_> in the worst case scenario we need to come up with a way to actually update the android initrd from the ubuntu side ... and accordingly install our modules into the android paths 
[13:36] <ogra_> (on the rootfs)
[13:37] <ogra_> i dont think android even uses modprobe ... they usually insmod the modules from init.rc
[13:37] <rtg> ogra_, ick, what a hack.
[13:37] <ogra_> with full path and options 
[13:37] <ogra_> yeah, its awful ... better pray that the flip works :)
[13:39] <ogra_> i guess installing the modules is easy by adding some symlinks ... though it might be that /system is readonly which could cause probs 
[13:39] <apw> ogra_, it is not clear why it would not be possible, we have pure ubuntu on the N7 desktop images
[13:39] <ogra_> apw, the question is if androids HW layer is still functional if you put it into a container
[13:40] <rtg> apw, doesn't the N4 do some sort of signing thing ?
[13:40] <ogra_> we need the drivers ... and they are not only linked against bionic instead of libc, but also all armel :)
[13:40] <apw> rtg, hmmm dunno maybe, but we are signing whatever crap we put on there now don't we ?
[13:41] <apw> it is good to see this is all resolved well before freeze
[13:41] <rtg> apw, not as far as I knwo, but I guess we _are_ booting our kernel so maybe signing isn't an issue.
[13:41] <ogra_> haha
[13:41] <apw> rtg, yeah thats my assumption
[13:41] <ogra_> on nexus signing sholdnt be an issue ... 
[13:42] <ogra_> on all other platforms it might become one
[13:42] <ogra_> even on one we will be preinstalled on
[13:42] <ogra_> but thats 13.10 material i guess
[13:42] <apw> ogra_, well we do at least have precident with the win8 poop
[13:42] <ogra_> :)
[13:42] <apw> so we know how to do it 'safely'
[13:43] <ogra_> yeah, but yu might have to rely on hackish solutions the vendor picked
[13:43] <ogra_> there isnt a standard like UEFI on android 
[13:43] <ogra_> its usually some fastboot based loader ... 
[13:44] <ogra_> and you cant replace the bootloader since it is usually signed with a factory key 
[13:44] <ogra_> (else we could switch to arm-grub or u-boot and life would be easier)
[13:45] <ogra_> the fastboot based loaders can even contain a hardcoded and signed GPT so you cant ever resize the boot partition for example 
[13:46] <apw> quality and no mistake
[13:46] <ogra_> :)
[13:47] <ogra_> well, if you measure quality by "lock out the users effectively" they surely did a good job here 
[13:47] <apw> almost as good as raring daily qualit
[13:47] <ogra_> (and i think thats what carriers are usually after)
[13:54] <sforshee> ppisati, have you been looking into the nexus 4 ftrace problems?
[13:54] <ppisati> sforshee: nope, i'm stuck with calxeda :(
[13:54] <ppisati> sforshee: i wish i can give it a look
[13:55] <sforshee> ppisati, ack. I just wanted to be sure we weren't duplicating effort
[13:55] <sforshee> did you have any ideas about the email I sent?
[13:56] <ppisati> sforshee: nope, really
[13:56] <ppisati> sforshee: i din't look at the code closely
[13:56] <cking> sforshee, I've not had a chance to look at this yet today either
[13:57] <sforshee> ppisati, I guess I'll start digging into the code today. The write that's failing for me seems to be smack in the middle of the kernel text, so I have no idea why it fails
[13:57] <sforshee> when so many before it succeed
[13:58] <sforshee> ppisati, do you know if there's some way to dump the arm page table attributes?
[13:59] <ppisati> sforshee: not really
[14:00] <ppisati> sforshee: btw, when i turned on ftrace, my kernel refused to boot
[14:01] <sforshee> ppisati, my kernel boots, however the screen stays blank
[14:01] <ppisati> sforshee: do you have a cgf diff?
[14:02] <ppisati> *cfg
[14:02] <sforshee> ppisati, I can generate one, just a sec
[14:04] <sforshee> ppisati, http://pastebin.ubuntu.com/5713232/
[14:04] <ppisati> sforshee: i'll give it a try later, thanks
[14:05] <sforshee> ppisati, the test options are completely unnecessary, the failure happens during ftrace initialization when DYNAMIC_FTRACE=y
[14:08] <jussi> smb: I thought there was some preinstall script that cleaned up old kernels so this didnt happen ?
[14:09] <rtg> jjohansen, need to reboot tangerine for the openssl update
[14:10] <smb> jussi, I would not know of any pre-install script (probably also depends on whether one uses updatemanager or dist-upgrade). For Raring, running apt-get autoremove seems to result in some housekeeping
[14:11] <jussi> smb: yeah, unfortunately autoremove isnt really nice to me - it removes lots of things I still want. anyway, Ill remove an old kernel or 2. Frustrating though
[14:11] <jussi> (and yes, I should have read the error message properly... :P )
[14:12] <smb> It sometimes helps. ;)
[14:41] <rtg> cking, henrix: need to reboot gomeisa for SSL update
[14:46] <rtg> ogasawara, we definitely need to upload 3.8.7 before final. it fixes a Thinkpad suspend regression.
[14:47] <rtg> I suspect its 'Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"' 'cause I saw a bunch of ACPI noise in my log
[14:50] <ogasawara> rtg: ack, lets try to get it in today since final freeze is Thurs.
[14:50] <ogasawara> rtg: well, I guess we could give it another day too in case something else lands
[14:50] <rtg> ogasawara, 3.8.8 is gonna release by tomorrow
[14:50] <ogasawara> rtg: so lets wait
[14:50] <rtg> ack
[14:54] <rtg> jsalisbury, 3.8.6 appears to have fixed some Raring suspend regressions, at least on my Thinkpad. you might keep that in mind as you're processing bug reports.
[14:54] <jsalisbury> rtg, ok, thanks
[14:54] <jsalisbury> rtg, I'll ask for testing of some of the existing reports as well
[15:07] <rsalveti> rtg: ogra_: ogasawara: I tested the n4 kernel and it worked fine, have a pending mr to replace the kernel from boot.img to the one provided by the package
[15:08] <rsalveti> regarding modules, as long we have the core part as built-in, we're good
[15:08] <ogra_> will you autosync into phablet.u.c ?
[15:08] <rtg> rsalveti, sort of, until someone wants to plug in a USB gizmo, or mount a stange file system.
[15:09] <rsalveti> rtg: ogra_: sure, but the problem is that we don't have different raring images per device
[15:09] <rsalveti> so we can't yet install the kernel package at the image by default
[15:10] <ogra_> yeah
[15:10] <rsalveti> in case the user wants to use a module, he would need to install the package by hand
[15:10] <rsalveti> and then it should work, as the kernel is the same, so binary compatible
[15:10] <rsalveti> ogra_: my idea is to disable the kernel build part of the android image
[15:10] <rsalveti> and just use a pre-built image, and try to keep that in sync
[15:11] <rsalveti> at jenkins we have a script that will download the latest every time
[15:11] <ogra_> well, as long as youo dont add more sources for me to pull from while building the android layer :P
[15:11] <rsalveti> no, it's easier actually
[15:11] <rsalveti> and will reduce the build time as well
[15:11] <ogra_> i'm just concerned about more holes in the firewall to the livefs builder 
[15:11] <rsalveti> rtg: ogasawara: there's only one extra requirement now from the app dev team, which is to support lttng
[15:12] <rsalveti> and for that we'd need working kernel packages for maguro and manta (galaxy nexus and nexus 10)
[15:12] <ogra_> since each of these changes delays me waiting for IS
[15:12] <rsalveti> ogra_: right, they will be available via phablet.u.c
[15:12] <ogra_> great
[15:12] <rsalveti> rtg: ogasawara: and also a backport of the latest apparmor patch set used 
[15:13] <rsalveti> as they will still be used as dev target 
[15:15] <jsalisbury> **
[15:15] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:15] <jsalisbury> **
[15:15] <rtg> rsalveti, ogasawara: prolly ought to get those listed as work items so we don't forget.
[15:15] <rsalveti> rtg: yup, indeed
[15:15] <rtg> rsalveti, doesn't lttng use ftrace ?
[15:17] <rsalveti> rtg: I think it lttng is trying to reuse some pieces from ftrace
[15:17] <rsalveti> but they still need external modules
[15:17] <rsalveti> which is provided via dkms at ubuntu
[15:17] <rtg> rsalveti, seems like sforshee and cking were having problems with ftrace on the Nexus kernels
[15:18] <rsalveti> rtg: hm, interesting
[15:18] <rsalveti> well, lttng provides both user and kernel tracing, so at least some part should work
[15:18] <sforshee> rsalveti, yeah there's a problem with dynamic ftrace atm on the nexus 4
[15:19] <rsalveti> sforshee: is that specific to this kernel or for the upstream 3.4 one as well?
[15:19] <sforshee> rsalveti, I was told that it worked in generic 3.4, but I'd have to refer you to cking and ppisati for confirmation of that
[15:20] <rsalveti> sforshee: right, but good to know
[15:20] <cking> i believe that's what ppisati concluded
[15:20] <rsalveti> will give that a test later today to see if it works at least enough for lttng
[15:21] <sforshee> rsalveti, the problem is that dynamic ftrace inserts calls to a function named mcount at the start of just about every kernel function, then at boot overwrites those calls with noops
[15:21] <sforshee> at some point writing the noop fails, and ftrace disables itself as a result
[15:22] <rsalveti> rtg: should I put the WIs for you there?
[15:22] <rtg> rsasure
[15:22] <rtg> rsalveti, sure
[15:22] <jdstrand> rsalveti, rtg: hey, where is that apparmor work item being tracked?
[15:23] <rtg> jdstrand, Blueprint foundations-1303-phablet-kernel-maintenance] I think
[15:23] <rtg> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance
[15:23] <rsalveti> jdstrand: we can probably track it at https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance
[15:24] <jdstrand> ok, thanks. /me subscribes
[15:24] <jdstrand> oh, I already am :)
[15:25]  * henrix -> back in 15
[15:25] <jdstrand> jjohansen: fyi, I also subscribed you to ^
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[17:18]  * ppisati -> EOD
[17:28]  * rtg -> lunch
[17:46]  * cking EOD too
[21:59]  * rtg -> EOD