My brother being somewhat of a nerd himself, went for the full monty. He broke out the Wireshark sniffer and made a log of all the traffic coming out and going to the FS. As far as he told me, the FS talks to the DHCP server and it does manage to configure its IP stack. In fact, he is able to ping the FS and get a reply back. Telnet to port 5000, however, does not work.
Btw, he tells me that the all the leds work just fine, i.e., the space usage ones at the bottom indicate the proper free space, and if he turns it on without any disks the first bay goes red, etc.
So I dug around the initialization scripts of the FS and noticed that all this initialization happens inside of /etc/init.d/rcS (abridged):
mount -t sysfs none /sys
mount -t tmpfs -o size=30M /dev/shm /dev/shm
if [ ! -f /var/samba/netbios.conf ]; then
if [ -f /var/log/nasd.log ]; then
/bin/cp /var/log/nasd.log /var/log/nasd.backup.log
/usr/bin/nasd &> /var/log/nasd.log &
From what I can tell, as soon as the FS starts booting Linux it tries to mount the diskpack (mount -a) and other auxiliary mount points (/sys, /dev/shm), then it mounts /var (enable_var), and then it reaches out to the DHCP server (net_config).
After that, the FS tries to update the time (ntp_config), adds some more network stuff (netplugd), sets a default netbios name if none exists (DroboShare? really?), makes a backup copy of nasd.log, and starts nasd.
So… his FS seems to be stuck somewhere between net_config and nasd. I can’t see what could possibly be preventing it from proceeding. Maybe it is because /var is full and the backup copy of nasd.log fails?
There is another possibility, but only someone from DRI engineering could answer. I know that x86 servers (when configured to netboot/PXE boot) reach out to the DHCP server twice during boot. The first time happens inside the BIOS, so that the server can try to netboot. The second time is during boot, where Linux will reconfigure the network cards from scratch.
In other words, this DHCP attempt that my brother is seeing could be coming not from the Linux OS, but from the bootloader of the FS. If that is the case, I wonder if it is trying to netboot… and if so, I wonder if I could give it an image of the boot and root sections of the flash memory (taken from a good FS) over TFTP so that it would boot far enough to do a firmware reflash…
@Sky: could you please check with your engineering guys to see if that is possible?