[00:47] <keithzg> Uhhhh well that's not good, on the first 16.04 system I've tried rebooting after applying the kernel update, it doesn't actually boot anymore . . .
[00:47] <nacc> keithzg: yikes
[00:47] <nacc> keithzg: as in, no boot, or doesn't boot that kernel?
[00:48] <keithzg> nacc: System certainly powers on and gets me to Grub. Choosing cecovery boot just hangs at saying it's loading the initial RAM disk. Choosing the previous kernel instead everything boots fine.
[00:49] <sarnold> keithzg: last time I had a non-booting kernel after update was due to forgetting the linux*extra* package
[00:50] <TJ-> keithzg: what make/model of system? We know of RHEL/CentOS systems also suffering that but no details as yet
[00:51] <TJ-> keithzg: would be good to report this in #ubuntu-kernel so the kernel devs see the info as well as a bug report
[00:52] <keithzg> sarnold: Yeah I don't appear to have linux-image-extra-4.4.0-108-generic installed, but then again I also don't have linux-image-extra-4.4.0-104-generic installed either and that booted fine
[00:53] <keithzg> TJ-: CPU is an Intel i5-4670K, motherboard is an ASUS Z87-A.
[00:53] <TJ-> keithzg: does the size of the /boot/initrd.img for the PTI kernel look sane? as in not truncated
[00:54] <keithzg> TJ-: Yeah, 34969733 which seems about in line with the others sitting there
[00:55] <TJ-> keithzg: is it booting using UEFI or BIOS? and if UEFI, is it using Secure Boot with -signed images?
[00:57] <keithzg> TJ-: Definitely booting via UEFI, admittedly unsure if it's *actually* booting via the -signed image
[01:05] <keithzg> sarnold: Wait, I was just foolishly misreading the dpkg output, I do definitely have the correct linux-image-extra-*-generic packages installed for both this and the previous kernels.
[01:05] <sarnold> keithzg: alright .. I was hoping for an easy "oh yeah" solution :)
[01:06] <keithzg> sarnold: Yeah, me too---and I definitely wouldn't have put it past me to have just human error'd it somehow, still seems like a distinct possibility in fact :D
[01:08] <TJ-> could be related to this, there's a helpful screenshot too https://askubuntu.com/questions/994067/kernel-panic-after-spectre-meltdown-update-16-04
[01:09] <keithzg> I'm not even getting to a kernel panic though :/
[01:10] <TJ-> keithzg: do you seen any messages? it may be the console isn't being drawn at the point it occurs, especially if GRUB is in gfxmode
[01:11] <TJ-> keithzg: I generally switch GRUB to text mode to ensure the display doesn't get blanked, with GRUB_TERMINAL=console
[01:12] <keithzg> TJ-: Hmm do I have to do that even in a recovery boot? I figured that was one of the differences, since in the non-recovery boot the screen was just blank.
[01:13] <TJ-> keithzg: does the system use ZFS ?
[01:13] <keithzg> TJ-: Nope, I'm a btrfs partisan ;)
[01:13] <keithzg> (although that's only for the storage pool, everything's installed to ext4)
[01:14] <keithzg> (well, I mean, /boot is vfat 'cause UEFI but you know)
[01:14] <TJ-> you have /boot/ in the EFI SP ?
[01:15] <keithzg> Ah right sorry it's just /boot/efi that's vfat
[01:19] <keithzg> I'll go off and reboot this again, temporarily editing the recovery session to have GRUB_TERMINAL=console and see if that shows anything more, then (and actually record what it *does* show this time rather than relying on my fallable memory)
[01:27] <keithzg> Ah, right it's just an option in /etc/default/grub, I guess I'll just set that generally and see how it goes in a non-recovery session first.
[01:32] <keithzg> TJ-: Booting with GRUB_TERMINAL=console just ends up making a normal boot show the same thing as a recovery boot, namely "Loading Linux 4.4.0-generic ..." then on the next line "Loading initial ramdisk ..." then on the next line "_" and it just sits there forever.
[01:33] <TJ-> keithzg: OK, one last thing to try, add "debug" to the kernel command line in case we can get *something*
[01:34] <keithzg> Wait sorry I mixed that up, non-recovery just talks about invalid video mode and then says it's booting in blind mode.
[01:34] <TJ-> keithzg: I'll stick to #ubuntu-kernel now so everything is captured in the logs in that channel
[01:34] <keithzg> TJ-: Fair enough
[02:13] <Epx998> Is there any documentation on network installing ubuntu with an uefi filesystem, preseed is tripping me up
[02:16] <strive> Epx998: Maybe this could help? https://help.ubuntu.com/community/UEFI
[02:17] <Epx998> strive: I just need to workout my partman junk for uefi - there isnt a lot on it that goes over recipes
[02:17] <Epx998> for us simple admin folk
[02:18] <strive> Ok.
[02:19] <Epx998> i might have found a workable template to start from
[02:20] <Epx998> hmm there is some doc I can install from a package that has everything in it, dang cant remember the package name
[04:32] <trneal> is there an AWS SNS subscription ARN for ubuntu image updates?
[04:33] <Odd_Bloke> trneal: There isn't yet, but it is something we've discussed.
[05:38] <trneal> ah yea, it’s something my company is requiring of me so i’ve gotta make my own I guess haha
[05:39] <trneal> if it ever does happen, would you guys make a news announcement on the blog?
[05:41] <Odd_Bloke> trneal: I think we would, yes.
[05:42] <trneal> cool  :)
[05:42] <trneal> thanks for your help Odd_Bloke
[05:42] <Odd_Bloke> trneal: If you're happy to do so, would you mind filing a bug at https://bugs.launchpad.net/cloud-images/+filebug describing what you'd want?
[05:42] <trneal> you got it
[05:44] <Odd_Bloke> Thanks!
[06:18] <cpaelzer> good morning
[06:24] <nacc> cpaelzer: morning (for you :)
[06:24] <nacc> powersj: fyi, figured out the issue with jenkins and will land MPs fixing it tomorrow
[06:54] <cpaelzer> nacc: ok
[06:55] <cpaelzer> nacc: I just sorted out all the branches that I want to review, but need a bit time to actually get to them
[06:55] <cpaelzer> I hope that after your night I at least tackled some of them
[07:06] <lordievader> Good morning
[09:21] <johan-hedin> 40Gbps Network In | 1000Mbps Network Out  | 5TB Transfer can take how much trafic ?
[09:21] <johan-hedin> and load ?
[15:06] <trippeh> hum, vfio apparmor-rules are not beeing added to a VMs unique apparmor profile.
[15:07] <trippeh> SRIOV managed hostdev networking
[15:12] <trippeh> libvirt
[15:13] <cpaelzer> trippeh: they are in my tests at least - what release are you on?
[15:14] <cpaelzer> trippeh: and can you share the xml snippet that you use to define the hostdev?
[15:14] <trippeh> cpaelzer: Artful
[15:15] <cpaelzer> ... deploying a system with working SR-IOV on artful ...
[15:15]  * cpaelzer thanks MAAS
[15:16] <trippeh> cpaelzer: https://pastebin.com/raw/Gr55tFMv
[15:17] <cpaelzer> uh I see - it is a hostdev type network and a "normal" interface define
[15:17] <cpaelzer> hrm
[15:17] <cpaelzer> let me take a look, but there is a chance that virt-aa-helper at the time invoked has no context to detect that
[15:17] <cpaelzer> I'll ping you back in a bit ...
[15:17] <trippeh> thanks :)
[15:18] <trippeh> I can always workaround it, but.
[15:19] <cpaelzer> sure you can, but it is either breaking guest isolation slightly or a real bruden to manage it
[15:19] <cpaelzer> if the context doesn't hold the info there is not much I can do, but I want at least to check the details
[15:19] <trippeh> I see another VM has the vfio entries in the profile - but that one is also has other pci devices mapped in.
[15:20] <trippeh> (not network related)
[15:31] <cpaelzer> trippeh: yeah that is what I meant with "normal" hostdev
[15:31] <cpaelzer> that virt-aa-helper can read
[15:31] <cpaelzer> drill down to the actual entries, and add to the profile
[15:32] <trippeh> adding the VF pci devices as normal hostdevs you mean?
[15:33] <cpaelzer> yeah that is what work AFAIK
[15:33] <trippeh> that is a pain to manage, especially with vlans and such
[15:33] <cpaelzer> sure
[15:33] <cpaelzer> it is a balance of effort all the time
[15:34] <cpaelzer> the storage pools have a similar issue in that virt-aa-helper can just not tap "into" them
[15:34] <cpaelzer> I recently extended some code but it doesn't cover all of it yet
[15:34] <cpaelzer> I have a meeting soon with the original author of most of the libvirt apparmor code and hope he might have some good ideas how to better integrate those devices
[15:35] <cpaelzer> and in that regard the extternal hostdev network is very similar to the storage pools
[15:35] <trippeh> yeah
[15:35] <cpaelzer> instead of the guest owning it it just refers to an external entity
[15:35] <cpaelzer> At least after my check I should be able to add to the known bug that these kind of devices are affected as well
[15:36] <trippeh> I think I will apply the workaround in the mean time, that is updating the abstractions/ thing with vfio paths
[15:36] <trippeh> its not a high security environment or anything :)
[15:39] <trippeh> hm I guess local/usr.lib.libvirt.virt-aa-helper
[15:39] <cpaelzer> no that is what virt-aa-helper is allowed to access
[15:40] <cpaelzer> the libvirt-qemu thins
[15:40] <trippeh> right
[15:40] <cpaelzer>  /etc/apparmor.d/abstractions/libvirt-qemu
[15:44] <trippeh> it boots \o/
[15:59] <cpaelzer> trippeh: assumption confirmed - I added your example to 1677398
[16:18] <georgem1> I updated the kernel on Ubuntu 16.04 to 4.4.0-109.132 and now I get: apparmor="DENIED" operation="open" profile="libvirt-fac20622-50e9-4ec5-ada1-fca9568a4386" name="/proc/6038/task/24889/comm" pid=24888 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=114 ouid=114 for every operation inside the kvm guest
[16:19] <georgem1> I also updated libvirt-bin from 1.3.1-1ubuntu10.15 to 2.5.0-3ubuntu5.6~cloud0
[16:25] <cpaelzer> georgem1: that is a non critical deny which is fixes in newer releases
[16:25] <cpaelzer> let me fetch the bug to remember the details
[16:27] <cpaelzer> there are two similar ones - one where qemu wants to write to the log who send it a kill signal
[16:27] <cpaelzer> but that is not yours
[16:27] <cpaelzer> your case georgem1 is the debug-threads features
[16:27] <cpaelzer> or debug name I need to check
[16:27] <cpaelzer> TL;DR - qemu tries to rename it's threads for more readability
[16:27] <cpaelzer> but is denied to do so
[16:28] <cpaelzer> upstream https://bugzilla.redhat.com/show_bug.cgi?id=1369281
[16:28] <ubottu> bugzilla.redhat.com bug 1369281 in libvirt "security: apparmor denies qemu.conf set_process_name" [Unspecified,Closed: upstream]
[16:29] <cpaelzer> -name debug-threads=on is triggering that feature of qemu
[16:29] <cpaelzer> I'd not see how a kernel updated would be related thou
[16:30] <cpaelzer> georgem1: I think the upgrade to the newer libvirt enabled that
[16:30] <cpaelzer> https://www.redhat.com/archives/libvir-list/2016-March/msg00428.html
[16:30] <cpaelzer> but TL;DR not critical
[16:37] <georgem1> ok, thanks
=== JanC is now known as Guest37549
=== JanC_ is now known as JanC
[17:52] <Epx998> Can someone point me to some preseed uefi examples?
[17:56] <ahasenack> nacc: what is the git-ubuntu lint checking with this test:
[17:56] <ahasenack> Verified old/debian is the same commit as old/debian
[17:57] <nacc> ahasenack: i take it you are using a namespace of '' ?
[17:57] <nacc> ahasenack: we should probably shortcircuit those checks inn that case
[17:57] <nacc> normally it's checking that old/debian matches pkg/old/debian
[17:57] <ahasenack> what sets the namespace?
[17:57] <ahasenack> ah, pkg
[17:57] <nacc> or rather ahsenack/old/debian
[17:57] <ahasenack> would that be whatever I gave it in merge start?
[17:57] <ahasenack> "git ubuntu merge start ubuntu/devel" vs "git ubuntu merge start pkg/ubuntu/devel"?
[17:58] <nacc> well, most often nthose are the same commit
[17:58] <nacc> so no
[17:58] <nacc> the goal is to check that your merge is curret
[17:58] <nacc> and is merginng what we expect
[17:58] <nacc> e.g., if you race someonne else doing the merge
[17:58] <nacc> or if there's a new upload to debia
[17:58] <ahasenack> hm
[17:59] <ahasenack> because I'm getting a failure,
[17:59] <ahasenack> Verified old/ubuntu exists
[17:59] <ahasenack> W: Expected old/ubuntu (0ddfe85c73cda4785965a063546d026a753d1d4c) is not the same commit as old/ubuntu (4e4074eadda2c0d637d032a7a4e9dbba0f9b0506)
[17:59] <ahasenack> trying to understand it
[17:59] <ahasenack> that could be that a new ubuntu package was uploaded, for example?
[17:59] <nacc> ahasenack: yes
[17:59] <nacc> ahasenack: what repo?
[17:59] <ahasenack> nacc: net-snmp
[18:00] <nacc> ahasenack: i am i the middle of debugginng/fixinng your binnd9 bug, can you show me the repo, the commits, etc? (pastebin)
[18:04] <ahasenack> nacc: lint: https://pastebin.ubuntu.com/26361488/https://pastebin.ubuntu.com/26361488/
[18:04] <ahasenack> er
[18:04] <ahasenack> nacc: lint: https://pastebin.ubuntu.com/26361488/
[18:04] <ahasenack> nacc: 0ddfe85c73cda4785965a063546d026a753d1d4c: https://pastebin.ubuntu.com/26361506/
[18:04] <ahasenack> nacc: 4e4074eadda2c0d637d032a7a4e9dbba0f9b0506 https://pastebin.ubuntu.com/26361509/
[18:04] <nacc> ahasenack: so line 7 is the bit that is showinng the namespace (sort of)
[18:05] <ahasenack> bionic has 5.7.3+dfsg-1.7ubuntu1
[18:05] <ahasenack> should I pass it pkg?
[18:05] <nacc> let me read
[18:06] <nacc> one sec
[18:06] <ahasenack> --lint-namespace pkg doesn't work, then it doesn't find any of the tags
[18:06] <nacc> ahasenack: right
[18:06] <nacc> ahasenack: you're not llinting pkg/
[18:06] <nacc> so that doesn't make sense
[18:08] <nacc> ahasenack: it's a bit odd that your ubuntu/devel is not tracking pkg/ubuntu/devel
[18:08] <nacc> ahasenack: that's what it is complaining about
[18:08] <nacc> ahasenack: i think this is an older import, right?
[18:08] <ahasenack> how can I set that tracking?
[18:08] <ahasenack> nacc: could be
[18:09] <ahasenack> nacc: from august probably, that's the last time I merged this
[18:09] <nacc> ahasenack: easiest way, probably is `git checkout ubuntu/devel; git reset --hard pkg/ubuntu/devel` and then re-tag old/ubuntu to point there
[18:10] <ahasenack> ok, thanks
[18:10] <nacc> git tag -f old/ubuntu pkg/ubuntu/devel
[18:10] <nacc> or so
[18:10] <nacc> we have a lot of stuff that's a bit broken right now between the two importer algorithms
[18:11] <nacc> ahasenack: technnically the above was aw arninng
[18:11] <nacc> ahasenack: not an error
[18:11] <nacc> the trees matched, which is the technically important bit
[18:11] <nacc> but for parenting, it's good to have the commits match what we think they should too
[18:12] <nacc> that is harder to get wrong with the newer algo
[18:12] <nacc> but also this is why i dont' use local branches for remote-tracking
[18:12] <nacc> e.g., i don't like ubuntu/devel and debian/sid
[18:12] <nacc> just use pkg/ubuntu/devel pkg/debian/sid always
[18:12] <nacc> annd keep pkg uptodate
[18:13] <ahasenack> this merge was so easy I might start from scratch
[18:13] <ahasenack> but let me try the workaround first
[18:13] <nacc> ack
[18:15] <ahasenack> nacc: worked
[18:21] <nacc> ahasenack: cool
[18:31] <nacc> ahasenack: fixed your bind9 issue
[18:31] <ahasenack> \o/
[18:31] <nacc> i need to run an errand, do you want me to throw up an MP so you can do that merge?
[18:32] <nacc> ahasenack: https://paste.ubuntu.com/26361665/
[18:34] <ahasenack> big chunk
[20:47] <nacc> ahasenack: and it's not quite right (although it does fix your bind9 case inadvertently)
[21:26] <nacc> cpaelzer: do you need to pinng LocutusOfBorg on the curl http2 enablemetn?
[22:11] <fullstop> hi all. How do I prevent resolvconf from adding a search entry in /etc/resolv.conf ?
[22:16] <fullstop> oh.  remove the entry from /etc/network/interfaces