=== efm__ is now known as efm === med_ is now known as Guest39045 === diplo_ is now known as diplo === JanC is now known as Guest24635 === JanC_ is now known as JanC [13:24] do you guys know why I'm getting this message? WARNING: Security updates for your current Hardware Enablement Stack [13:24] ended on 2016-08-04 [13:24] but when I run hwe-support-status --verbose [13:25] I get: Your Hardware Enablement Stack (HWE) is supported until April 2019. [13:25] did I do something wrong when I upgraded the hwe? [14:26] DammitJim: you get that on login? [14:26] (in motd) [14:26] yes [14:28] `lsb-release -d` shows? [14:29] ack, I don't have that package installed [14:29] do I really need to install it? [14:29] err [14:29] lsb_release -d [14:30] Description: Ubuntu 14.04.5 LTS [14:31] yikes [14:32] hrm [14:32] hwe-support-status and the motd snippet are not agreeing here. [14:32] DammitJim: did you just recently upgrade to the xenial hwe stack? [14:33] (16.04) [14:36] right! [14:36] yes, I did it this morning [14:36] and I've been updating servers for a month now [14:42] and today is the first time that this happens (I've been using scripts) [15:05] join channel #ubuntu [15:29] DammitJim: good. this feels like a simple bug in the motd update script [15:29] "simple" [15:30] DammitJim: I'm not sure what package installs that, or I would say "file a bug on this package". perhaps someone else knows [15:36] dpb1: install what? [15:37] ok [15:37] the motd.d that is printing WARNING: Security updates for your current Hardware Enablement Stack ended on 2016-08-04 [15:37] nacc: ^ [15:37] (14.04) [15:37] update-notifier-common: /etc/update-motd.d/95-hwe-eol [15:37] is that it? [15:38] from src:update-notifier [15:38] what do I need to run? [15:40] DammitJim: `apport-bug update-notifier-common` i think. Is this desktop or server? [15:41] server [15:44] DammitJim: i'm not sure what the bug reporting tool is on server, tbh, you can just file it on launchpad directly (against update-notifier) [15:45] ok [15:46] DammitJim: the script that is generating the motd message is: /usr/lib/update-notifier/update-motd-hwe-eol [15:46] DammitJim: if you want to debug it a bit [15:58] DammitJim: actually, hrm [15:58] DammitJim: in my 16.04 lxd, i'm not actually seeing a hwe-support-status command (nor one in xenial's archives) [15:58] DammitJim: can you do a `dpkg -S hwe-support-status` ? [16:09] hello everyone [16:10] this might be a bit odd of a question, but is there a way to directly upgrade a server instance from 8.04 to 16.04, that doesn't involve reinstalling? [16:11] lachokds: no, you can't directly do it even when 8.04 was supported [16:11] lachokds: you'd need to do 8.04 -> 10.04 -> 12.04 -> 14.04 -> 16.04 [16:12] !eolupgrade | lachokds [16:12] lachokds: End-Of-Life is the time when security updates and support for an Ubuntu release stop, see https://wiki.ubuntu.com/Releases for more information. Looking to upgrade from an EOL release? See https://help.ubuntu.com/community/EOLUpgrades [16:12] lachokds: but honestly, you're better off reinstalling, I'd say [16:12] lachokds: that's a silly number of EOL upgrades before you even get to the supported state [16:12] thanks [16:13] actually yeah, I was trying to upgrade to 10.04 but then my whole system became unbootable [16:13] after restoring from backups I was wondering what else I could do [16:14] lachokds: how did you upgrade to 10.04? following the above? [16:14] yeah, I changed the sources.list file to point to old-releases.ubuntu.com and went from there [16:15] lachokds: ah ok [16:15] I think it might have been that I chose the package maintainer's version for grub [16:16] do you think I should try once again with the original grub version in the system? [16:16] lachokds: i have no idea. my opinion is you've waiting far too long to do this update. You've been unsupported for years (at least 4 years?), and insecure as well. You might as well reinstall. [16:17] You'd be much better off with a clean install to 16.04 [16:19] nacc: I know, I just got the assignment to work on this server. I guess it's gonna be a very interesting conversation :-P [16:19] lachokds: is this a production environment? [16:19] genii: thanks [16:21] nacc: seems like so, though I don't really know why it wasn't upgraded before. Anyways, thanks! [16:21] lachokds: that seems even worse, then, yeah ... [16:22] nacc: seems like it's just trusty [16:24] dpb1: yeah, so i think that could be the problem [16:24] dpb1: something wasn't removed properly [16:24] dpb1: as it shouldn't exist on xenial? [16:25] nacc: feels very weird to me too [16:25] dpb1: yeah, i'm not sure if that's intentional [16:25] dpb1: and oddly it *does* exist on 17.10 [16:25] wth [16:25] dpb1: what ? [16:25] lachokds: we're talking about DammitJim's issue from earlier [16:27] sorry, I wasn't connected [16:27] my apologies [16:27] lachokds: np [16:28] lachokds: sorry, multiple conversations going at a time. :) [16:28] lachokds: I'm impressed you found an 8.04 server out there. good luck. :) [16:29] s/im/de/ :) [16:29] nacc: lol [16:30] nacc: thanks, I guess (?) hehe :) [16:57] hello [17:00] Hi, my Ubuntu Server is randomly freezing after Grub menu on reboot. Can I find a log somewhere to help me diagnose what happen? Nothing is logged in journalctl [17:07] Does it show anything on the screen? [17:07] Does hittign the Esc key make it show anything? [17:07] Have you tried going down to the Advanced options section ont he menu and booting with an older kernel ? [17:08] Black screen, hitting ESC or shift do nothing. I've tried with ubuntu 16.04.02 LTS (kernel 4.8) - Same issue [17:24] nacc... mine is on 14.04 [17:24] dpkg -S hwe-support-status [17:24] update-manager-core: /usr/bin/hwe-support-status [17:24] DammitJim: oh I'm sorry, I misread dpb1's comment (xenial hwe stack can mean two different things) [17:24] DammitJim: in your case, you are on 14.04.5 now? [17:25] yes [17:26] DammitJim: afaict, on trusty, the MOTD should match what `hwe-support-status` outputs... I suppose there is a window while the file is being updated ont he first boot [17:28] hhmmmm... maybe I should restart again? [17:29] exit [17:30] DammitJim: if it's not too much hassle, that would be good to test, or you can just login again (in theory). I'm not sure when motd gets regenned [17:35] he really restarted [17:35] :) [17:44] nacc: just for kicks, I'm trying another merge: bind9 [17:44] nacc: something new: http://pastebin.ubuntu.com/24974070/ [17:45] nacc: the commented pick lines [17:45] should I leave them like that and only work on the rest? [17:48] they all look like empty commits [17:48] ahasenack: it's referred to in wiki: 2.2.5.4 -- but i forgot to update the later portion at 2.3.2 [17:48] ah, right [17:49] fixing now [17:49] thx [17:50] ahasenack: added 2.3.2.3 [17:50] o/ [18:00] stgraber: just got the update to lxd on artful, now my containers won't start :) [18:01] nacc: what error are you getting? [18:01] stgraber: http://paste.ubuntu.com/24974162/ [18:01] stgraber: it creates it, but it's "STOPPED". Manually starting it works [18:02] stgraber: i don't see a reboot request in /var/run/reboot-required, so I hadn't rebooted yet [18:03] Hey guys, I'm getting this WARNING: The following packages cannot be authenticated! libexpat1 libgraphite2-3 should I proceed with the install? [18:04] Masterphi: can you pastebin `apt-cache policy libexpat1 libgraphite2-3` ? [18:04] yah, right away [18:05] nacc: https://pastebin.com/7i69mf6D [18:05] Masterphi: that's debian not ubuntu [18:05] heh, right. This VM isn't ubuntu [18:05] oops [18:15] debian/patches/series must be the conflict champion [18:17] ahasenack: often, yes [18:17] nacc: do you prefer a certain order when decomposing a big change? debian/changelog order, or debian/patches/series order? [18:18] ahasenack: so it's one logical change that is in a bunch of places? [18:18] one logical change has two debian/patches [18:18] and they are not together in series [18:19] nacc: it's the CVE-2016-8864 fix: http://pastebin.ubuntu.com/24974239/ [18:19] they added a cve patch, and a fix for a regression in that patch as a separate patch [18:19] at the same time [18:20] and that 10.1ubuntu3 package wasn't even published it seems: https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P4-10.1ubuntu3 [18:20] https://launchpad.net/ubuntu/+source/bind9/+publishinghistory [18:20] use that --^ [18:20] superseeded, deleted [18:20] ahasenack: the individual page reflects what is currently in the archive, iirc [18:21] ahasenack: as opposed to if it was ever published (as this one was) [18:21] the dates are odd [18:21] ahasenack: i'm confused, the change that shoulud be in that bit of delta is only in rt43779.patch on my reading [18:22] both patch files are there [18:22] ahasenack: let me look in the repo [18:22] diff from previous, in lp: http://launchpadlibrarian.net/303851673/bind9_1%3A9.10.3.dfsg.P4-10.1ubuntu2_1%3A9.10.3.dfsg.P4-10.1ubuntu3.diff.gz [18:22] CVE-2016-8864.patch is added [18:23] as is rt43779.patch [18:28] mdeslaur: --^ can you clarify? [18:32] ahasenack: it might be that it's really two changes, or since they were fixing CVE-2016-8864, and new this further fix was needed, but they hadn't published the CVE fix yet [18:32] ahasenack: just the changelog doesn't make that clear [18:32] and ubuntu4 has a further fix [18:33] huh? it should be in ubuntu2 [18:33] and the one in ubuntu4 introduces no new patch, according to the changelog [18:33] I think what doesn't have a new cve number is the two regressions [18:35] mdeslaur: actually, according to https://www.ubuntu.com/usn/usn-3119-1/, the fix for CVE-2016-8864 should be in 1:9.10.3.dfsg.P4-10.1ubuntu1.1 (zesty) or 1:9.10.3.dfsg.P4-8ubuntu1.2 (xenial) [18:35] ah [18:35] 1:9.10.3.dfsg.P4-8ubuntu1.2 is what introduces the patch in the case of yakkety, for example [18:35] er [18:35] copy&paste error [18:35] https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P4-10.1ubuntu1.1 [18:36] man, sometimes I wished all packages had the ubuntu release number in them [18:36] wait a sec, I'm confused now [18:36] * mdeslaur looks [18:37] nacc: i don't see any ubuntuN.M in the rebase (http://pastebin.ubuntu.com/24974070/), all are ubuntuN, if that matters [18:39] nacc: let me see [18:39] mdeslaur: we were wondering about the order of events, it looked like the fix for CVE-2016-8864 was added at the same time as one of its regression fixes rt43779.patch [18:39] ahasenack: oh wait, a security update to xenial won't show up in the merge [18:40] nacc: I'm sure it's got something to do with the random name, but we have a test for that and it's passing, so I'm kinda confused as to what's going on here :) [18:40] stgraber: yeah. I can reboot if you think it'd fix it [18:40] nacc: nope, got the same here [18:40] stgraber: oh ok :) [18:40] stgraber: that's reassuring at least :) [18:40] nacc: looking into it now, I have a feeling it's going to be a very stupid issue [18:40] ahasenack, nacc: yes, it looks like zesty was missing CVE-2016-8864, and I added it at the same time as the other stuff, but forgot to add it to the changelog [18:41] http://launchpadlibrarian.net/303851673/bind9_1%3A9.10.3.dfsg.P4-10.1ubuntu2_1%3A9.10.3.dfsg.P4-10.1ubuntu3.diff.gz [18:41] mdeslaur: and when you say "no CVE number", you mean no CVE number for the regression? [18:41] nacc: we effectively rewrote the entire client code between 2.14 and 2.15, so that kind of regressions are unfortunately kinda expected... will update the testsuite [18:41] yes, for the regression fix [18:41] or no new cve patch? Or what? [18:41] mdeslaur: yep, that makese sense [18:41] ok [18:42] ahasenack: sorry, i see it's a fix in zesty (not zesty-security), so it's correct for it to merge [18:42] ahasenack: the N.M uploads won't typically show up in a merge, they aren't in artful's history [18:42] nacc: sure enough, it's a stupid mistake... fixed [18:42] stgraber: yep, i saw that in d/changelog, so figured it was a dogfood situation :) [18:42] stgraber@castiana:~$ lxc launch ubuntu-daily:artful [18:42] Creating the container [18:42] Container name is: rare-gopher [18:42] Starting rare-gopher [18:42] stgraber: i just happened to be heavily using lxd at the time :) [18:43] nacc: if you use fixed names that'll work fine, it's just the logic to fetch the random name back from the daemon that's broken [18:43] stgraber: cool, will adjust my flow for now [18:43] nacc: will send a branch in a few minutes, once merged, I'll cherry-pick the fix in the package, so everything should be back to normal by tomorrow morning (unless adt takes forever) [18:44] stgraber: great, thanks! [18:44] stgraber: while i have you, is there a file limit to how many files can be pushed by `lxc file push` ? [18:45] nacc: I don't think so. We don't have batch sending so we just do a request for each arg. That'd make the limit be the maximum number of args you can have on the cmdline [18:45] stgraber: ok, i hit something funky with `lxc file push -r` as well ... but i'll debug it a bit more locally [18:47] nacc: https://github.com/lxc/lxd/pull/3463 [18:47] stgraber: great, thanks [18:57] man, are these bind9 patches big [18:57] scary stuff, that so much code had to be changed [18:58] in perhaps the most mature product in the world [18:58] -rw-rw-r-- 1 andreas andreas 5,4K Jun 28 15:53 CVE-2017-3135.patch [18:58] and this is a regression patch in a *security* patch: [18:58] -rw-rw-r-- 1 andreas andreas 15K Jun 28 15:53 rt44318.patch [18:59] but, setting the record straight, a lot of that is test changes [18:59] which is good [19:12] mdeslaur: hi, question: we skipped CVE-2016-2775 because it's in lwresd and that package is in universe? [19:12] mdeslaur: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-2775.html [19:12] or that just means it's not as urgent, and it's still work in progress? [19:13] ahasenack: it means someone from the community has to contribute a debdiff and test it, etc. [19:14] ok [19:14] I may include it next time, I just keep forgetting [19:18] man, it's harder than I thought to read a conflict in a d/p file [19:19] ahasenack: right, because it's a conflict in diff [19:19] exactly [19:19] the diff should be the same [19:19] ahasenack: you get used to it :) [19:19] I mean, the file is named the same :) [19:19] but I want to be sure [19:20] ahasenack: md5sum it [19:20] nacc: how can I see the two files? git doesn't create .dotfile versions [19:20] both added: debian/patches/CVE-2016-2776.patch [19:20] ahasenack: i'm not sure i understand your question [19:20] ahasenack: but you can always do `git show :/path/to/file` [19:20] I want to quickly see the debian version of that file, and my version [19:21] * ahasenack tries git show [19:21] new/debian [19:21] right [19:21] works [19:22] much metter [19:23] ok, just a dep3 difference, and the usual @line numbers [20:10] nacc: hm, if you could spare a moment [20:10] nacc: http://pastebin.ubuntu.com/24974921/ [20:10] debian has that patch already [20:10] slightly different (dep3 header), and of course the series file has conflicts [20:10] how do I drop our change in this case? [20:13] I could rebase --skip, but let's say I want to record this with some sort of commit [20:19] * ahasenack thinks git checkout --ours on both files [20:19] that it becomes an empty commit [20:27] s/that/then/ [20:37] ahasenack: i'm here now [20:37] ahasenack: can we do a HO? [20:37] sure [20:38] ahasenack: use the standup one? just easier to discuss the code if we are looking at the same [20:38] nacc: standup, yep [20:38] ahasenack: omw [20:45] ahasenack: ORIG_HEAD [20:45] ahasenack: once all resolved, you'll run `git commit --allow-empty -c ORIG_HEAD` [21:04] nacc: after the empty commit, git rebase --continue is complaining about empty changes, and advising --skip [21:04] ahasenack: hrm, `git status` says nothing to commit? [21:04] http://pastebin.ubuntu.com/24975282/ [21:04] ahasenack: ok, then maybe you do need to explicitly --skip it, sorry [21:05] yeah, status is empty [21:05] ok [21:05] (all conflicts fixed: run "git rebase --continue") [21:05] heh [21:05] nothing to commit, working directory clean [21:05] ok [21:11] hi.. Terminal must be at least 80 x 27. and i don't know how to solve this... [21:13] Czr3: what do you mean? [21:14] i was installin asterisk 14 on debian 9, then when i used "make menuselect" it said error: "terminal must be at least 80 x 27".. [21:14] installing* [21:15] debian 9? [21:15] yeap D= [21:15] * dpb1 points at name of channel. :) [21:25] patch 6 out of 12 [21:25] phew [21:26] does anybody here have VMs running with QCOW2 disks under KVM with the discard=unmap setting? fstrim seems to work for me from within the VM, but the disk image size doesn't decrease [21:26] i'm using pc-i440fx-xenial for the machine type, and virtio-scsi [21:27] that patch for cve 2016 8864 was infamous it seems: [21:27] CVE-2016-8864.patch [21:27] CVE-2016-8864-regression2.patch [21:27] CVE-2016-8864-regression.patch [21:28] furkan: I don't know what discard=unmap does, but regarding qcow2 image sizes, did you check with du and qemu-image info? [21:28] as opposed to ls, I mean [21:28] you may need to repack the qcow2 I wouldn't expect them to magically shrink or pass through the holes to the OS [21:28] discard=unmap enables TRIM on the guest, so it informs the hypervisor of blocks that have been deleted [21:29] so theoretically that's supposed to allow the image to shrink by itself [21:29] http://dustymabe.com/2013/06/11/recover-space-from-vm-disk-images-by-using-discardfstrim/ [21:31] so when i run fstrim on the VM, it tells me that it's trimmed 3.8GB, but the image size stays the same