=== mamarley is now known as Guest427
=== mamarley_ is now known as mamarley
=== mamarley is now known as Guest91007
=== mamarley_ is now known as mamarley
[07:50] <xnox> i wonder if i can run LTS kernel on yakkety, such that i get CLS for my laptop
[08:02] <smb> xnox, you surely can run then 18.04 kernel ... at some point
[08:03] <xnox> hm. i'm wondering why we don't keep lts ga kernel in yakkety. Or like forward copy it.
[08:03] <xnox> i should be able to pin to xenial kernel package i think. things should generally work.
[08:06] <smb> xnox, its just that I wonder why you want that
[08:08] <smb> (and don't assume I have any idea at this time of day about what this CLS ramblings are)
[08:08] <xnox> live patchign
[08:09] <xnox> because it is stated that live patches are not currently built/released for yakkety kernel
[08:11] <smb> xnox, so what? its not like you could not reboot your laptop :-P
[09:10] <caribou> guys, I must be missing something obvious with my kernel rebuilds:
[09:11] <caribou> even when building the generic package with skipabi=true skipmodule=true, I'm not able to reboot with a rebuilt bzImage 
[09:12] <caribou> it just doesn't find the root device upon reboot
[09:12] <caribou> FYI I'm working on a bisect & don't want to have to rebuild all modules each & everytime
[09:15] <caribou> apw: smb: any thought ? ^^^
[09:15] <caribou> if you're not too busy of course :)
[09:16] <smb> caribou, hm... frankly for bisecting I usually (most of the time its on mainline trees anyhow) copy a /boot/config-... into .config and run "make -j32 deb-pkg INSTALL_MOD_STRIP=1"
[09:16] <smb> There is some auto incrementing version of the packages that way, too
[09:17] <caribou> smb: which Mainline tree did you use ? kernel.org one ? last time I tried, it complained that it could no find debian/control
[09:17] <smb> Just one needs to be careful what number is used with the latest build (they might jump back and forth)
[09:18] <caribou> smb: I would prefer to use the mainline as I can't use non-linear tags for the bisect
[09:18] <caribou> smb: let me try your command again
[09:18] <smb> caribou, yes the kernel.org one
[09:18] <smb> caribou, note its is just plain make and not dpkg-buildpackage or so
[09:47] <boulabiar> Hi, how to bug report the new kernel livepatch ?
[09:47] <boulabiar> after installing, my laptop can't sleep anymore
[09:48] <boulabiar> ubuntu-bug canonical-livepatch don't work, because the package is installed via snap
[09:50] <henrix> boulabiar: i guess you'll need to use https://bugs.launchpad.net/ubuntu/+source/canonical-livepatch/+filebug
[09:56] <boulabiar> henrix: something went wrong with the page you asked my to use
[09:57] <boulabiar> I've written a full paragraph, then when i clicked send, an error appeared, I repeated this 2 times...
[10:01] <henrix> boulabiar: ah, so launchpad is probably in one of those days
[10:01] <ogra_> apw, did you forget to binary-new the linux-raspi2 package in xenoal-security/-updates ?
[10:03] <ogra_> (seems the images that QA tries to test here at the sprint all ended up with 4.4.0.1029.29)
[10:05] <smb> ogra_, the version number sounds like the one I would expect
[10:06] <ogra_> smb, 
[10:06] <ogra_>  linux-raspi2 | 4.4.0-1029.36 | xenial-security/universe  | source
[10:06] <ogra_> vs
[10:06] <ogra_>  linux-raspi2 | 4.4.0.1029.29 | xenial-security/universe  | armhf
[10:07] <ogra_> brad is on it though, i pinged him in person
[10:19] <apw> ogra_, what is wrong with those versions ?
[10:19] <apw> remember one is source and the other is a binary from a _different_ source
[10:19] <ogra_> apw, we need 4.4.0-1029.36 in the archive as binaries
[10:20] <ogra_> ogra@anubis:~/datengrab/images/snappy$ rmadison -s xenial-updates,xenial-security linux-raspi2
[10:20] <ogra_>  linux-raspi2 | 4.4.0-1029.36 | xenial-updates/universe  | source
[10:20] <ogra_>  linux-raspi2 | 4.4.0-1029.36 | xenial-security/universe | source
[10:20] <ogra_>  linux-raspi2 | 4.4.0.1029.29 | xenial-updates/universe  | armhf
[10:20] <ogra_>  linux-raspi2 | 4.4.0.1029.29 | xenial-security/universe | armhf
[10:20] <ogra_> there is no armhf binary for 4.4.0-1029.36 anywhere 
[10:22] <apw> ogra_, the binary is _not_ called linux-raspi2 ?
[10:22] <apw> you are asking rmadison for binaries only called linux-raspi2
[10:22] <ogra_> oh man 
[10:23] <apw> try -S
[10:23] <ogra_> indeed you are right, thoughh why do we only get .29 in the snaps then
[10:24] <ogra_> https://launchpadlibrarian.net/290161189/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
[10:24] <ogra_> thats a build log from 2h ago 
[10:24] <apw> ogra_, the linux-raspi2 package is from linux-meta-raspi2 and that is the ight number for that
[10:24] <ogra_> Get:5 http://ftpmaster.internal/ubuntu xenial-security/universe armhf linux-image-raspi2 armhf 4.4.0.1029.29 [2324 B]
[10:24] <apw> you should have linux-raspi2 at 4.4.0.1029.29 (note no - in the version)
[10:25] <apw> and linux-image-4.4.0-1029 at 4.4.0-1029.36 which is from linux-raspi2
[10:25] <ogra_> hmm
[10:25] <ogra_> Get:2 http://ftpmaster.internal/ubuntu xenial-security/universe armhf linux-image-4.4.0-1029-raspi2 armhf 4.4.0-1029.36 [35.3 MB]
[10:25] <ogra_> there is actually is
[10:25] <apw> right, so that is exactly as expected
[10:26] <ogra_> then i dont get whyy all the bugs are still there :(((
[10:26] <apw> ogra_, which bugs, ones which are fixed in the -proposed kernel ?
[10:26] <smb> ogra_, because it only fixes security
[10:26] <smb> ?
[10:26] <ogra_> (teh kernel i tested from proposed yesterday was not oopsing on boot ... the QA team now tests it and has unbootable imges again)
[10:26] <apw> ogra_, they are not in that kernel it was an embargoed security fix
[10:27] <ogra_> err
[10:27] <apw> ogra_, that is exactly expected
[10:27] <ogra_> so you didnt base on that one ? 
[10:27] <apw> that is _how_ embargoed cves work
[10:27] <ogra_> damn 
[10:27] <ogra_> well, we need the one from proposed today 
[10:27] <apw> no we would never do that, it was an untested CVE CRD release
[10:27] <apw> ogra_, that is gone
[10:28] <ogra_> so is there any way to get the fixes in today (we tested the hell out of the proposed kernel yesterday to make sure it can land asap)
[10:29] <apw> ogra_, that doesn't have the aa fix bear in mind
[10:29] <ogra_> it is essential for the snappy RC image that we need to release this week
[10:29] <ogra_> (and what you have in the archive is unbootable anyway on pi3 currently)
[10:30] <apw> ogra_, i might be able to resurect the previous version but that won't have the aa fix which we respan for
[10:30] <sbeattie> ogra_: jjohansen may have a kernel you can use which was based on the -proposed kernel with the raspi2 fixes + the needed apparmor fix.
[10:30] <ogra_> sbeattie, for the archive ? 
[10:30] <sbeattie> in a ppa
[10:30] <apw> oh yeah thats right, we could do that because there was jj's kernel in a ppa
[10:30] <jjohansen> ogra_: so based on kernel that was in updates yesterday + the apparmor fix
[10:30] <jjohansen> https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-devel
[10:30] <apw> ogra_, anyhow, i'll see where we are with the respins
[10:30] <sbeattie> s/updates/proposed/
[10:31] <ogra_> can we somehow fast-path that in ? (i have the QA team here and i can spin snaps for them from the PPA to get everything tested)
[10:31] <jjohansen> sbeattie, orgra: so again this is not based on -proposed but on -updates from yesterday
[10:32] <jjohansen> the xenial -proposed kernel has the apparmor backport from yakkety on it
[10:32] <sbeattie> jjohansen: oh, updates?
[10:33] <jjohansen> yeah -updates from yesterday
[10:33] <ogra_> jjohansen, well, we have a kernel that oopses on boot, that was the released kernel and the one formerly in updates ... 
[10:34] <ogra_> the only kernel that boots is the one that was in -proposed yesterday 
[10:34] <apw> ogra_, cna you remember the version number ?
[10:35] <ogra_> i can dig it up, i have a test image but that needs some time since i need to set up gear to boot it to run uname 
[10:35] <apw> ogra_, can you build images/snaps whatever against a PPA
[10:36] <apw> if not then it is no point in me trying to find it
[10:36] <ogra_> apw, ppisati said it should just be  >= 4.4.0-1028.34  but thats obviously not true when the former proposed kernel wasnt even used
[10:36] <apw> what should be ?
[10:36] <jjohansen> ogra_: so xenial -proposed should not be vulnerable to the aa bug, the yakkety version of apparmor had refactored that code and due to that had the fix in it already
[10:36] <ogra_> apw, the one with all the fixes :)
[10:37] <apw> i need a specific exact version as i have to reach blind into the archive
[10:37] <ogra_> yes, i know 
[10:37] <jjohansen> the ppa has the -updates kernel with the apparmor fix based on the assumption you would a released kernel
[10:37] <ogra_> as i said, that requires some work
[10:38] <ogra_> jjohansen, right, but -updates is a step back and wont boot without some bootloader hackery first 
[10:38] <ogra_> apw, i'll ping you as soon as i can give you the version
[10:39] <jjohansen> ogra_: got it, so I just want to confirm for you from an apparmor pov the ppa kernel based on yesterdays -updates and the xenial -proposed kernel should be functionally equiv. ie not have the bug
[11:25] <apw> ogra_, oh, a thought, isn't the download of the package from -proposed in the logs of the image build which was good; rather than booting it
[12:16] <ogra_> apw, \o/ ... sorry it took so long, found the package version in a build log 
[12:16] <ogra_> Get:5 http://ftpmaster.internal/ubuntu xenial-proposed/universe armhf linux-image-raspi2 armhf 4.4.0.1028.28 [2324 B]
[12:17] <ogra_> and
[12:17] <ogra_> Get:1 http://ftpmaster.internal/ubuntu xenial-proposed/universe armhf linux-image-4.4.0-1028-raspi2 armhf 4.4.0-1028.34 [35.4 MB]
[12:18] <ogra_> does that help ?
[12:21] <apw> ogra_, yes that helps, thanks.
[16:16] <yoasif> hi, is there any documentation or way of getting the "extras" package for mainline kernel builds?
[18:44] <tjaalton> i'm hit by https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1635115
[18:44] <ubot5`> Ubuntu bug 1635115 in grub2 (Ubuntu) "grub fails zfs root filesystem detection due to failed checksum" [Undecided,Confirmed]
[18:44] <tjaalton> my home server fails to boot after latest updates to xenial
[18:47] <tjaalton> oh well, no time to fix it now..
[18:55] <mamarley> Ooh, that should be probably be marked Critical.
[18:55] <apw> i am not sure zfs is support as root/boot is it?
[19:16] <tjaalton> not in the installer, but i see no reason to make it harder