oem-config replaces /etc/resolv.conf symlink with a hard file

It looks like the oem-config network plugin calls netcfg, and one of the first things that does is unlink resolv.conf (reap_old_files()). Is there an alternative to netcfg when using oem-config?

I have tested this several times with different network settings and can see that ubiquity plays quite nicely with resolvconf. That includes static (e.g. dns-nameservers entries in /e/n/interfaces) and dhcp cases.

The only problem is the issue identified by Newton Liu above - the resolv.conf gets unlinked. Hence, the correct entries (as present in /run/resolvconf/resolv.conf) are invisible in the system.

Fix proposal for zesty.

The attachment "zesty_ubiquity_17.04.8.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

This patch can't be applied as-is; netcfg comes from the standalone package from the same name. Assuming we can fix this appropriately in netcfg itself without breaking debian-installer-based installs, this might work.

However, I suspect this can be appropriately handled directly in ubiquity.

Seems like the most sensible fix is in netcfg after all; we should apply the patch (minus the ubiquity bits), after properly testing that this doesn't break server installs with only d-i, and that it doesn't break non-OEM ubiquity installs.

This bug was fixed in the package netcfg - 1.138ubuntu5

---------------
netcfg (1.138ubuntu5) zesty; urgency=medium

  * Don't reap old resolv.conf if resolvconf is in use. Thanks Dariusz Gadomsky
    for the patch. (LP: #1646585)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 03 Apr 2017 13:45:53 -0400

NVIDIA confirmed the Zesty fix works for them. Would it be possible to backport to 16.04.

The ubiquity tasks should be Fix Released as well; ubiquity was updated before the zesty release, artful is unaffected (fixed because zesty was fixed before release).

I'm adding the tasks for Xenial by request from Stéphane.

Hello Newton, or anyone else affected,

Accepted netcfg into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netcfg/1.135ubuntu4.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Since we're hitting this during server install, and the netcfg executable used is the one in the ubiquity package, All we need to test this is the updated ubiquity package. I'm having trouble finding a pointer to that...

The latest ubiquity I see for xenial is 2.21.63, and its netcfg-common.c looks unfixed:

void reap_old_files (void)
{
    static char* remove[] =
        { INTERFACES_FILE, HOSTS_FILE, HOSTNAME_FILE, NETWORKS_FILE,
          RESOLV_FILE, DHCLIENT_CONF, DOMAIN_FILE, 0 };
    char **ptr = remove;

    while (*ptr)
        unlink(*ptr++);
}

Indeed, ubiquity has not been updated yet, because we should be able to verify netcfg without it. Nevertheless, I have another SRU to land that also needs to be applied to xenial, so I'll upload ubiquity along as soon as netcfg lands in xenial-proposed.

Hello Newton, or anyone else affected,

Accepted netcfg into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netcfg/1.138ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

Hello Newton, or anyone else affected,

Accepted netcfg into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netcfg/1.135ubuntu4.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Verification-done for xenial, using netcfg 1.135ubuntu4.5:

I approximated the behavior of oem-config on a system after install calling netcfg; it appears to properly handle the resolv.conf symlink on the system.

The current issue is that ubiquity does NOT use the netcfg package, but rather has its own copy of netcfg that still (as near as I can tell) has the bug. Is there another bug tracking that? What is the timeframe for that getting fixed in xenial?

This bug was fixed in the package netcfg - 1.135ubuntu4.5

---------------
netcfg (1.135ubuntu4.5) xenial; urgency=medium

  * Add description for non-PCI platform network interfaces. LP: #1697914

 -- dann frazier <email address hidden> Wed, 19 Jul 2017 15:15:12 -0600

Hello Newton, or anyone else affected,

Accepted ubiquity into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/2.21.63.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Verification-done for xenial with ubiquity 2.21.63.4:

I verified that the resolv.conf file after running OEM mode is correctly left around as a symlink to resolvconf.

The verification of the Stable Release Update for ubiquity has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package ubiquity - 2.21.63.4

---------------
ubiquity (2.21.63.4) xenial; urgency=medium

  * src/panel/panel.c: set stricter size/extend rules for the panel so that it
    looks nicer if its scaling is too great. (LP: #1622686)
  * Automatic update of included source packages: console-setup
    1.108ubuntu15.3, flash-kernel 3.0~rc.4ubuntu62.2, grub-installer
    1.128ubuntu5.1, hw-detect 1.117ubuntu2.1, netcfg 1.135ubuntu4.5,
    partman-auto 134ubuntu1.1, partman-btrfs 18ubuntu1.1, partman-
    partitioning 110ubuntu4.1, preseed 1.71ubuntu1.1, hw-detect
    1.117ubuntu2.2. (LP: #1646585)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 24 Jul 2017 11:36:37 -0400

This has broken again in bionic. While the fix is still in there, the netcfg-common.c file that ubiquity uses does NOT handle the systemd-resolve.service case, where the symlink is to ../run/systemd/resolv/stub-resolv.conf, and so running ubiquity during oem-config-firstboot again breaks the system.