On update of mag8 -> mga9 after updating this package urpmi stopped downloading, since nameserver was not known anymore. Replugging network resolved the problem, but doing this on a remote machine will give u BIG trouble
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.
Assignee: bugsquad => pkg-bugsSummary: resolvconf: nameserver unset after update => resolvconf: nameserver unset after M8-M9 upgrade. Stops the upgrade process.
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.
Keywords: (none) => IN_ERRATA9
Keywords: IN_ERRATA9 => FOR_ERRATA9
Increasing the priority. This is a release blocker for the beta 2 iso images.
Priority: Normal => release_blockerCC: (none) => davidwhodgins
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.
Status: NEW => RESOLVEDResolution: (none) => FIXED