Re: loopback interface broken on current

On 01/04/13 09:45, Gary Jennejohn wrote:
> On Thu, 03 Jan 2013 20:30:18 +0900
> KAHO Toshikazu <vinwa_at_elam.kais.kyoto-u.ac.jp> 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