On 03/11/14 12:23 PM, Gary Dale wrote:
After the last upgrade (kernel 3.2.0-4-amd64 and wget), I have a
Debian/Wheezy server that isn't starting. It gets to the network then
stops.
The system isn't hung - it will still output messages to the screen
when I plug and unplug USB devices, and I can use the SysRq key to do
the reisub bit and see the messages from the various commands.
When I boot to rescue mode, I get to the same point but it shows more
network messages that seem to show the eth0 link is up, but it
doesn't get beyond that.
I can boot from sysrescuecd and everything works. And I can run the
system in chroot and start the services I need for it do its job
temporarily (bind, samba, cups) but I can't ssh to it. This is a pain
because the server is remote (35 minutes away) so I can only work on
it in person. And in person I have to steal a keyboard and monitor
from another machine.
Anyway, within the chroot I can view the various system logs but they
don't show much. They show me (remotely) rebooting the server after
the kernel upgrade then nothing until I chroot into it from
sysrescuecd. Dmesg is similarly absent. The dmesg log is from the
previous time I rebooted.
The onscreen messages during a boot showed the system failing to load
the firmware for the Realtek NIC (8111E) but installing the realtek
firmware package didn't help - it just fixed the error message.
The system is an ASUS M5A88-M mainboard with an AMD Fx4100 processor.
It has a 3-disk mdadm RAID array setup as a RAID-1 /dev/md0 boot
partition and RAID-5 /dev/md1p1 as root and /dev/md1p2 as /home.
Does anyone have any ideas on how I can track down and/or fix this
problem?
Update: booting using sysrescuecd, I removed the
/etc/rcS.d/S13networking link and rebooted into single-user mode. It
completed OK, so I then ran /etc/init.d/networking start, which
exhibited the same problems it did when run by init. However this time
I was able to kill the process, at which point I noted the network had
been started. Exiting from the single-user mode allowed the boot to
continue to a normal command prompt.
This still leaves me with the problem of not being able to reboot the
computer remotely, since the workaround involves disabling the network.
dmesg shows the following from the last boot:
[ 181.805309] r8169 0000:03:00.0: firmware: agent loaded
rtl_nic/rtl8168e-3.fw into memory
[ 181.917202] r8169 0000:03:00.0: eth0: link down
[ 181.920948] r8169 0000:03:00.0: eth0: link down
[ 181.928316] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 184.284849] r8169 0000:03:00.0: eth0: link up
[ 184.292178] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 195.016023] eth0: no IPv6 routers present
The eth0: link becomes ready line is the last line I get on the screen
when I boot into single-user mode with networking enabled.
The previous dmesg.0 log from two months ago shows instead:
[ 10.391548] r8169 0000:03:00.0: firmware: agent aborted loading
rtl_nic/rtl8168e-3.fw (not found?)
[ 10.391740] r8169 0000:03:00.0: eth0: unable to load firmware patch
rtl_nic/rtl8168e-3.fw (-2)
[ 10.405264] r8169 0000:03:00.0: eth0: link down
[ 10.405333] r8169 0000:03:00.0: eth0: link down
[ 10.408540] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 11.061379] RPC: Registered named UNIX socket transport module.
The first (firmware) message change reflects the installation of the
firmware-realtek package in an effort to fix the problem.
I'm guessing that the change is that networking is now bringing the
link up because I switched to a static IP address, whereas previously
it was brought up by dchp (with the router assigning an IP address
using its internal dhcp server).
This is my /etc/network/interfaces file:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.17
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
Should it have something about IPv6 in it (or at least somewhere)? Or
is there some other error?