/srv/irclogs.ubuntu.com/2013/04/16/#ubuntu-kernel.txt

=== amitk is now known as amitk-afk
=== dupondje_ is now known as dupondje
=== amitk-afk is now known as amitk
jussiHi peoples. Im on Raring and my kernel wont install - is it known? and are you fixing it? :D10:01
jussihttp://paste.ubuntu.com/5712775/10:07
smbgzip: stdout: No space left on device10:13
smbjussi, That you have to fix on your own ;)10:14
ogra_smb, nah, its your fault, make smaller kernels !10:15
ogra_:)10:15
smbogra_, :-P10:16
ppisatiapw: so, given the same hw but two different kernels, the two kernels generate different uuids for the same partition10:19
ppisatiapw: 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 filesystem10:19
ppisatiogra_: same hw but two different kernels10:27
ppisatiogra_: if the kernel is the only variable to change, and uuids change10:27
ppisatiogra_: it must be kernel related10:27
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
ppisatieh10:28
ppisatibut truste me it just happened to me :)10:29
ogra_heh, yeah, i dont deny that :)10:29
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 help10:30
ppisatils -la /dev/disk/by-uuid/10:31
ppisatishow same partitions, but different uuids10:31
ogra_and blkid does the same ?10:31
ogra_iirc it asks the kernel directly10:31
ppisatiogra_: 99% i think it does the same10:32
ppisatiogra_: didn't strace it yet10:32
apwppisati, those are often calculated from disk serial numbers and the like, if there was a change there it could change the uuids10:41
apwppisati, it would be highly undesirable of couse10:41
ppisatiapw: yeah10:41
ppisatiapw: never mind anyway...10:41
apwppisati, did you suss it out ?10:43
ppisatiapw: yes, and it wasn't a kernel config... don't let me say anything... :)10:43
apwheh ok :)10:43
apwzequence, your uploads are reviewed and sponsored into the kernel ppa, sorry for the delay11:00
apwogra_, we have a specifiic initrd configuration for the nexus images, what makes that different11:01
apwogra_, (i am assuming you were involved :)11:01
ogra_apw, the size limit and plkymouth bugs11:11
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 starts11:12
ogra_*run11:14
ogra_apw, the code for that  is in ubuntu-defaults-nexus7 and in ac100-tarball installler 11:18
apwogra_, great ... i want to see if we can elide the filesystem modules we know we do not need11:28
ogra_well, keep them but use MODULES=list for the initrd (and indeed dont supply a list)11:29
ogra_so you end up without modules in there but have them on the fs11:30
ogra_(we should probably just patch initramfs-tools one day to accept MODULES=none for such cases)11:30
apwogra_, i was thinking the same, move to list, and don't specify any11:37
ogra_i do that since years for arm stuff :)11:38
ogra_the android based devices usually have a limited partition for kernel/initrd11:38
* ppisati -> out for lunch11:40
zequenceapw: Thanks11:49
apwogra_, so i think you are saying that something like this would be reasonable for the n7 images: http://paste.ubuntu.com/5712980/12:12
apwogra_, not of course that that helps any with how the phablet images are built yet12:12
ogra_COMPRESS=lzma helps too 12:12
ogra_and FRAMEBUFFER=Y in case we will ever use plymouth (we dont currently)12:13
ogra_but yeah, MODULES=list is essential 12:14
ogra_note that ac100-tarball-installer puts that in place during the nexus7 install12:14
apwogra_, we seem to have FRAMBUFFER=y in another, file, COMPRESS=lzma sounds like a good plan12:15
ogra_ogra@anubis:~/Devel/packages/ac100-tarball-installer-0.45$ cat conf.d/ac100-installer 12:15
ogra_MODULES=list12:15
ogra_BOOT=installer12:15
ogra_COMPRESS=lzma12:15
apwogra_, it does, it is not on my image, but perhaps it is too old, 12:15
ogra_thats what we use during install12:15
apwogra_, it does? was what i mean12:15
ogra_oh12:16
ogra_no it *should* but it doesnt 12:16
apwogra_, or am i conflating this with ac100 and n712:16
ogra_it does it for ac100 ... no idea why i didnt add it for nexus7 too12:16
apwogra_, 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
apwogra_, i see modules getting sucked up into my initramfs's12:17
ogra_k12:17
apwogra_, it is only that the n7 kernel has a lot turned off we don't get too big12:17
ogra_then soemthing is wrong 12:17
apwindeed when i harmonize the filesystems it immediatly is too big12:18
apwbut my image might be older, if you have recent install you could check12:18
ogra_i dont12:18
apwok12:19
ogra_hmm, yeah, seems to be no code for it at all12:19
ogra_so yeah, add yours :)12:19
ogra_though probably not to /etc12:19
ogra_use /usr/share/initramfs-tools/conf.d/  for packaged configs ... /etc is for admins to override12:20
ogra_(or for hacks that arent properly packaged) 12:20
apwogra_, ok12:23
rtgogasawara, 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:00
ogasawarartg: ack, I'll just push them out a bit13:01
rtgI think the initrd works OK since it gets flashed along with the kernel13:01
apwrtg, do we know if they are going to definatly do that even ?13:02
rtgapw, I think he's qorking on it13:02
rtgworking*13:02
apwrtg, actually is that true in the sense at least the kernel outside if taken from our source is built outside too13:02
apwobviously from an update point of view it is true13:02
rtgapw, huh? cannot parse.13:03
apwin 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 think13:03
apwbut ... on update from us, the modules are trapped so it _is_ a problem then13:04
rtgapw, only those in the initrd13:04
apwnasty13:04
rtgapw, oh, I see what you're saying. perhaps that might work but we'd have to craft an update that works under Android13:05
apwright and we don't have that now for sure13:05
* rtg -> bbias13:05
apwthough, if you are root in our chroot, what stops you probing the chroot modules into the kernel13:05
rtgapw, nothing stops you, but it is not currently automatic. the ubuntu chroot is not started by default.13:22
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:34
ogra_and its still not clear that we can actually flip the container models13:35
rtgogra_, ack13: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:35
ogra_(on the rootfs)13:36
ogra_i dont think android even uses modprobe ... they usually insmod the modules from init.rc13:37
rtgogra_, 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:37
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
apwogra_, it is not clear why it would not be possible, we have pure ubuntu on the N7 desktop images13:39
ogra_apw, the question is if androids HW layer is still functional if you put it into a container13:39
rtgapw, 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
apwrtg, hmmm dunno maybe, but we are signing whatever crap we put on there now don't we ?13:40
apwit is good to see this is all resolved well before freeze13:41
rtgapw, not as far as I knwo, but I guess we _are_ booting our kernel so maybe signing isn't an issue.13:41
ogra_haha13:41
apwrtg, yeah thats my assumption13:41
ogra_on nexus signing sholdnt be an issue ... 13:41
ogra_on all other platforms it might become one13:42
ogra_even on one we will be preinstalled on13:42
ogra_but thats 13.10 material i guess13:42
apwogra_, well we do at least have precident with the win8 poop13:42
ogra_:)13:42
apwso we know how to do it 'safely'13:42
ogra_yeah, but yu might have to rely on hackish solutions the vendor picked13:43
ogra_there isnt a standard like UEFI on android 13:43
ogra_its usually some fastboot based loader ... 13:43
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:44
ogra_the fastboot based loaders can even contain a hardcoded and signed GPT so you cant ever resize the boot partition for example 13:45
apwquality and no mistake13:46
ogra_:)13:46
ogra_well, if you measure quality by "lock out the users effectively" they surely did a good job here 13:47
apwalmost as good as raring daily qualit13:47
ogra_(and i think thats what carriers are usually after)13:47
sforsheeppisati, have you been looking into the nexus 4 ftrace problems?13:54
ppisatisforshee: nope, i'm stuck with calxeda :(13:54
ppisatisforshee: i wish i can give it a look13:54
sforsheeppisati, ack. I just wanted to be sure we weren't duplicating effort13:55
sforsheedid you have any ideas about the email I sent?13:55
ppisatisforshee: nope, really13:56
ppisatisforshee: i din't look at the code closely13:56
ckingsforshee, I've not had a chance to look at this yet today either13:56
sforsheeppisati, 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 fails13:57
sforsheewhen so many before it succeed13:57
sforsheeppisati, do you know if there's some way to dump the arm page table attributes?13:58
ppisatisforshee: not really13:59
=== kentb-afk is now known as kentb
ppisatisforshee: btw, when i turned on ftrace, my kernel refused to boot14:00
sforsheeppisati, my kernel boots, however the screen stays blank14:01
ppisatisforshee: do you have a cgf diff?14:01
ppisati*cfg14:02
sforsheeppisati, I can generate one, just a sec14:02
sforsheeppisati, http://pastebin.ubuntu.com/5713232/14:04
ppisatisforshee: i'll give it a try later, thanks14:04
sforsheeppisati, the test options are completely unnecessary, the failure happens during ftrace initialization when DYNAMIC_FTRACE=y14:05
jussismb: I thought there was some preinstall script that cleaned up old kernels so this didnt happen ?14:08
=== cmagina_away is now known as cmagina
rtgjjohansen, need to reboot tangerine for the openssl update14:09
smbjussi, 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 housekeeping14:10
jussismb: 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 though14:11
jussi(and yes, I should have read the error message properly... :P )14:11
smbIt sometimes helps. ;)14:12
rtgcking, henrix: need to reboot gomeisa for SSL update14:41
rtgogasawara, we definitely need to upload 3.8.7 before final. it fixes a Thinkpad suspend regression.14:46
rtgI suspect its 'Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"' 'cause I saw a bunch of ACPI noise in my log14:47
ogasawarartg: ack, lets try to get it in today since final freeze is Thurs.14:50
ogasawarartg: well, I guess we could give it another day too in case something else lands14:50
rtgogasawara, 3.8.8 is gonna release by tomorrow14:50
ogasawarartg: so lets wait14:50
rtgack14:50
rtgjsalisbury, 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
jsalisburyrtg, ok, thanks14:54
jsalisburyrtg, I'll ask for testing of some of the existing reports as well14:54
rsalvetirtg: 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 package15:07
rsalvetiregarding modules, as long we have the core part as built-in, we're good15:08
ogra_will you autosync into phablet.u.c ?15:08
rtgrsalveti, sort of, until someone wants to plug in a USB gizmo, or mount a stange file system.15:08
rsalvetirtg: ogra_: sure, but the problem is that we don't have different raring images per device15:09
rsalvetiso we can't yet install the kernel package at the image by default15:09
ogra_yeah15:10
rsalvetiin case the user wants to use a module, he would need to install the package by hand15:10
rsalvetiand then it should work, as the kernel is the same, so binary compatible15:10
rsalvetiogra_: my idea is to disable the kernel build part of the android image15:10
rsalvetiand just use a pre-built image, and try to keep that in sync15:10
rsalvetiat jenkins we have a script that will download the latest every time15:11
ogra_well, as long as youo dont add more sources for me to pull from while building the android layer :P15:11
rsalvetino, it's easier actually15:11
rsalvetiand will reduce the build time as well15:11
ogra_i'm just concerned about more holes in the firewall to the livefs builder 15:11
rsalvetirtg: ogasawara: there's only one extra requirement now from the app dev team, which is to support lttng15:11
rsalvetiand 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 IS15:12
rsalvetiogra_: right, they will be available via phablet.u.c15:12
ogra_great15:12
rsalvetirtg: ogasawara: and also a backport of the latest apparmor patch set used 15:12
rsalvetias they will still be used as dev target 15:13
jsalisbury**15:15
jsalisbury** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting15:15
jsalisbury**15:15
rtgrsalveti, ogasawara: prolly ought to get those listed as work items so we don't forget.15:15
rsalvetirtg: yup, indeed15:15
rtgrsalveti, doesn't lttng use ftrace ?15:15
rsalvetirtg: I think it lttng is trying to reuse some pieces from ftrace15:17
rsalvetibut they still need external modules15:17
rsalvetiwhich is provided via dkms at ubuntu15:17
rtgrsalveti, seems like sforshee and cking were having problems with ftrace on the Nexus kernels15:17
rsalvetirtg: hm, interesting15:18
rsalvetiwell, lttng provides both user and kernel tracing, so at least some part should work15:18
sforsheersalveti, yeah there's a problem with dynamic ftrace atm on the nexus 415:18
rsalvetisforshee: is that specific to this kernel or for the upstream 3.4 one as well?15:19
sforsheersalveti, I was told that it worked in generic 3.4, but I'd have to refer you to cking and ppisati for confirmation of that15:19
rsalvetisforshee: right, but good to know15:20
ckingi believe that's what ppisati concluded15:20
rsalvetiwill give that a test later today to see if it works at least enough for lttng15:20
sforsheersalveti, 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 noops15:21
sforsheeat some point writing the noop fails, and ftrace disables itself as a result15:21
rsalvetirtg: should I put the WIs for you there?15:22
rtgrsasure15:22
rtgrsalveti, sure15:22
jdstrandrsalveti, rtg: hey, where is that apparmor work item being tracked?15:22
rtgjdstrand, Blueprint foundations-1303-phablet-kernel-maintenance] I think15:23
rtghttps://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance15:23
rsalvetijdstrand: we can probably track it at https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance15:23
jdstrandok, thanks. /me subscribes15:24
jdstrandoh, I already am :)15:24
* henrix -> back in 1515:25
jdstrandjjohansen: fyi, I also subscribed you to ^15:25
jsalisbury##16:55
jsalisbury## Kernel team meeting in 5 minutes16:55
jsalisbury##16:55
=== kamal1 is now known as kamal
=== kamal is now known as Guest20579
=== Guest20579 is now known as kamal1
=== kamal1 is now known as kamal
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 23th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* ppisati -> EOD17:18
* rtg -> lunch17:28
* cking EOD too17:46
* rtg -> EOD21:59
=== kentb is now known as kentb-out
=== ayan_ is now known as ayan

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!