| === shokohsc5 is now known as shokohsc | ||
| === not_phunyguy is now known as phunyguy | ||
| === nuccitheboss1 is now known as nuccitheboss | ||
| === scoobydoo_ is now known as scoobydoo | ||
| 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:14 |
|---|---|---|
| lotuspsychje | !ltsupgrade | faekjarz | 09:20 |
| ubottu | faekjarz: Regular upgrades from the last but one LTS release to the latest LTS release, 22.04 "Jammy Jellyfish", are enabled days or weeks after 22.04.1 is released. This delay helps to ensure that any lingering issues are resolved before people upgrade production systems. If you'd prefer to upgrade now, use sudo do-release-upgrade -d | 09:20 |
| faekjarz | thanks, lotuspsychje | 09:22 |
| 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:23 |
| faekjarz | hmm, k thx | 09:24 |
| lotuspsychje | and for production servers, that would be reccomended to await .1 | 09:24 |
| 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 | 09:27 |
| ubottu | Ubuntu 22.04 (Jammy Jellyfish) is the 36th release of Ubuntu and the current !LTS release – Download at https://ubuntu.com/download :: Release notes at https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes :: Further schedule at https://ubottu.com/y/jj | 09:27 |
| technohead | Hi, anyone has setup Bind with chroot jail? Any decent guide which you can recommend me? | 10:54 |
| odc | nope, I deployed BIND in docker. Easier than a chroot! | 11:36 |
| sdeziel | technohead: I put bind9 in a LXD container and add the following systemd hardening snippet to it: https://termbin.com/eqoq | 12:18 |
| sdeziel | technohead: so no chroot but you can achieve something similar with systemd mount features (*Path=) | 12:19 |
| === leftyfb_ is now known as leftyfb | ||
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| sdeziel | teward: should the "affects nginx" link be dropped from that bug? | 13:25 |
| 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:26 |
| teward | (unrelated: COVID sucks, so don't get it if you can avoid it) | 13:28 |
| 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:33 |
| 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:34 |
| sdeziel | well, to be honest, I just noticed "The upgrade has aborted" followed by "A recovery will run now (dpkg --configure -a)" ;) | 13:36 |
| ahasenack | kanashiro: do you have that corosync bug # at hand? | 14:44 |
| ahasenack | i can't find it | 14:44 |
| kanashiro | ahasenack, let me check | 14:45 |
| ahasenack | it's not even in https://people.canonical.com/~ubuntu-archive/pending-sru.html, I thought it would be there | 14:46 |
| kanashiro | it was marked as server-todo I think | 14:47 |
| ahasenack | got it | 14:48 |
| ahasenack | https://bugs.launchpad.net/charm-hacluster/+bug/1874719 | 14:48 |
| ubottu | Launchpad bug 1874719 in corosync (Ubuntu Focal) "[SRU] Use the hostname as the node name instead of hardcoded 'node1'" [Medium, In Progress] | 14:48 |
| scortal | hi | 18:08 |
| === bbezak_ is now known as bbezak | ||
| === diddledani_ is now known as diddledani | ||
| === blackboxsw_ is now known as blackboxsw | ||
| === soren_ is now known as soren | ||
| === Fossil_ is now known as Fossil | ||
| === coreycb_ is now known as coreycb | ||
| === tds5 is now known as tds | ||
| scortal | hi | 18:58 |
| kinghat | my server 20.04 time is off, is there a best practice for getting it back on time? | 20:30 |
| ahasenack | kinghat: see if this helps: https://ubuntu.com/server/docs/network-ntp | 20:31 |
| kinghat | ahasenack: 👍 | 20:39 |
| kinghat | think im back on track | 20:39 |
| scortal | hi all | 21:10 |
| === kostkon_ is now known as kostkon | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!