=== JanC is now known as Guest36120
=== JanC_ is now known as JanC
=== hyperair is now known as Guest74530
=== sakrecoer_ is now known as sakrecoer
[14:09] <manjo> apw, hello.. did you get a chance to see my email ? regarding "module disagrees about version of symbol module_layout" ? 
[14:11] <apw> manjo, i see it, what compiler did it use to build this version?
[14:11] <manjo> apw, xenial what ever is default .. 
[14:12] <manjo> apw, in the PPA buildes 
[14:12] <manjo> apw, also arm64
[14:13] <apw> well they that would likley be gcc5 so that ought to be ok.  the message seems to imply that the kernel and modules come from different builds with different configs most likely
[14:13] <manjo> apw, right that is why I am stumped .. coz it is a full kernel build in the PPA 
[14:14] <manjo> apw, something is not right 
[14:14] <apw> manjo, well how is the kernel getting to the CPU could that be out of sync with the initramfs
[14:15] <manjo> apw, I am seeing this with DI install .. di I built using this kernel 
[14:15] <apw> right but how are you making sure that the module and vmlinux are from the same build
[14:17] <manjo> apw, not sure what you are asking .. the kernel built in a ppa, the DI built in that same PPA so DI would be picking up kernel and modules from that PPA ..
[14:17] <apw> manjo, which of d-i's outputs are you booting, a netboot ?
[14:18] <manjo> ah! sorry .. yes netboot 
[14:18] <apw> and how are those bits getting to the board
[14:18] <manjo> apw, pxe tftp usual di 
[14:19] <apw> and can you tell from the logs it got a consistant set in this boot
[14:19] <manjo> apw, oh do you suspect that the server might be corrupted ? 
[14:19] <manjo> apw I did not even think of that case .. 
[14:19] <apw> well i'd want to confirm these were a matched pair, that it wasn't using the wrong vmlinxu or something
[14:20] <manjo> right let me check to make sure 
[14:20] <apw> you know how fickle all this tftp bullshit is
[14:21] <mamarley> I noticed you mentioned GCC5 earlier, and also that the kernel in Yakkety is currently built with GCC5.  Is there an issue building kernels with GCC6?
[14:22] <apw> mamarley, i believe there is currently yes, at least for 4.4, not sure which upstream kernels have support for it
[14:22] <mamarley> Ah, OK.  I was curious because I had been using the 4.7 mainline kernel, and that works fine with GCC6.
[14:23] <apw> yeah i only was peripherally involved, i know we had to do special things for 4.4 in yakkety, when it stops being an issue is not something i have asked
[14:30] <manjo> apw, so I verified that the bits are coming from the right place 
[14:30] <manjo> apw, nothing funny there 
[14:31] <manjo> apw, https://pastebin.canonical.com/163979/
[14:32] <manjo> apw, https://pastebin.canonical.com/163980/
[14:32] <manjo> oops I left out the imp cut paste in the prev pastbin 
[14:34] <rtg> dannf, how is 4.6 arm64 looking ? ogasawara mumbled something about ROCKCHIP needing to be enabled ?
[14:36] <apw> manjo, and you have downloaded those and confirmed they are a consistant set content wise
[14:37] <manjo> apw, yes built yesterday .. ubuntu-installer dir looks kosher
[14:39] <manjo> apw, with CONFIG_MODVERSION it should re-generate Module.symvars .. and the modules should link with that correct? .. unless there is some code missing which I doubt is the case 
[14:44] <apw> manjo, looking at the kernel code emitting that, it really thinks the symbol table for that thing is different for the vmlinux and the module pair
[14:45] <apw> manjo, which either implies they are from differnt builds, or the modules and kernel are built differently in the same build
[14:45] <apw> manjo, quite how that could occur if you are sure they are form the same build, i guess it depends how different the build is from our standard ?
[14:46] <dannf> rtg, ogasawara : yep: LP: #1616672
[14:46] <ubot5> Launchpad bug 1616672 in linux (Ubuntu) "4.6.0-11.13 from ckt PPA fails to boot on X-Gene" [High,Confirmed] https://launchpad.net/bugs/1616672
[14:47] <ogasawara> dannf: thanks
[14:47] <rtg> dannf, is that sufficient for now ? infinity would like to get a 4.6 kernel promoted soon, and this appears to be the only blocker.
[14:48] <manjo> apw, the process is simple, take unstable, add patches, adj configs, fix changelog and build in ppa ... I have done this a number of times in the past with 4.3, 4.4, 4.5 etc and did not see this issue 
[14:48] <dannf> rtg: i'm fine w/ it - i'm moving on to 3.8-rc to see if there was a fix since, but that is having its own problems, so i can't promise any "real" fix anytime soon
[14:48] <manjo> apw, Y kernel skipped 4.7 so I can only use unstable which has a 4.7 tag 
[14:49] <rtg> dannf, ok, I'll add this patch and upload soon
[14:50] <apw> manjo, other than looking at the build log for oddness, i have nothing.  there is more info at debug level you might want to up loglevel to debug on boot
[14:50] <manjo> apw, ok crazy question .. can I disable CONFIG_MODVERSION ?
[14:51] <apw> you could, but what it is telling you is wrong implies that the values in that structure are not going to be read right, whcih is likely going to explode in your face next
[14:51] <apw> as the structure layout the kernel is going to drop onto that data in the file isn't the same shape
[14:52] <manjo> lol right ok .. 
[14:52]  * manjo tries to find a vein .. 
[15:56] <dannf> infinity: just a heads up that a 4.8-rc3 w/ ubuntu config is blowing past the size limit for xgene/uboot. might make that compressed image support work for d-i more critical
[15:57] <infinity> dannf: Joy.
[15:57] <infinity> dannf: I have no issues with compressed images, as long as you make sure every platform supports it. :P
[15:58] <infinity> dannf: (Been down this road with PPC, where we switched from coff to zImage and had to switch back because some firmware/bootloaders didn't like it)
[15:58] <infinity> dannf: Unless you mean just compressing the uImage for xgene, not the vmlinux.  Then that's trivial.
[15:59] <dannf> infinity: i mean for both. we *could* just do x-gene, but the only other bootloader i think we care about is UEFI, which deals with it
[16:00] <dannf> s/do x-gene/do just x-gene/
[16:00] <infinity> dannf: So, wait.  Is the current zImage uncompressed on arm64?
[16:00] <dannf> infinity: actually - i guess qemu might be another example - i'll test that as well
[16:00] <dannf> infinity: yes
[16:00] <dannf> infinity: that's what i'd like to change - but need to get d-i/f-k in place before i send that patch
[16:00] <infinity> dannf: qemu can take raw zImages fine, and in the non-raw case, it's using firmware (uboot or ovmf), so should be fine.
[16:01] <infinity> dannf: It doesn't look uncompressed to me...
[16:02] <dannf> infinity: does it say COFF?
[16:02] <infinity> dannf: My uncompressed PPC kernels are huge in comparison.
[16:02] <leitao> rtg, I sent an email to the kernel mailing list regarding kernel issue on ppc64el.
[16:02] <leitao> I am not seeing it at https://lists.ubuntu.com/archives/kernel-team/2016-August/thread.html. Maybe it was not received because I am not part of the mailing list.
[16:03] <infinity> dannf: Although, file(1) thinks it's a DOS executable, not a bzImage, so... Maybe it is uncompressed. :P
[16:03] <infinity> (Also, wat)
[16:03] <dannf> infinity: it is - EFI stub
[16:04] <infinity> dannf: Anyhow, any modern u-boot can boot zImage/bzImage, as can EFI, and if that's all we care about, you should be good to go.
[16:04] <apw> that could be compressed still
[16:04] <infinity> dannf: And raw qemu.
[16:04] <infinity> But, yeah.  My PPC kernels are, like, 30MB.  How big is your arm64 kernel?
[16:04] <dannf> infinity: right - but the uImage needs to have the right compress field, which brings me back to https://code.launchpad.net/~dannf/debian-installer/xgene-uboot-gzip-support/+merge/300645
[16:05] <apw> an x86 kernel is a binary, just a small one which uncompresses itself, so it isn't a gzip
[16:05] <infinity> dannf: Why are we using uImage/uInitrd at all?
[16:05] <infinity> dannf: Surely the u-boot on any arm64 system is new enough to load raw kernels.
[16:05] <dannf> infinity: xgene only supports uImage - at the time only armhf supported raw zImage
[16:05] <infinity> dannf: Wow.  That's.  Derp.
[16:06] <infinity> Well done, arm64 folks.
[16:06] <apw> they have to be backwards somewhere
[16:07] <ogra_> just flash a new u-boot during install :P
[16:07] <infinity> ogra_: Chicken, meet egg.  How do you boot the installer?
[16:07] <ogra_> details 
[16:07] <infinity> :)
[16:07] <ogra_> :)
[16:07] <dannf> can't flash u-boot on mcdivitt
[16:08] <infinity> dannf: If that's tested and you're pretty sure it doesn't suck, just go ahead and commit, it doesn't need review, IMO.
[16:08] <dannf> infinity: ack
[16:08] <infinity> dannf: I have to upload a fresh d-i in about half an hour to pick up netcfg, so this'll get in there if you commit now. :P
[16:10] <infinity> dannf: For future reference, don't let me block you on d-i stuff unless it's a large enough change that you're pretty sure I'll revert and/or yell at you for not asking for a review.
[16:10] <dannf> infinity: in 1:1 w/ bossman, so will be at least 20 minutes
[16:10] <dannf> infinity: understood :)
[16:12] <infinity> dannf: And those goes double if you're committing without uploading, cause I review the full delta before upload anyway.
[16:23] <infinity> dannf: On second thought, I'll just merge it, I'm operating on a clock. :)
[16:24] <dannf> infinity: ack
[16:28] <infinity> dannf: Merged and uploaded.
[16:28] <dannf> infinity: thx!
[16:37] <rtg> leitao, unmoderated
[16:37] <leitao> rtg, weird. Anyway, sent you a private email
[16:38] <rtg> leitao, no, I mean I released it from the moderation queue
[16:38] <rtg> anyways...
[16:39] <leitao> rtg, got it. So it is moderated. Thanks
[16:42] <rtg> apw, that looks like a mainline cross compile problem, though it likely also exists in our Ubuntu cross builds
[16:43] <apw> rtg "that" ?
[16:44] <rtg> apw, https://lists.ubuntu.com/archives/kernel-team/2016-August/079743.html
[16:45] <apw> hrm
[16:45] <rtg> apw, I doubt if I've ever run the cross compiled ppc64el kernel
[16:47] <apw> rtg, ok that is using your 4.7.0-0.4 debian tooling etc, and is supplying CROSS_COMPILE=powerpc64le-linux-gnu-
[16:48] <apw> rtg, so i would expect that to do something sane
[16:48] <rtg> apw, upstream makefile bug ?
[16:49] <apw> or we lost our own fixes
[16:50] <rtg> apw, shouldn't have. I don't remember any conflicts in the debian directory
[16:50] <apw> both the primary makefile and our rules look to pass it as normal
[16:50] <apw> hrm
[16:58] <rtg> this sounds vaguely familiar
[17:04] <apw> rtg, ok yes, this is actually only the host tooling which is coming out as x86, and as these are cross compiles that is entirely expected
[17:05] <rtg> apw, host side device tree compiler ? so its not really a problem.
[17:05] <apw> rtg, right it does mean you cannot build out of tree modules against these test builds
[17:06]  * apw replies on the mailing list as well
[19:38] <jhg_> greetings!
[19:39] <jhg_> are there any nightlies that track linux-next or netdev with binary kernel packages?
[21:29] <apb1963_> help attempted in #ubuntu but no resolution.  No response in #ubuntu-server yet... and so now I'm asking here.  Aptitude is giving me an abortion when trying to install libsnmp-dev.  Details here: http://pastebin.com/AAaZgFid