I'm glad you identified the right package. It was difficult for me to figure out what actually initially creates /etc/hosts!
> What was in your /etc/hosts, if not this?
Exactly what you posted, except for the localhost entry in the ::1 line. This condition is common across two fresh installs here at home.
----
127.0.0.1 localhost
127.0.1.1 topol015
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
----
Also, hopefully helpful ...
- My installs were from the Live CD Gnome desktop Live User environment (I did not install from the CD without booting up the Gnome session first).
- My installs were on a SOHO LAN with an IPv4 router that was also the DNS server and was not responding to IPv6 DNS queries (in case netcfg or some other tool makes choices based on IPv6 reachability)
However,
- Dovel mentioned in https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/274995/comments/230 that neither his upgraded installation contained the correct /etc/hosts line, nor did his installation direct from CD. (His upgraded installation may have had a different audio configuration or some other factor, it did not experience the delay in 274995.)
(If I understand it correctly,) The bug in 274995 (a condition with a delay noticed by a large number of users) involves attempts to reach a user-session Pulseaudio daemon during /etc/init.d/alsa-tools stop. Of course, the daemon had shut down with the end of the user session, but the alsa-tools seemed oblivious to that and still treated them as part of the default audio system. To experience the delay, there had to be no IPv6 localhost in /etc/hosts AND ALSO no timely response to the resulting AAAA DNS queries for localhost. This is an indicator that the number of users without localhost for ipv6 in /etc/hosts may be quite high.
Hi Steve,
I'm glad you identified the right package. It was difficult for me to figure out what actually initially creates /etc/hosts!
> What was in your /etc/hosts, if not this?
Exactly what you posted, except for the localhost entry in the ::1 line. This condition is common across two fresh installs here at home.
----
127.0.0.1 localhost
127.0.1.1 topol015
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
----
Also, hopefully helpful ...
- My installs were from the Live CD Gnome desktop Live User environment (I did not install from the CD without booting up the Gnome session first).
- My installs were on a SOHO LAN with an IPv4 router that was also the DNS server and was not responding to IPv6 DNS queries (in case netcfg or some other tool makes choices based on IPv6 reachability)
However, /bugs.launchpad .net/ubuntu/ +source/ alsa-utils/ +bug/274995/ comments/ 230 that neither his upgraded installation contained the correct /etc/hosts line, nor did his installation direct from CD. (His upgraded installation may have had a different audio configuration or some other factor, it did not experience the delay in 274995.)
- Dovel mentioned in https:/
(If I understand it correctly,) The bug in 274995 (a condition with a delay noticed by a large number of users) involves attempts to reach a user-session Pulseaudio daemon during /etc/init. d/alsa- tools stop. Of course, the daemon had shut down with the end of the user session, but the alsa-tools seemed oblivious to that and still treated them as part of the default audio system. To experience the delay, there had to be no IPv6 localhost in /etc/hosts AND ALSO no timely response to the resulting AAAA DNS queries for localhost. This is an indicator that the number of users without localhost for ipv6 in /etc/hosts may be quite high.