Except that my configuration files had already been changed during the Ontap
upgrade, obviously, as the machine wouldn't operate on the network after
rebooting, so I had no idea of knowing what else was messed up in the config
files. I had to operate on the assumption that everything was in an unknown
state, not just the network interface, so I got the basic configuration
reset quickly and then brought the system up and reviewed all the settings
afterwards, pulling some back out of snapshots and resetting others
manually.
Depending on how much of the configuration was lost, I might have also lost
the hosts file or name resolution or NIS configuration info, for example,
and ifconfig wouldn't have fixed that, and the filer wouldn't have known who
the admin host was, which would have simply sent me back to the console to
fix more stuff and left the system down longer.
In my experience, it's sometimes better to minimize downtime by trying a
solution that will quickly cover many potential problems rather than
investigate and repair one problem at a time. (Especially when you're
instructing someone else what to do over the phone, as I was in this recent
case from a couple thousand miles away.)
-----Original Message-----
From: Shuey, Chuck [mailto:cds@netapp.com]
Sent: Friday, July 20, 2001 11:45 AM
To: 'Mike Sphar'; 'toasters(a)mathworks.com'
Subject: RE: general filer gripe
The best solution is to run the ifconfig command manually from the console
to bring up an interface. Then, you can mount the root volume on your admin
host to edit the /vol/vol0/etc/rc file. This way, you don't have to redo
all of your configuration files that the setup script would otherwise
change.
Chuck Shuey
Professional Services Engineer
Network Appliance
-----Original Message-----
From: Mike Sphar [mailto:mikey@Remedy.COM]
Sent: Friday, July 20, 2001 7:41 AM
To: 'toasters(a)mathworks.com'
Subject: RE: general filer gripe
I've had similar situations where networking info was messed up after an
ontap upgrade, but it only hung for a few minutes before I got a login
prompt on the console, at which point I just logged in and re-ran "setup"
which prompts for all the networking info. Then after the networking was
fixed I restored some of my original settings (like the exports file) from
snapshots.
-----Original Message-----
From: Leonard, Roger [mailto:Roger.Leonard@marconi.com]
Sent: Friday, July 20, 2001 7:19 AM
To: 'toasters(a)mathworks.com'
Subject: general filer gripe
This is probably covered in NetApp 101 but never having taken the classes
(yet) I need something clarified.
Environment: Sun solaris with automounter and different flavors of filers
running ATM and LANE.
i mucked up the networking portion of the rc file and the filer was
essentially hung trying to export filesystems. it could not resolve the
addresses to these hosts because it could not get dns or nis or any name
resolution or even a default route for that matter. It hung while
complaining for over an hour. so i could not get in through my normal "cd
/net/filername/etc" my final recourse was to create boot floppies, boot
from them, selecting "boot without rc" bringing up networking with
ifconfigs and elconfigs, then going in through "cd /net/filername/etc" and
editing the rc file accordingly and rebooting. very slow and tedious.
My basic question is: was this the proper way to fix a screwed up rc?
boot floppy
manually config network
cd /net/filername/etc
edit rc
Or is there a way to edit the rc file from a terminal session? or any other
of the /etc files?
what is the quickest way to recover from this type of problem??
can i boot the filer kernel in single user mode without networking?
What is the best way to get around this problem in the future? Can i make
the exports fail and just come up to a prompt or do i have to boot floppy
everytime?
if i hardcoded my export hosts in the /etc/hosts would the filer come up
even without networking and NIS/DNS, etc?
thanks
Roger D. Leonard