Correct, the "regression", such as it was, seemingly exists only as a
change to how that invalid systemd-resolved conf was handled. I did go
back and verify that the invalid config did function on the old version,
but no on the new, so there is a functional change there, but given the
invalidity in
Well ... that configuration correction appears to have done the trick!
I'm very sorry to have inadvertently put you through this for the sake
an off-by-one-character invalid config. Re-reading the documentation I
can now see where the confusion occurred when crafting the config
originally, and I gu
Sorry, I've been a bit swamped and this fell through the cracks, I'll
try and find some time this week to try with the updated config.
In answer to your previous question: yes, the dig was the first thing I
did following a reboot each time with the intention of providing the
smallest number of log
Here you are, Till. Three sections, one for each NM version containing
the two dig requests during the tests, plus one for a dig to contact the
local DNS explicitly.
nm-1.10.6:
$ dig dnsmasq.local.org.com | grep -FA1 ';; ANSWER' # first attempt always fails
;; ANSWER SECTION:
dnsmasq.local.org.co
Process follows directly from previous comment.
- Updated to network-manager 1.10.14-0ubuntu2 (from bionic-proposed)
- Rebooted and ran dig twice to mirror previous test, never resolved to
expected result. :(
- Log file from reboot until after the second dig attached.
Ran dig a few more times ov
Can only attach one file at a time, so this and the next comment are
heavily linked.
- Updated to systemd 237-3ubuntu10.22 (from bionic-updates)
- Enabled debug logging for network manager and disabled flood protection on
journald.
- Rebooted and successfully ran dig (second attempt)
- First ru
Installed the systemd from the ppa and the .14 NM package:
ii network-manager 1.10.14-0ubuntu2
ii systemd 237-3ubuntu10.22~ppa1
Rebooted, gave it a spin and no good, I'm afraid. The 127.0.0.54
resolver was still left out of the loop. I've since gone back to the
public systemd versi
Yup, it shows up at the top of the global resolver list:
$ systemd-resolve --status
Global
Public bug reported:
On 18.04.2 the `upgrade network-manager:amd64 1.10.6-2ubuntu1.1
1.10.14-0ubuntu2` lead to scoped DNS servers defined in
`/etc/systemd/resolved.conf.d/*.conf` being ignored.
Downgrading with `sudo apt-get install network-
manager=1.10.6-2ubuntu1.1` has resolved the issue for n
9 matches
Mail list logo
