2011-04-13 10:33 AM
I have a FAS2040 with two filers working with firmware v8.0.1. I have an issue with both filers when I try to read autosupport options values. Here is an example :
option autosupport.content: can not be read, connection problem (code=0xffffffff)
autosupport.content unknown (value might be overwritten in takeover)
Moreover, the "options autosupport" command takes a lot of time to try reading each value (timeout occurs after 20-30sec per option approximatively). I did not success to troubleshoot this. I got this problem since I flashed the filers with Ontap v8.0.1 and migrated them to another subnet. I ensured to set the correct gateway ip address.
My troubleshooting helped me to discover when each "losk" interface is disabled or set with another IP address than 127.0.20.1, the problem is still the same except I did not experience the long timeout. But it seems obvious since both filers are communicating through each internal "losk" interface...
Thanks beforehand for your help.
Solved! SEE THE SOLUTION
2011-04-13 11:39 PM
Thanks for your answer.
Indeed, I already tried to reboot the filer.
I get the following...
NetApp Release 8.0.1 7-Mode: Wed Jan 5 17:24:41 PST 2011
...*> version -b
/cfcard/x86/freebsd/image1/kernel: OS 8.0.1
/cfcard/backup/x86_elf/kernel/primary.krn: OS 7.3.2
/cfcard/x86_elf/firmware/deux/firmware.img: Firmware 3.1.0
/cfcard/x86_elf/firmware/SB_XIV/firmware.img: BIOS/NABL Firmware 3.0
/cfcard/x86_elf/firmware/SB_XIV/bmc.img: BMC Firmware 1.3
/cfcard/x86_elf/firmware/SB_XVII/firmware.img: BIOS/NABL Firmware 6.1
/cfcard/x86_elf/firmware/SB_XVII/bmc.img: BMC Firmware 1.3
/cfcard/common/firmware/zdi/zdi_fw.zpk: PAM II Firmware 1.10 (Build 0x201012200653)
/cfcard/common/firmware/zdi/zdi_fw.zpk: X1936A FPGA Configuration PROM 1.0 (Build 0x200706131558)
2011-04-14 11:04 AM
Not seeing any issues, as the booted kernel and Primary kernel in the flash both are 8.0.1.
Please verify for any configuration errors reported on sysconfig -c / messages file.
May be you can try reinstalling ONTAP download any latest patch release of 8.0.1 and try updating the system files.
Also on the loader prompt you have the option to reset the system parameters to default just incase any thing worng there.
Also if this system is not a production system yet and you have the option,
From the special boot menu you have a option to erase all disks and and build a flexible root file system ( make sure you unplug all the disks except the root disks before you do this!!!)
to get a clean system.
2011-04-22 02:31 PM
I had this take one of our 3240s last weekend.
autosupport options couldn't be read from the registry, a reboot made the ntp settings go away.
Multiple hours with support finally led us to the rc files.
Deleting the entry for the losk interface and rebooting cleared everything up.
I was told it's a bug that they didn't have a clear understanding as to the cause.
Our other 3240s didn't have an entry for the losk interface and didn't have this problem.
Eveyrhing was good after the reboot.
2011-04-25 11:23 AM
Thanks for this tip. I'm actually dealing with the support regarding this issue. I will report this similar experience to the support. This could be helpful.
Of course, I keep this topic updated...
2011-04-30 07:26 AM
Add me to the list. Seeing same problem with 8.0.1P2 on a FAS3210. Timezone, autosupport, and some other info is lost on reboot. The config otherwise fully checks out.Have invested hours in trying to root cause but no luck. Not sure of the "loskness monster" is part to blame.
2011-04-30 07:38 AM
This is likely either one or both of these environment options set..not an ONTAP issue, but firmware loader environment variables set. You can check from the loader prompt with "printenv" or if you enable the diag account in 7mode and run "kenv" from the bsd prompt
These were coming pre-set for a while on some shipments a few months ago...but is now fixed...but sounds like you got one of those systems.
For a short while systems shipped with one or both options set. Whenever there is a reboot or cluster takeover/giveback then these options are reset or the system reruns the setup script. You can unsetenv/setenv to remove or change the value, but "set-defaults" and "bye" is a guaranteed way to get to factory defaults... just check your onboard FC ports to see if initiator or target and confirm if still initiator or target from maintenance mode prior to booting into production again. You could do a cf takeover and cf giveback to get to loader to minimize downtime.
I am almost positive this is your issue as it fits exactly and has caused some fits...it only occurred on a small number of systems before we started reporting on it an manufacturing fixed the root cause... support should be well aware of it when you call in to also guide you through the internal TSB on this issue.
2011-04-30 07:56 AM
Scott - Wow, thanks! Yea, on boot we get the following message -
Starting AUTOBOOT press Ctrl-C to abort...
Loading X86_64/freebsd/image1/kernel:0x100000/3386728 0x53b000/3222096 0x84da50/1190096 Entry at 0x80148250
Loading X86_64/freebsd/image1/platform.ko:0x971000/546300 0xa99e60/514368 0x9f6600/17192 0xb177a0/29592 0x9fa928/1272 0xb1eb38/3816 0x9fae20/52267 0xa07a50/69035 0xa18800/1464 0xb1fa20/4392 0xa18db8/248 0xb20b48/744 0xa18eb0/968 0xb20e30/2904 0xa19278/128 0xb21988/384 0xa19300/130208 0xb21b08/138192 0xa38fa0/425 0xa5d500/8307 0xa99d73/237 0xa5f578/122208 0xa7d2d8/117403
Starting program at 0x80148250
NetApp Data ONTAP 8.0.1P2 7-Mode
Copyright (C) 1992-2010 NetApp.
All rights reserved.
* Press Ctrl-C for Boot Menu. *
Wipe filer procedure requested.
Chelsio T3 RDMA Driver - version 0.1
Ipspace "iwarp-ipspace" created
That line "wipe filer procedure requested" was distrubing to say the least. But I wasnt convinced the filer was being fuly wiped. Virtual interface settings remained, the /etc/rc was still there, hostnames info, IP info, etc etc.... Not one hit on Google or NOW for that string (now thats changed!). After the reboot, we did not actually have to run through setup, but yes some "setup-like" actions were definitely present with all of the config info being reset. Continuously losing the timezone was a serious problem itself, resulting in authentication issues.
I will read up more on those options, and update the NetApp community with the results. I will not be able to access my client until next week.
Thank you so much.