before update:
cat /etc/resolv.conf 
# Generated by NetworkManager
search fritz.box
nameserver 192.168.178.1

after install of resolvconf:
cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Thank you for this important report.

Unclear who might deal with this, so assigning the bug globally.

Summary: resolvconf: nameserver unset after update => resolvconf: nameserver unset after M8-M9 upgrade. Stops the upgrade process.
Assignee: bugsquad => pkg-bugs

since this has sth. to do with networkmanager, we should add wally

The problem comes from
%posttrans
%_post_service %{name}

in resolvconf. I would say this should be removed, as the regeneration of this information in combination with networkmanager or systemd-network causes more trouble than it solves. On update this will not generate more information as it had before, and is at least updated after reboot. So I guess we are making more trouble be keeping this. (btw I guess the mga3 patch can savely be removed)

CC: (none) => jani.valimaa

still an issue. Every udpate stops during install, if network-manager is installed.

Increasing the priority. This is a release blocker for the beta 2 iso images.

CC: (none) => davidwhodgins
Priority: Normal => release_blocker

resolvconf is no longer required by anything and is not installed by default on fresh installs. Is it still needed?

CC: (none) => mageia

(In reply to Dave Hodgins from comment #5)
> Increasing the priority. This is a release blocker for the beta 2 iso images.

sorry but no way this this can be a blocker for beta isos, it's way out of scope for that... 

its not a default setup and  not something that gets triggered when using the isos,  only during online updates with urpmi or dnf

Blocker for rc iso images then. How are we going to handle it during upgrades?

(In reply to Dave Hodgins from comment #8)
> Blocker for rc iso images then.

ACK.

> How are we going to handle it during upgrades?

I saw papoteur "fixed" it by dropping the posttrans, which basically broke the 
resolvconf package instead...

I guess a better fix would be to make resolvconf service smarter by making it check if it's "in charge" of maintaining /etc/resolv.conf and only then trigger the update

Maybe a sufficient fix is adding somewhere at the top of /etc/resolvconf/update.d/libc   :

if [ -L ${ETC}/resolv.conf ] && [ "$(readlink ${ETC}/resolv.conf)" != "$DYNAMICRSLVCNFFILE" ]; then
  exit 0
fi


Then if *something else* is managing /etc/resolv.conf, resolvconf won't do anything, while it can still replace a regular file with its symbolic link. Presumably networkmanager also makes /etc/resolv.conf a symbolic link, like resolvconf and systemd-resolved.

CC: (none) => cjw

(In reply to Dave Hodgins from comment #8)
> Blocker for rc iso images then. How are we going to handle it during
> upgrades?

resolvconf is not on any of the Mageia 9 ISOs, so not a blocker for the ISOs.

(In reply to Martin Whitaker from comment #11)
> (In reply to Dave Hodgins from comment #8)
> > Blocker for rc iso images then. How are we going to handle it during
> > upgrades?
> 
> resolvconf is not on any of the Mageia 9 ISOs, so not a blocker for the ISOs.


yeah, its meant more as a "need to be fixed before RC relase time" as thats when early adopters already do distro upgrades on production systems

should resolv.conf get obsoleted? I think it was used for networkscripts in earlier mga releases, so it is present on older installs.

And I think we can be proud of the fact, mga does not need reinstalls after a few years as it can be updated for years. Most of my installs are upgrades from old mandriva and still running good.

I have not used resolvconf in year.

Perhaps we should study dropping resolconf and the default setting for rc-manager in networkmanager. At the moment it's 'resolvconf'

man NetworkManager.conf

       rc-manager
           Set the resolv.conf management mode. This option is about how NetworkManager writes to /etc/resolv.conf, if at all. The default value depends on
           NetworkManager build options, and this version of NetworkManager was build with a default of "resolvconf". Regardless of this setting,
           NetworkManager will always write its version of resolv.conf to its runtime state directory as /run/NetworkManager/resolv.conf.

           If you configure dns=none or make /etc/resolv.conf immutable with chattr +i, NetworkManager will ignore this setting and always choose unmanaged
           (below).

           auto: if systemd-resolved plugin is configured via the dns setting or if it gets detected as main DNS plugin, NetworkManager will update
           systemd-resolved without touching /etc/resolv.conf. Alternatively, if resolvconf or netconfig are enabled at compile time and the respective binary
           is found, NetworkManager will automatically use it. Note that if you install or uninstall these binaries, you need to reload the rc-manager setting
           with SIGHUP or systemctl reload NetworkManager. As last fallback it uses the symlink option (see next).

           symlink: If /etc/resolv.conf is a regular file or does not exist, NetworkManager will write the file directly. If /etc/resolv.conf is instead a
           symlink, NetworkManager will leave it alone. Unless the symlink points to the internal file /run/NetworkManager/resolv.conf, in which case the
           symlink will be updated to emit an inotify notification. This allows the user to conveniently instruct NetworkManager not to manage
           /etc/resolv.conf by replacing it with a symlink.

           file: NetworkManager will write /etc/resolv.conf as regular file. If it finds a symlink to an existing target, it will follow the symlink and
           update the target instead. In no case will an existing symlink be replaced by a file. Note that older versions of NetworkManager behaved
           differently and would replace dangling symlinks with a plain file.

           resolvconf: NetworkManager will run resolvconf to update the DNS configuration.

           netconfig: NetworkManager will run netconfig to update the DNS configuration.

           unmanaged: don't touch /etc/resolv.conf.

           none: deprecated alias for symlink.

Switched an m8 i586 vb guest from drakx-net to NetworkManager, and then upgraded
to m9 using mgaapplet. Upgrade log ends with
"Installation finished. No error reported."

Closing as fixed.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

So nothing for errata it seems to me.

If wrong, set back and explain :)

CC: (none) => fri
Keywords: FOR_ERRATA9 => (none)