[09:14] <faekjarz> Do i need to run "do-release-upgrade -d" in order to upgrade from 20.04 to 22.04 LTS, now? (i kinda don't want to install a development release)
[09:20] <lotuspsychje> !ltsupgrade | faekjarz 
[09:22] <faekjarz> thanks, lotuspsychje
[09:23] <faekjarz> is there an actual schedule that could tell me when the .1 release is due? the release cycle page doesn't help
[09:23] <lotuspsychje> august probably faekjarz 
[09:24] <faekjarz> hmm, k thx
[09:24] <lotuspsychje> and for production servers, that would be reccomended to await .1
[09:27] <faekjarz> aye! it's my home server and i have a fresh clonezilla backup from an hour ago - i shall boldly go... ;)
[09:27] <lotuspsychje> see also the releasenotes before you go faekjarz 
[09:27] <lotuspsychje> !jammy
[10:54] <technohead> Hi, anyone has setup Bind with chroot jail? Any decent guide which you can recommend me?
[11:36] <odc> nope, I deployed BIND in docker. Easier than a chroot!
[12:18] <sdeziel> technohead: I put bind9 in a LXD container and add the following systemd hardening snippet to it: https://termbin.com/eqoq
[12:19] <sdeziel> technohead: so no chroot but you can achieve something similar with systemd mount features (*Path=)
[13:17] <teward> sdeziel: the only way to fix d-r-u a-la #1977667 is to fix the underlying scripts so they don't exit in an error case.  Which is impossible with the postinst and a systemd call
[13:17] <teward> the error chain you have is, from inner to outer:
[13:18] <sdeziel> teward: wait
[13:18] <teward> dpkg error code ---> apt error code ---> d-r-u error code
[13:18] <sdeziel> teward: I cannot even get d-r-u to abort the upgrade :)
[13:18] <teward> sdeziel: it's been well known for eons that you can't 'abort' an upgrade mid-install mid-configuration
[13:18] <teward> hence the "backup your stuff first" problem
[13:18] <teward> sdeziel: my point is
[13:18] <sdeziel> teward: d-r-u did the right thing by continuing (at least in my reproducing attempt)
[13:18] <teward> sdeziel: i think you misunderstand the call chain
[13:19] <teward> you ARE aware that the configure steps happen *after* all the package installs/updates/etc. happen right?
[13:19] <sdeziel> yep
[13:19] <teward> and you ARE aware that when dpkg/apt fails to configure a package *it* in turn returns an error code, independent of d-r-u yes?
[13:20] <teward> unless you are telling d-r-u to ignore error cases where dpkg/apt fails to install/configure which all happen at one command call, I don't see a way for d-r-u to 'ignore' the config failure
[13:20] <sdeziel> this is the part that I'm not 100% now because in my reproducing steps, nginx-light shows as "ii" in `dpkg -l` despite the error I introduced
[13:20] <teward> because, IMO, if a package fails to configure on upgrade, that's a problem.
[13:20] <teward> sdeziel: i'm past the nginx issue
[13:20] <teward> sdeziel: as we already discussed in bug it's not an NGINX issue
[13:21] <sdeziel> teward: yeah, we all know this has nothing to do with NGINX
[13:21] <teward> the underlying issue needs its own d-r-u bug IMO
[13:21] <teward> not continuing to compound on the nginx bug :P
[13:21] <teward> my point still stands regardless
[13:21] <teward> let's say this was Apache
[13:21] <teward> or BIND
[13:21] <teward> or $insert_server_package_here
[13:21] <teward> similar config failures, same trigger case problem with a d-r-u failure
[13:22] <teward> what OP discovered and you're seeing is an inherent apt/dpkg/subprocess forking error code handling issue
[13:22] <sdeziel> teward: I took the liberty to try an reproduce the problem without changing the bug assignment ... maybe I should have moved it first, sorry. Even then, I didn't find a problem with d-r-u so AFAIK, there is no bug at all
[13:22] <teward> sdeziel: i think the red herring error case is the problem
[13:22] <teward> at the same time i don't see a way to "bypass" that is my thing
[13:22] <teward> so ultimately I don't see this as a bug and the fact we're still digging is just spamming things :P
[13:22] <teward> *yawns* sorry i woke up grumpy
[13:22] <teward> still recovering from the COVID
[13:25] <sdeziel> teward: should the "affects nginx" link be dropped from that bug?
[13:26] <teward> i believe so, yes, as it's an "invalid" against NGINX.
[13:26] <teward> the bug needs a retitle though too
[13:26] <teward> to not confuse people
[13:26] <teward> again, apologies if i seem hostile today, i'm just grumpy from the COVID.  most of the symptoms are gone, but i'm still sleeeeepy heh
[13:28] <teward> (unrelated: COVID sucks, so don't get it if you can avoid it)
[13:33] <sdeziel> teward: I'll let the reporter deal with the retitle as this one seems to be coming from d-r-u automatic bug report or something
[13:33] <teward> sdeziel: it's not a d-r-u reported bug
[13:33] <teward> d-r-u is letting apt report the bug
[13:34] <teward> the bug report is the apt "install failed" bug
[13:34] <teward> so this needs a LOT more love than just OP here
[13:34] <teward> again, this is how you and I understand the call chain but $AVERAGE_JOE won't
[13:36] <sdeziel> well, to be honest, I just noticed "The upgrade has aborted" followed by "A recovery will run now (dpkg --configure -a)" ;)
[14:44] <ahasenack> kanashiro: do you have that corosync bug # at hand?
[14:44] <ahasenack> i can't find it
[14:45] <kanashiro> ahasenack, let me check
[14:46] <ahasenack> it's not even in https://people.canonical.com/~ubuntu-archive/pending-sru.html, I thought it would be there
[14:47] <kanashiro> it was marked as server-todo I think
[14:48] <ahasenack> got it
[14:48] <ahasenack> https://bugs.launchpad.net/charm-hacluster/+bug/1874719
[18:08] <scortal> hi
[18:58] <scortal> hi
[20:30] <kinghat> my server 20.04 time is off, is there a best practice for getting it back on time? 
[20:31] <ahasenack> kinghat: see if this helps: https://ubuntu.com/server/docs/network-ntp
[20:39] <kinghat> ahasenack: 👍
[20:39] <kinghat> think im back on track
[21:10] <scortal> hi all