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
> 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
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
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
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 |
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
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
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
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
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 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 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 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
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
14 matches
Mail list logo