From owner-freebsd-current@FreeBSD.ORG Wed Jan 9 08:56:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCDF1985; Wed, 9 Jan 2013 08:56:07 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 766E7AA2; Wed, 9 Jan 2013 08:56:06 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TsrS8-002KcJ-05>; Wed, 09 Jan 2013 09:56:04 +0100 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TsrS7-0022j4-Ug>; Wed, 09 Jan 2013 09:56:03 +0100 Message-ID: <50ED30B9.7040101@zedat.fu-berlin.de> Date: Wed, 09 Jan 2013 09:56:25 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: gljennjohn@googlemail.com Subject: Re: loopback interface broken on current References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> <20130104094532.4a921e47@ernst.jennejohn.org> In-Reply-To: <20130104094532.4a921e47@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 08:56:08 -0000 On 01/04/13 09:45, Gary Jennejohn wrote: > On Thu, 03 Jan 2013 20:30:18 +0900 > KAHO Toshikazu wrote: > >> Hello, >> >>> There is still ====>ifa_del_loopback_route: deletion failed: 3 >>> that wasn't there before,but the 127.0.0.1 seems to be configured now: >> >> Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf? >> If you have it, try to remove it. >> >> I think something broken, but people using automatic configuration >> don't notice the breakage. >> > > Something is definitely broken because I don't have network_interfaces > in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned. > Same here. The OS: FreeBSD 10.0-CURRENT/amd64 r245218. Since I have three boxes running approximately the same configurations (I share my configs between lab and home), but different hardware, I'm confused. The symptoms in my case are: Booting the box is all right until it comes to the start of nfsuserd. Prior to that, ntp adjusts the clock properly with an external time server - so this implies network connectivity. Start of nfsuserd is stuck forever. Interrupting the start of nfsuserd restarts several other services, but winbindd and slapd (OpenLDAP) get stuck again. In case I also interrupt them, there are other services which will not start. Trying to login as root on the console fails - I never get a password tag after having issued the root login name. Since this machine is bound to a local and remote OpenLDAP backend, I'm used to have an emergency local user which usually works - but this time, neither root nor this user can login! Bringing up the box in SINGLEUSER allows me to login. Investigating the network interfaces with ifconfig reveals, that the loopback did not get assigned to any inet 127.0.0.1 address. Sometimes there is only inet6 linklocal address, some nd6 options, but sometimes even IPv6 assignments do not show up. In a desperate move I tried to recompile a kernel. In /etc/src.conf, I recompile also the kernel module for the most recent virtual-box kernel module. While the kernel and module (*.ko) get installed properly, the recompilation of the VirtualBox port gets stuck when the system unfolds the source tarball. Hitting Ctrl-T say "sbwait" for the process. Other processes seem to have trouble getting a proper ownership or UID for a file - this is my naiv interpretation what I see at the surface. The funny thing is, that after several reboots, the box gets up as normal. I revealed this issue approx. two weeks ago when out of the sudden the amd automounter stopped working and the NFSv4 network drives didn't attach properly and made the whole box being stuck. Sorry for the more superficial description of the problem ... Has the problem been identified? Is there a solution? Since it affects only my very modern hardware (i7-3930, 32GB RAM, ASUS P9X79 WS mainboard), while a very same setup on older hardware (our local server is Intel Q6600 with 8GB RAM and and oldish Intel P45-chipset based mainboard), both systems do have Intel NICs, I'm a bit confused. Regards, Oliver