Tim:
> > And there are (or were?) various apps that look to Network Manager
> > to tell if you're off- or on- line.
Felix Miata:
> I don't know why apps would care. When I want to know, I look at the
> LEDs on my router and/or modem and/or ethernet port
Likewise...
I found it a problem. If one
Tim composed on 2025-04-28 15:16 (UTC+0930):
> On Sun, 2025-04-27 at 13:58 -0400, Felix Miata wrote:
>> Having no mobile computers, and none using wireless networking, I find
>> myself to
>> be the only network manager needed, and barely so, so have no network manager
>> installed
> It can stil
Tim via users:
> > My internal DNS can obviously answer my LAN addressing queries, and
> > it's set up to also resolve queries about internet addresses. It runs
> > as a full server. No public server can answer queries about my LAN.
Marco Moock:
> Then only have the internal DNS set in your OS.
On Sun, 2025-04-27 at 13:58 -0400, Felix Miata wrote:
> Having no mobile computers, and none using wireless networking, I find myself
> to
> be the only network manager needed, and barely so, so have no network manager
> installed
It can still manage that *one* connection. And there are (or were
François Patte composed on 2025-04-27 12:46 (UTC+0200):
> Once upon a time, there were a file ifcfg-xxx were the ethernet config
> was clearly written but times have changed!
Having no mobile computers, and none using wireless networking, I find myself to
be the only network manager needed, and
On 4/27/25 3:46 AM, François Patte wrote:
Le 27/04/2025 à 07:49, Samuel Sieb a écrit :
On 4/26/25 2:05 PM, François Patte wrote:
Le 24/04/2025 à 23:01, Jonathan Billings a écrit :
On Apr 24, 2025, at 08:28, François Patte
wrote:
am a little bit confused about the dns : I have systemd
Am 27.04.2025 um 20:42:23 Uhr schrieb Tim via users:
> My internal DNS can obviously answer my LAN addressing queries, and
> it's set up to also resolve queries about internet addresses. It runs
> as a full server. No public server can answer queries about my LAN.
Then only have the internal DN
nswered and the others won't be queried.
I think I read that systemd-resolved queries all servers in parallel and return
the answer
from the first server to respond?
If the servers do not have consistent contents you see unexpected query results.
Barry
--
_
On Sun, 2025-04-27 at 12:17 +0200, Marco Moock wrote:
> Then you have a general problem. DNS is intended to give back the same
> results for the same query - regardless which server you ask.
Yes, and no.
My internal DNS can obviously answer my LAN addressing queries, and
it's set up to also resol
Le 27/04/2025 à 07:49, Samuel Sieb a écrit :
On 4/26/25 2:05 PM, François Patte wrote:
Le 24/04/2025 à 23:01, Jonathan Billings a écrit :
On Apr 24, 2025, at 08:28, François Patte
wrote:
am a little bit confused about the dns : I have systemd-resolved
installed and when I list the content of
e others. If it does respond (even if it doesn't have and
> > results), it has answered and the others won't be queried.
>
> I think I read that systemd-resolved queries all servers in parallel
> and return the answer from the first server to respond?
>
> If the se
On Sat, 2025-04-26 at 23:05 +0200, François Patte wrote:
> Current DNS Server: 192.168.1.1
> DNS Servers: 80.67.169.12 80.67.169.40 192.168.1.1
Having multiple DNS servers, like that, *can* be a problem. It depends
on your use case.
The system will usually have a default server it querie
On 4/26/25 2:05 PM, François Patte wrote:
Le 24/04/2025 à 23:01, Jonathan Billings a écrit :
On Apr 24, 2025, at 08:28, François Patte wrote:
am a little bit confused about the dns : I have systemd-resolved
installed and when I list the content of the package (rpm -ql), I can
read on the
Le 24/04/2025 à 23:01, Jonathan Billings a écrit :
On Apr 24, 2025, at 08:28, François Patte wrote:
am a little bit confused about the dns : I have systemd-resolved installed and
when I list the content of the package (rpm -ql), I can read on the first line:
/etc/systemd/resolved.conf
But
On Apr 24, 2025, at 08:28, François Patte wrote:
> am a little bit confused about the dns : I have systemd-resolved installed
> and when I list the content of the package (rpm -ql), I can read on the first
> line:
>
> /etc/systemd/resolved.conf
>
> But there is no /etc/
On 4/24/25 5:27 AM, François Patte wrote:
I am a little bit confused about the dns : I have systemd-resolved
installed and when I list the content of the package (rpm -ql), I can
read on the first line:
/etc/systemd/resolved.conf
But there is no /etc/systemd/resolved.conf
It's a ghost
Bonjour,
I am a little bit confused about the dns : I have systemd-resolved
installed and when I list the content of the package (rpm -ql), I can
read on the first line:
/etc/systemd/resolved.conf
But there is no /etc/systemd/resolved.conf
There is a /usr/lib/systemd/resolved.conf but it
points, systemd-resolved stops
working. BUT Trustedqsl works and I need that working..
So, Now my choise is comment those out and use system-resolved
as masked, and use self edited resolv.conf
So, my point of vew, problem SOLVED. Another thing is, vhen TQSL
corrects program to follow these new O
Sun, 10 Nov 2024 07:44:54 -0500
Jonathan Billings kirjoitti:
>> Sadly, your excerpt from the journal starts *just* after anything
> useful might have been recorded. It’s just systemd noise about the
> service not failing and how it isn’t restarting it.
>
> But I can’t comment further because ap
On Nov 10, 2024, at 03:04, jarmo wrote:
>
> I see no network, after starting computer, which I do very seldom,
> only when there comes kernel update.
> So network does not start at all and when doing journal query I get
> this, what I sent before...
>
> journalctl -xeu systemd-resolved.service
>
worth running memtest diagnostic to eliminate RAM issues.
>
> Barry
When I upgraded into F41, everything worked fine, no problem.
But afterward came some updates, started this systemd-resolved
problem.
I think, if there is HW problem, it should effect also, when I'm using
th
> On 10 Nov 2024, at 08:04, jarmo wrote:
>
> I see no network, after starting computer
What does `ip addr` report when you have “no network”?
I wonder if you have a hardware problem?
Might be worth running memtest diagnostic to eliminate RAM issues.
Barry
--
__
Fri, 8 Nov 2024 23:14:57 +
Barry kirjoitti:
> > On 8 Nov 2024, at 13:19, jarmo wrote:
> >
> > Had to install inxi first :)
>
> Thanks for the info.
>
> Do you see systemd-resolved failing immediately after you first login?
> Or does if fail after you
> On 8 Nov 2024, at 13:19, jarmo wrote:
>
> Had to install inxi first :)
Thanks for the info.
Do you see systemd-resolved failing immediately after you first login?
Or does if fail after you have been using the system for a little while?
After it fails do you see any journal logs
On Fri, 2024-11-08 at 01:19 -0500, Jeffrey Walton wrote:
> Disabling a service only lasts until the next (re)boot. And it does
> not stop currently executing services, and the service can still be
> started in the current session.
Not quite the full picture, not in general, even if that was a spec
Fri, 8 Nov 2024 12:58:16 +
Barry Scott kirjoitti:
>
> I asked for `inxi -Fzxx` that will provide a lot of info beyond RAM
> can you provide that?
>
> FYI I use `free -h` so that the numbers are easier to read.
>
> Barry
Had to install inxi first :)
Below is with sys
> On 8 Nov 2024, at 09:44, jarmo wrote:
>
> Fri, 8 Nov 2024 09:06:46 +
> Barry kirjoitti:
>
>>> On 8 Nov 2024, at 06:02, jarmo wrote:
>>>
>>> Process: 19413 ExecStart=/usr/lib/systemd/systemd-resolved
>>> (code=exited, status=1/
Fri, 8 Nov 2024 09:06:46 +
Barry kirjoitti:
> > On 8 Nov 2024, at 06:02, jarmo wrote:
> >
> > Process: 19413 ExecStart=/usr/lib/systemd/systemd-resolved
> > (code=exited, status=1/FAILURE) Main PID: 19413 (code=exited,
> > status=1/FAILURE) Error: 12
> On 8 Nov 2024, at 06:02, jarmo wrote:
>
> Process: 19413 ExecStart=/usr/lib/systemd/systemd-resolved (code=exited,
> status=1/FAILURE)
> Main PID: 19413 (code=exited, status=1/FAILURE)
> Error: 12 (Muistin varaaminen ei onnistu)
This is ENOMEM and that implie
Fri, 8 Nov 2024 01:19:34 -0500
Jeffrey Walton kirjoitti:
get my network working.
>
> Disabling a service only lasts until the next (re)boot. And it does
> not stop currently executing services, and the service can still be
> started in the current session.
>
> If you want to permanently disa
On Fri, Nov 8, 2024 at 1:02 AM jarmo wrote:
> [...]
>
> So, I disable systemd-resolved and manually create /etc/resolv.conf
> to get my network working.
Disabling a service only lasts until the next (re)boot. And it does
not stop currently executing services, and the service
Thu, 7 Nov 2024 22:10:31 +
Barry kirjoitti:
> > On 7 Nov 2024, at 17:31, Barry wrote:
> >
> > What is the output of systemctl status systemd-networkd?
>
> Sorry i mean the output of systemctl status systemd-resolved !
>
> Barry
>
systemctl
> On 7 Nov 2024, at 17:31, Barry wrote:
>
> What is the output of systemctl status systemd-networkd?
Sorry i mean the output of systemctl status systemd-resolved !
Barry
--
___
users mailing list -- users@lists.fedoraproject.org
To un
> On 7 Nov 2024, at 15:08, jarmo wrote:
>
> Won't start, claims something about memory,
> sorry, can't specify, made local resolv.conf
> to get network running..
What is the output of systemctl status systemd-networkd?
>
> It is enabled by default, I disabled to get
> self edited dns query
Won't start, claims something about memory,
sorry, can't specify, made local resolv.conf
to get network running..
It is enabled by default, I disabled to get
self edited dns query working..
Fedora 41 xfce4
Jarmo
--
___
users mailing list -- users@lists
After Upgrading to Fedora 35 split DNS resolution with systemd-resolved doesn't
work anymore.
My Fedora server managed a libvirt virtual network for internal communicatin
between VMs. Systemd doesn't work nicely with libvirt, among others does
libvirt manage virtual networks di
Peter. Considering your 5 years here and the topic of systemd-resolved. I was
wondering if you could help me to propose a default change to the installation
of systemd-resolved that seems to have helped me keep it installed and working
even with a Local DNS server in the mix.
This approach
On 6/5/22 17:18, stan via users wrote:
On Sat, 4 Jun 2022 16:07:12 -0400
Tom Horsley wrote:
Try editing /etc/NetworkManager/NetworkManager.conf and putting
dns=none after the [main] section entry.
I have to do this in order to use dns servers other than those the ISP
provides with knot-reso
> On 4 Jun 2022, at 21:07, Tom Horsley wrote:
>
> On Sat, 04 Jun 2022 15:55:53 -0400
> Sam Varshavchik wrote:
>
>> this ends up creating /etc/resolv.conf as a plain file, rather than a
>> symlink. But, I suppose, that works too.
>
> Perhaps people who want their own damn resolv.conf file
>
On Sat, 4 Jun 2022 16:07:12 -0400
Tom Horsley wrote:
> Try editing /etc/NetworkManager/NetworkManager.conf and putting
> dns=none after the [main] section entry.
I have to do this in order to use dns servers other than those the ISP
provides with knot-resolver.
_
On Sat, 04 Jun 2022 15:55:53 -0400
Sam Varshavchik wrote:
> this ends up creating /etc/resolv.conf as a plain file, rather than a
> symlink. But, I suppose, that works too.
Perhaps people who want their own damn resolv.conf file
are missing this obscure setting:
Try editing /etc/NetworkManager
Petr Menšík writes:
Symlinks obviously ends with non-expected SELinux contexts. I think this is
actually a bug in SELinux policy for Network Manager. Because target file
has wrong selinux context.
$ ls -Z /run/NetworkManager/no-stub-resolv.conf
system_u:object_r:NetworkManager_var_run_t:s0
:51, Sam Varshavchik wrote:
It seems that uninstalling systemd-resolved and repointing
/etc/resolv.conf ends up breaking chrony:
type=AVC msg=audit(1653741361.179:318): avc: denied { getattr } for
pid=856 comm="chronyd" path="/run/NetworkManager/no-stub-resolv.conf"
On Sat, 28 May 2022 08:51:08 -0400
Sam Varshavchik wrote:
> It seems that uninstalling systemd-resolved and repointing /etc/resolv.conf
> ends up breaking chrony:
The simplest fix is the also remove chrony and install ntp.
___
users mailin
It seems that uninstalling systemd-resolved and repointing /etc/resolv.conf
ends up breaking chrony:
type=AVC msg=audit(1653741361.179:318): avc: denied { getattr } for
pid=856 comm="chronyd" path="/run/NetworkManager/no-stub-resolv.conf"
dev="
On 14/04/2021 02:38, Jack Craig wrote:
On Tue, Apr 13, 2021 at 3:52 AM Tim via users mailto:users@lists.fedoraproject.org>> wrote:
On Mon, 2021-04-12 at 12:06 -0700, Jack Craig wrote:
> Oh so now I have learned something new.
>
> I thought that because I was a Domain owner, I had
On Tue, Apr 13, 2021 at 3:52 AM Tim via users
wrote:
> On Mon, 2021-04-12 at 12:06 -0700, Jack Craig wrote:
> > Oh so now I have learned something new.
> >
> > I thought that because I was a Domain owner, I had to do the
> > translation from my public IP to my local DNS name
>
> Just to be clear:
On Mon, Apr 12, 2021 at 11:54 PM J.Witvliet--- via users <
users@lists.fedoraproject.org> wrote:
>
>
>
> *From: *"Jack Craig"
> *Date:* Monday, 12 April 2021 at 21:07:07
> *To: *"Community support for Fedora users"
> *Subject:* Re: systemd-resolv
On 13/04/2021 18:52, Tim via users wrote:
You can see that sort of thing with the "dig" tool. If you do a "dig
example.com" you'll get a collection of responses. The "answer"
section is the domain name and numerical IP address for it, that you
queried. The "authority" section will be the autho
On Mon, 2021-04-12 at 12:06 -0700, Jack Craig wrote:
> Oh so now I have learned something new.
>
> I thought that because I was a Domain owner, I had to do the
> translation from my public IP to my local DNS name
Just to be clear:
By "your public IP" do mean the IP for your server that the worl
From: "Jack Craig"
mailto:jack.craig.ap...@gmail.com>>
Date: Monday, 12 April 2021 at 21:07:07
To: "Community support for Fedora users"
mailto:users@lists.fedoraproject.org>>
Subject: Re: systemd-resolved, split dns, & vpn setup
Oh so now I have learned so
Oh so now I have learned something new.
I thought that because I was a Domain owner, I had to do the translation
from my public IP to my local DNS name
in as much as networksolutions.com, my domain registrar provider, has
already the IP and host name then
I don't need to provide that so let me t
I'm answering this with a separate response because it goes off in a
different direction. You can decide which way to go without mixing up
all the information together.
On Sat, 2021-04-10 at 12:03 -0700, Jack Craig wrote:
> I think I understand that the primary name server for domain must be
> in
On Sat, 2021-04-10 at 12:03 -0700, Jack Craig wrote:
> OK time to share the real problem here ,it is me. that is to say
> after several decades of computer work I got Parkinson's and that
> forced me to stop working commercially. I didn't want to give up my
> networking all the way so I keep thi
On Sat, Apr 10, 2021 at 1:20 AM Tim via users
wrote:
> On Thu, 2021-04-08 at 13:37 -0700, Jack Craig wrote:
> > I have tried at length to get bind 9 to support proper a split
> > horizon configuration without success.
>
> I remember going through that with you last year. It definitely works,
> a
On Thu, 2021-04-08 at 13:37 -0700, Jack Craig wrote:
> I have tried at length to get bind 9 to support proper a split
> horizon configuration without success.
I remember going through that with you last year. It definitely works,
as I did it on my system as I went through it with you.
Do you hav
gt; second article
> > where it said, if I understand this correctly, the systemD-resolveD is
> not appropriate for the primary DNS server of a domain.
>
> Indeed, systems-resolved is a name resolver, as the name suggest, and it
> queries a DNS server to get needed Informations.
> Am 08.04.2021 um 22:37 schrieb Jack Craig :
>
> This was looking like a good solution until I got down to the end of the
> second article
> where it said, if I understand this correctly, the systemD-resolveD is not
> appropriate for the primary DNS server of a domain
er config
connecting my external ip, 108.220.213.121 to it's internal 10.0.0.101.
I have tried at length to get bind 9 to support proper a split horizon
configuration without success.
I came across two very informative articles about systemD-resolveD and
their future implementation on F33 as st
On 11/01/2021 03:25, Jerome Lille wrote:
On Sun, 2021-01-10 at 15:44 +0800, Ed Greshko wrote:
On 06/01/2021 00:10, Jerome Lille wrote:
I've just updated a desktop from Fedora 32 to 33 and after that the
logs are flooded with the following message
systemd-resolved[]: Using degraded featur
On Sun, 2021-01-10 at 15:44 +0800, Ed Greshko wrote:
> On 06/01/2021 00:10, Jerome Lille wrote:
> > I've just updated a desktop from Fedora 32 to 33 and after that the
> > logs are flooded with the following message
> >
> > systemd-resolved[]: Using degraded featur
Ed Greshko writes:
Networkmanager must be checking if /etc/resolv.conf is a symbolic link and
only updating its own private resolver configs, otherwise it'll update them
and /etc/resolv.conf
I have no idea of what "private configs" you speak. I also can't think of
The configs in /var/run
On 10/01/2021 14:50, Ed Greshko wrote:
I also can't think of why NM would ever check if
/etc/resolv.conf was a symlink.
I actually meant to say there would be no need to check if systemd-resolved is
masked.
But, either way, that was not a very well thought out statement.
---
The k
On 06/01/2021 00:10, Jerome Lille wrote:
I've just updated a desktop from Fedora 32 to 33 and after that the
logs are flooded with the following message
systemd-resolved[]: Using degraded feature set TCP instead of UDP for
DNS server 127.0.0.1.
systemd-resolved[]: Using degraded feature se
ic, I created an empty file by "touch"ing it. Then, on rebott,
since systemd-resolved is
masked NM will populate the file as it always has. In other words, the
previous method of doing
name resolution is in effect/restored.
But there are apps that read /etc/resolv.conf themselves (Firefox
On 10/01/2021 12:24, Sam Varshavchik wrote:
Tim via users writes:
Ed Greshko:
>> When I tested reverting to the previous behavior I simply started
>> with an empty /etc/resolv.conf.
>> No symlink. No selinux troubles. Everything just worked.
Sam Varshavchik:
> Well, then how do the apps that
y, meanwhile bind, on the same server, was like: "WHASSSUP"
And this happened several times, over the course of a week, it wasn't just a
one-time fluke.
I defy anyone to come up with a logical explanation why systemd-resolved
couldn't find bind running on the same
Ed Greshko:
>> When I tested reverting to the previous behavior I simply started
>> with an empty /etc/resolv.conf.
>> No symlink. No selinux troubles. Everything just worked.
Sam Varshavchik:
> Well, then how do the apps that need to talk to the DNS server find
> it? Maybe something in the gli
Ed Greshko writes:
When I tested reverting to the previous behavior I simply started with an
empty /etc/resolv.conf.
No symlink. No selinux troubles. Everything just worked.
Well, then how do the apps that need to talk to the DNS server find it?
Maybe something in the glibc resolver know
On 10/01/2021 09:17, Ed Greshko wrote:
On 10/01/2021 09:12, Sam Varshavchik wrote:
Doug H. writes:
>
> Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to
> be fixed.
Thanks for opening that bug.
Note that my outbound e-mail was being blocked by this. I am using post
On 10/01/2021 09:12, Sam Varshavchik wrote:
Doug H. writes:
>
> Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to
> be fixed.
Thanks for opening that bug.
Note that my outbound e-mail was being blocked by this. I am using postfix for outbound and the smtp alerts
we
Doug H. writes:
>
> Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to
> be fixed.
Thanks for opening that bug.
Note that my outbound e-mail was being blocked by this. I am using postfix
for outbound and the smtp alerts were triggering for each outbound e-mail
att
; > > wrote:
> > > > >
> > > > > Maybe this bug:
> > > >
> > > > https://github.com/systemd/systemd/issues/13432
> > >
> > > "opened this issue on Aug 29, 2019"
> > >
> > > I would not expect this to be fixed an
Michael H. Warfield writes:
> What I do is disable systemd-resolved and fix the resolv.conf file
> to put back the original and get rid of systemd's symlink.
ALSO! Remove the "resolve [!UNAVAIL=return]" stanza for hosts in
/etc/nsswitch.conf! That seems to have bee
On Tue, 2021-01-05 at 11:35 -0500, Tom Horsley wrote:
> On Tue, 05 Jan 2021 17:10:06 +0100
> Jerome Lille wrote:
> > What can be done?
>
> What I do is disable systemd-resolved and fix the resolv.conf file
> to put back the original and get rid of systemd's symlink.
32
>
> "opened this issue on Aug 29, 2019"
>
> I would not expect this to be fixed any time soon. The only solution
> is:
>
> systemctl stop systemd-resolved
> systemctl disable systemd-resolved
> rm -f /etc/resolv.conf
> ln -s ../run/NetworkManager/no-stub-
;opened this issue on Aug 29, 2019"
>
> I would not expect this to be fixed any time soon. The only solution
> is:
>
> systemctl stop systemd-resolved
> systemctl disable systemd-resolved
> rm -f /etc/resolv.conf
> ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/r
Chris Murphy writes:
On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy wrote:
>
> Maybe this bug:
https://github.com/systemd/systemd/issues/13432
"opened this issue on Aug 29, 2019"
I would not expect this to be fixed any time soon. The only solution is:
systemctl stop
ktop from Fedora 32 to 33 and after that
> > > the
> > > logs are flooded with the following message
> > >
> > > systemd-resolved[]: Using degraded feature set TCP instead of UDP
> > > for
> > > DNS server 127.0.0.1.
> > > systemd-reso
On Tue, 2021-01-05 at 11:37 -0500, Tim Evans wrote:
> On 1/5/21 11:10 AM, Jerome Lille wrote:
>
> > This machine uses a VPN service that is always on. The file
> > /etc/resolver.conf has just one line with the nameserver from the
> > VPN
>
> You do mean /etc/resolv.conf, right?
Right
___
On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy wrote:
>
> On Tue, Jan 5, 2021 at 9:10 AM Jerome Lille wrote:
> >
> > Hi
> >
> > I've just updated a desktop from Fedora 32 to 33 and after that the
> > logs are flooded with the following message
> >
>
On Tue, Jan 5, 2021 at 9:10 AM Jerome Lille wrote:
>
> Hi
>
> I've just updated a desktop from Fedora 32 to 33 and after that the
> logs are flooded with the following message
>
> systemd-resolved[]: Using degraded feature set TCP instead of UDP for
> DNS server
On 1/5/21 11:10 AM, Jerome Lille wrote:
This machine uses a VPN service that is always on. The file
/etc/resolver.conf has just one line with the nameserver from the VPN
You do mean /etc/resolv.conf, right?
--
Tim Evans | 5 Chestnut Court
On Tue, 05 Jan 2021 17:10:06 +0100
Jerome Lille wrote:
> What can be done?
What I do is disable systemd-resolved and fix the resolv.conf file
to put back the original and get rid of systemd's symlink.
___
users mailing list
Hi
I've just updated a desktop from Fedora 32 to 33 and after that the
logs are flooded with the following message
systemd-resolved[]: Using degraded feature set TCP instead of UDP for
DNS server 127.0.0.1.
systemd-resolved[]: Using degraded feature set UDP instead of TCP for
DNS s
There is another thread re systemd-resolved and adguard.
Ed Greshko had a solution to use /etc/resolve.conf instead of the stub file
systemd-resolved uses.
"To revert to the previous behavior you need to remove the symbolic link
lrwxrwxrwx. 1 root root 39 Sep 1 17:52 resolv.conf ->
On Sun, 15 Nov 2020 at 20:22, Tom H wrote:
> On Sun, Nov 15, 2020 at 10:15 AM Anthony F McInerney
> wrote:
>
>
> > Can someone explain why systemd-resolved needs to symlink
> > /etc/resolv.conf to 4(or more) different places, instead of just
> > having those &
On Sun, Nov 15, 2020 at 10:15 AM Anthony F McInerney
wrote:
> Can someone explain why systemd-resolved needs to symlink
> /etc/resolv.conf to 4(or more) different places, instead of just
> having those 'detected things' as options in
> /etc/systemd/resolved.conf ?
The di
rgument against having /etc/resolv.conf
> managed by alternatives. If systemd-resolved wishes to have the highest
> alternatives priority, and thus ends up being the resolver by default,
> that's fine.
>
> Does anyone have an argument /against/ having /etc/resolv.conf managed
>
"detected fully automatically"?
We've had a mechanism for controlling symlinks for an eternity:
alternatives.
I cannot see any valid technical argument against having /etc/resolv.conf
managed by alternatives. If systemd-resolved wishes to have the highest
alternatives priority
> It is a malignant carcinoma.
Okay, seriously y'all. This over-the-top animosity is not welcome here. This
is a Fedora list, and we expect discourse to remain civil. If you don't like
it, fine.
You have a number of options, including working on a Fedora spin which
configures things differently.
No.
It is a malignant carcinoma.
From: "Tom Horsley" mailto:horsley1...@gmail.com>>
Date: Saturday, 14 November 2020 at 15:16:35
To: "users@lists.fedoraproject.org"
mailto:users@lists.fedoraproject.org>>
Subject: Re: systemd-resolved breakage
On Sat, 14 Nov
esolv.conf again? Can I make it rewrite after disabling
> > systemd-resolved? Why doesn't it restore /etc/resolv.conf on
> > systemd-resolved shutdown?
>
> Yes, /etc/resolv.conf is a symlink. Apparently NetworkManager has been
> changed to write /run/NetworkManager/resolv
On Sat, 14 Nov 2020 11:56:01 +0100
Tom H wrote:
> > Yes, system is being shoved down your gullet, whether you like it
> > or not.
>
> Whichever distribution you use, you're at the mercy of its developers.
> In this particular case, the developer responsible for the change
> didn't care about br
On Sat, Nov 14, 2020 at 12:42 AM Sam Varshavchik
wrote:
> Petr Menšík writes:
>>
>> Am I missing something?
>
> Yes, system is being shoved down your gullet, whether you like it
> or not.
Whichever distribution you use, you're at the mercy of its developers.
In this particular case, the developer
Petr Menšík writes:
Am I missing something?
Yes, system is being shoved down your gullet, whether you like it or not.
would NetworkManager.conf:
dns=default
Write resolv.conf again? Can I make it rewrite after disabling
systemd-resolved? Why doesn't it restore /etc/resolv.conf on
sy
On Fri, Nov 13, 2020 at 3:17 PM Petr Menšík
wrote:
>
> Sad thing is, I want Network Manager to write my resolv.conf as it
> did before. I just want systemd-resolved disabled and keep simple
> text file in /etc/resolv.conf.
>
> I haven't found automatic way to recove
On Fri, Nov 13, 2020 at 2:22 PM Tom Horsley wrote:
> systemctl stop systemd-resolvd
> systemctl disable systemd-resolvd
resolved
> Edit /etc/NetworkManager/NetworkManager.conf And in the [main]
> section stick this:
>
> [main]
> dns=none
Since "/etc/NetworkManager/NetworkManager.conf" is
"%c
Sad thing is, I want Network Manager to write my resolv.conf as it did
before. I just want systemd-resolved disabled and keep simple text file
in /etc/resolv.conf.
I haven't found automatic way to recover my system, after I do:
systemctl disable --now systemd-resolved
It keep broken
(Relatively) simple fix:
systemctl stop systemd-resolvd
systemctl disable systemd-resolvd
Edit /etc/NetworkManager/NetworkManager.conf And in the [main]
section stick this:
[main]
dns=none
Now rm -f /etc/resolv.conf
Now create your own /etc/resolv.conf file from scratch with
the nameserver and
1 - 100 of 130 matches
Mail list logo
