oem-config incorrectly setting up /etc/hosts

[Mario Limonciello]

Binary package hint: ubiquity

This was an OEM preseeded installation using the preseed located at http://linux.dell.com/git/?p=ubuntu-fid.git;a=blob;f=framework/preseed/dell.seed;h=48677d853e9f0dc37dee95329f54f0a771531ea5;hb=HEAD

and the Ubuntu 9.10 gold DVD. For the user name in OEM config, it was selected to be "test".

test@test-laptop:~$ sudo ifconfig eth0 down
sudo: unable to resolve host test-laptop

[Mario Limonciello (superm1)]

It looks like /etc/hosts was badly created, here it is.

[Mario Limonciello (superm1)]

/etc/hostname is set to a hostname that was different than the preseed too.

[Mario Limonciello (superm1)]

apport-collect doesn't seem to want to work.

[Mario Limonciello (superm1)]

It appears that if you check /etc/hosts and /etc/hostname before running through OEM config, it's properly set up.

[Jerone Young (jerone)]

This bug is a critical bug as system does not function properly after oem-config is run the /etc/hosts file is completely no correct (see coment #2).

[Robbie Williamson (robbiew)]

Assigning to Evan, but he's having some internet connection issues today, so I will also subscribe Colin.

[Colin Watson (cjwatson)]

Jerone, the oem-config package has been merged into ubiquity. It is no longer correct to assign bugs to oem-config. I've adjusted the bug status appropriately.

[Colin Watson (cjwatson)]

(I'm on-site this week, so if I get to this bug I'll consider it a bonus, but can't guarantee it ...)

[Mario Limonciello (superm1)]

So two things worth mentioning:

1) This can't be reproduced 100% of the time, but when it does happen, the results on the system are disastrous.

2) That /etc/hosts bares an uncanny similarity to the one that NetworkManager would normally generate if it encountered an empty /etc/hosts. So there looks to be two bugs at play.
  a) There looks to be a bug with that in that no new lines are spit out by Network Manager
  b) If Network Manager calls update_etc_hosts at the exact same time that oem-config was changing the hostname, you can run into this scenario. OEM-config shouldn't be changing the hostname at all in the first place though as there is no place in the UI to set it.

here's a snippet from src/NetworkManagerPolicy.c:

        /* Hmm, /etc/hosts was empty for some reason */
        if (!added) {
                g_string_append (new_contents, "# Do not remove the following line, or various programs");
                g_string_append (new_contents, "# that require network functionality will fail.");
                g_string_append (new_contents, "127.0.0.1\t" FALLBACK_HOSTNAME "\tlocalhost");
        }

        error = NULL;
        if (!g_file_set_contents (SYSCONFDIR "/hosts", new_contents->str, -1, &error)) {
                nm_warning ("%s: couldn't update " SYSCONFDIR "/hosts: (%d) %s",
                            __func__, error ? error->code : 0,
                            (error && error->message) ? error->message : "(unknown)");
                if (error)
                        g_error_free (error);
        } else
                success = TRUE;

        g_string_free (new_contents, TRUE);
        return success;

[Martin Pitt (pitti)]

Accepted ubiquity into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.1.0

---------------
ubiquity (2.1.0) lucid; urgency=low

  [ Evan Dandrea ]
  * Run X with -nolisten tcp (LP: #462394).
  * Make sure we never try to install onto the live filesystem.
  * Only print the filenames being blacklisted if in debug mode.
  * Provide human readable sizes in the partitions-too-small warning
    (LP: #298974).
  * Mark the "Installation Complete" window as always on top
    (LP: #462178).
  * Fixes from Pychecker for the KDE frontend (kde_ui):
    - Don't import datetime or math. The timezone code is in a separate
      module now.
    - Remove some unused variables.
    - Don't assign to a variable that's going to be immediately discarded.
  * Signal to GTK+ when using a right-to-left language, so that it
    composes the interface from right to left (LP: #222845).
  * Signal to the slideshow when the installer is using a right-to-left
    language (LP: #446989).
  * Set SUDO_UID and SUDO_GID in ubiquity-dm so ubiquity knows what user
    to drop privileges to (LP: #422254).
  * Do not try to configure networking in oem-config (LP: #471498).
  * Make migration-assistant import failures non-fatal to the overall
    install.
  * pkgsel now provides a debconf question to avoid warning the end user
    when the language packs could not be installed (LP: #471553).
  * Make sure a device exists as part of the grub target device
    validation.
  * Allow the user to retry grub installation with a different device on
    failure.
  * Automatic update of included source packages: apt-setup
    1:0.42ubuntu1, choose-mirror 2.29ubuntu2, clock-setup 0.100ubuntu1,
    debian-installer-utils 1.71ubuntu1, grub-installer 1.47ubuntu1, hw-
    detect 1.73ubuntu1, netcfg 1.51ubuntu1, partman-base 135ubuntu1,
    tzsetup 1:0.26ubuntu1, user-setup 1.28ubuntu1.

  [ Colin Watson ]
  * Add a debian/rules target to run pychecker. I've fixed several warnings,
    but there are still several left so this is not yet enabled by default.
  * Fix debconf frontend:
    - Start oem-config on stopping rc, as well as when starting display
      managers.
    - Add some missing imports (ubiquity.frontend.base.Controller,
      ubiquity.plugin.Plugin, ubiquity.i18n, signal,
      ubiquity.components.install).
    - If there's a containing debconf frontend, talk to it rather than using
      debconf-communicator.
    - Set a controller in the language plugin.
    - Use spaces rather than ${!TAB} in localechooser when using the debconf
      frontend, since debconf doesn't support the latter yet.
    - Don't handle user-setup preseeding for the debconf frontend.
    - Remove unused progress_position handling.
    - Fix exception names in ubi-network and ubi-tasks.
  * Require Python 2.5, so we can now use hashlib rather than md5 and avoid
    a slew of warnings.
  * Add an intro message noting that we're alpha again.
 -- Evan Dandrea <email address hidden> Fri, 13 Nov 2009 10:41:42 +0000

[Jerone Young (jerone)]

Apparently there is still an issue with Network Manger here. Mario comments on it in comment #9.

Martin you marked it Invalid, do you have a reason? Please, if so remark this invalid. Though I am going to reopen this issue for Network Manger as chatting with Mario we only solved the ubiquity/oem-config side of the issue and can still happen as it is a race condition.

[Robbie Williamson (robbiew)]

subscribed desktop manager for awareness of possible NetworkManager issue.

[Brian Murray (brian-murray)]

Mario you mentioned the following in comment 9:

"b) If Network Manager calls update_etc_hosts at the exact same time that oem-config was changing the hostname, you can run into this scenario. OEM-config shouldn't be changing the hostname at all in the first place though as there is no place in the UI to set it."

and the changelog indicates:

"* Do not try to configure networking in oem-config (LP: #471498)."

Shouldn't the fix in ubiquity avoid this particular situation? Has anybody tested with the version of ubiquity in lucid or karmic-proposed?

[Mario Limonciello (superm1)]

Yes, I've tested the one from proposed, and the ubiquity side of the
bug does not show up in the tests I've ran.

On 11/30/2009, Brian Murray <email address hidden> wrote:
> Mario you mentioned the following in comment 9:
>
> "b) If Network Manager calls update_etc_hosts at the exact same time
> that oem-config was changing the hostname, you can run into this
> scenario. OEM-config shouldn't be changing the hostname at all in the
> first place though as there is no place in the UI to set it."
>
> and the changelog indicates:
>
> "* Do not try to configure networking in oem-config (LP: #471498)."
>
> Shouldn't the fix in ubiquity avoid this particular situation? Has
> anybody tested with the version of ubiquity in lucid or karmic-proposed?
>
> --
> oem-config incorrectly setting up /etc/hosts
> https://bugs.launchpad.net/bugs/471498
> You received this bug notification because you are a member of Ubuntu
> Installer Team, which is subscribed to ubiquity in ubuntu.
>

--
Sent from my mobile device

Mario Limonciello
<email address hidden>

[Jerone Young (jerone)]

For the network manager side of this bug. According to Mario

"If you replace /etc/hosts with a zero length file (as some editors may do in the process of saving), there is a chance you'll hit this, but it's still not guaranteed. You don't need to duplicate it to fix it. You just need to modify NM code to write out a proper /etc/hosts."

So the issue with Network Manger is it is not filling out /etc/hosts with proper content if it sees that it has no content.

[Rick Spencer (rick-rickspencer3)]

First the network manager bug task is is New and not assigned to anyone. This suggests the bug task will not be addressed. We shouldn't leave bug tasks in this state if a customer cares about them.

Secondly, we should not commit to fix bugs without repro steps. If the network manager is buggy, please define the steps to reproduce the bug (zeroing out the /etc/hosts file is a fine repro step).

I'll set to incomplete and assign to Jerone for now. If someone can define repro steps, please set it as confirmed and assign to canonical-desktop-team.

Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.0.9

---------------
ubiquity (2.0.9) karmic-proposed; urgency=low

  * Do not try to configure networking in oem-config (LP: #471498).
  * pkgsel now provides a debconf question to avoid warning the end user
    when the language packs could not be installed (LP: #471553).
 -- Evan Dandrea <email address hidden> Thu, 12 Nov 2009 15:00:43 +0000

[Jerone Young (jerone)]

@Rick
         Apparently it's not as easy to reproduce but the code is in Network Manager that is producing an invalid /etc/hosts . Will find code path (post it) and hopefully an easy way to trigger it. Apparently the steps above where not enough.

[Jerone Young (jerone)]

In the Network Manager source code in

src/NetworkManagerPolicy.c

The issue is in function "update_etc_hosts". If Network Manager sees that /etc/hosts is empty it puts an invalid /etc/hosts .. it's on line 318 of the network manager in karmic (0.8).

When this gets run I'm trying to figure out. But this is where Network Manger is generating the invalid /etc/hosts file

[Jerone Young (jerone)]

I was actually able to reproduce the issue of Network Manger putting a bad /etc/hosts using Fedora with the following steps:
     - remove hostname set from /etc/sysconfig/network
     - remove all contents of /etc/hosts
     - reboot
     - Network manager puts invalid /etc/hosts

So to get into this situation isn't easy. Though if you are installing from a preseed file may actually have this case for Ubuntu.

I also submitted fixes for the invalid file upstream. Though following these steps on Ubuntu doesn't seem to lead to the results that where hit. Will have to try again.

[Jerone Young (jerone)]

It looks like with the new ubiquity it is now unlikely we will get in a state where Network Manger will try and fall back. But basically if the hostname isn't set & nothing is in /etc/hosts. Network Manger tries to create it's own /etc/hosts

Trying this with an Ubuntu install I'm unable to recreate the situation even removing contents of both /etc/hostname & /etc hosts , as well as /etc/init/hostname.conf (so no hostname is set).

I will check back with Mario and see if we can carefully walk through the install. As long as /etc/hostname & /etc/hosts are created before Network Manager is started .. should never see the situation with network manager creating a fall back (bad) /etc/hosts file.

[Jerone Young (jerone)]

Talking this issue over a bit with Mario and running though the process . It is highly unlikely we will be able to run into this issue with network manager given the oem-config fix, as well as the inability to have network manager demonstrate the behavior hacking up an Ubuntu install.

With the fall back fix making it's way upstream, we will have it for the Lucid time frame which is acceptable.

Given this can now completely close this bug out.