Jeffrey Walton writes:
On Mon, Jun 3, 2024 at 6:42 AM Sam Varshavchik wrote:
>
> Tim via users writes:
>
> > Tim:
> > >> Is Anaconda more than just the OS installer, now? Is it needed post-
> > >> install?
> >
> > Kevin Fenzi:
> > > No, it's not needed. It's somewhat of a historical artifact o
On Mon, Jun 3, 2024 at 6:42 AM Sam Varshavchik wrote:
>
> Tim via users writes:
>
> > Tim:
> > >> Is Anaconda more than just the OS installer, now? Is it needed post-
> > >> install?
> >
> > Kevin Fenzi:
> > > No, it's not needed. It's somewhat of a historical artifact of the way
> > > some insta
Tim via users writes:
Tim:
>> Is Anaconda more than just the OS installer, now? Is it needed post-
>> install?
Kevin Fenzi:
> No, it's not needed. It's somewhat of a historical artifact of the way
> some installs work that it's there. There was some talk about it
> removing itself at the end,
Tim:
>> Is Anaconda more than just the OS installer, now? Is it needed post-
>> install?
Kevin Fenzi:
> No, it's not needed. It's somewhat of a historical artifact of the way
> some installs work that it's there. There was some talk about it
> removing itself at the end, but I am not sure where t
On Sat, Jun 01, 2024 at 06:07:24AM GMT, Tim via users wrote:
> On Fri, 2024-05-31 at 08:53 -0700, Kevin Fenzi wrote:
> > Interesting. So, the only thing I see that requires systemd-resolved
> > is anaconda-core. However, systemd itself has a 'recommends' for it,
> > so perhaps thats what pulled it
On Fri, 2024-05-31 at 08:53 -0700, Kevin Fenzi wrote:
> Interesting. So, the only thing I see that requires systemd-resolved
> is anaconda-core. However, systemd itself has a 'recommends' for it,
> so perhaps thats what pulled it back in?
>
> So, possibly keeping it installed, but masked is a bett
Sam Varshavchik composed on 2024-05-31 12:13 (UTC-0400):
> Masking is just solving the X of an XY problem. Either the dependencies
> being masked are not needed, or if they are needed masking would break
> something.
I like KISS:
# inxi -Sz
System:
Kernel: 6.8.11-300.fc40.x86_64 arch: x86_
Kevin Fenzi writes:
On Thu, May 30, 2024 at 04:25:44PM GMT, Sam Varshavchik wrote:
> 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
> >
> >
On Thu, May 30, 2024 at 04:25:44PM GMT, Sam Varshavchik wrote:
> 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 repla
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 |
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
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 39 May 29 09:44 /etc/resolv
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/resolv.conf ->
../run/systemd/resolve/stub-resolv.conf
I was confident t
24 matches
Mail list logo
