Samuel Sieb writes:
On 5/30/24 3:44 PM, Jeffrey Walton wrote:
On Thu, May 30, 2024 at 6:06 PM Samuel Sieb wrote:
On 5/30/24 2:12 PM, Jeffrey Walton wrote:
I guess what the logic or script is missing (the one Kevin detailed)
is, what to do if NetworkManager is installed and running. That see
On 5/30/24 3:44 PM, Jeffrey Walton wrote:
On Thu, May 30, 2024 at 6:06 PM Samuel Sieb wrote:
On 5/30/24 2:12 PM, Jeffrey Walton wrote:
I guess what the logic or script is missing (the one Kevin detailed)
is, what to do if NetworkManager is installed and running. That seems
like where the prob
On Thu, May 30, 2024 at 6:06 PM Samuel Sieb wrote:
>
> On 5/30/24 2:12 PM, Jeffrey Walton wrote:
> > I guess what the logic or script is missing (the one Kevin detailed)
> > is, what to do if NetworkManager is installed and running. That seems
> > like where the problem occured in your case. In yo
On 5/30/24 13:18, Todd Zullinger wrote:
Kevin Fenzi wrote:
[...snip loads of useful information...]
So, I think if you:
disable systemd-resolved
sudo bash -c 'mkdir -p /etc/systemd/system-preset && echo "disable
systemd-resolved.service" >/etc/systemd/system-preset/20-systemd-resolved-disabl
On 5/30/24 2:12 PM, Jeffrey Walton wrote:
I guess what the logic or script is missing (the one Kevin detailed)
is, what to do if NetworkManager is installed and running. That seems
like where the problem occured in your case. In your case (and others
like you), it seems like the condition 'Networ
On Thu, May 30, 2024 at 4:33 PM Sam Varshavchik wrote:
>
> Todd Zullinger writes:
>
> > Kevin Fenzi wrote:
> > [...snip loads of useful information...]
> > > So, I think if you:
> > >
> > > disable systemd-resolved
> >
> > To that end, the change proposal¹ when systemd-resolved was
> > enabled by
Todd Zullinger writes:
Kevin Fenzi wrote:
[...snip loads of useful information...]
> So, I think if you:
>
> disable systemd-resolved
To that end, the change proposal¹ when systemd-resolved was
enabled by default (F33) contains an example of how to
ensure the service remains disabled -- which w
Kevin Fenzi writes:
So, I think if you:
disable systemd-resolved
or
make /etc/resolv.conf a real file, not a link.
or
set 'DNSStubListener=no' in /etc/systemd/resolved.conf
It will not be replaced anymore.
I did not even /have/ systemd-resolved installed.
dnf system-upgrade installed it on
Kevin Fenzi wrote:
[...snip loads of useful information...]
> So, I think if you:
>
> disable systemd-resolved
To that end, the change proposal¹ when systemd-resolved was
enabled by default (F33) contains an example of how to
ensure the service remains disabled -- which would avoid the
situation
For whatever it's worth, the logic to replace or not replace
/etc/resolv.conf has gone through a bunch of adjustments, but currently,
as far as I can see it's:
if systemctl -q is-enabled systemd-resolved.service &>/dev/null &&
! systemd-analyze cat-config systemd/resolved.conf 2>/dev/null |
I have been getting the following SElinux alert:
SELinux is preventing key.dns_resolve from setattr access on the key
labeled kernel_t.
Is it safe to create a rule to ignore this? Known issue?
--
___
users mailing list -- users@lists.fedoraproject.org
T
Barry Scott writes:
> On 29 May 2024, at 23:49, Sam Varshavchik wrote:
>
> I updated from F39 to F40. I used to have:
>
> /etc/resolv.conf -> /run/NetworkManager/no-stub-resolv.conf
>
> Everything got messed up because the update hijacked this symlink again:
>
> lrwxrwxrwx. 1 root root 39 May
> On 29 May 2024, at 23:49, Sam Varshavchik wrote:
>
> I updated from F39 to F40. I used to have:
>
> /etc/resolv.conf -> /run/NetworkManager/no-stub-resolv.conf
>
> Everything got messed up because the update hijacked this symlink again:
>
> lrwxrwxrwx. 1 root root 39 May 29 09:44 /etc/reso
Jeffrey Walton writes:
On Wed, May 29, 2024 at 6:55 PM Sam Varshavchik
wrote:
>
> I updated from F39 to F40. I used to have:
>
> /etc/resolv.conf -> /run/NetworkManager/no-stub-resolv.conf
>
> Everything got messed up because the update hijacked this symlink again:
>
> lrwxrwxrwx. 1 root root
14 matches
Mail list logo