"autosupport options" issue

[seginetapp]

Hello,

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...

Any ideas?

Thanks beforehand for your help.

[baijulal]

Hope you had rebooted the filer and tried.

Please verify current version and version on the boot flash by version and version -b o/p.

[seginetapp]

Thanks for your answer.

Indeed, I already tried to reboot the filer.

I get the following...

...*> version
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/diag/diag.krn:  5.4.7
/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)

Something wrong?

[baijulal]

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.

[stevecotes]

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.

- steve

[seginetapp]

Hi Steve,

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...

😉

[markkulacz]

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. 

[scottgelb]

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.

bootarg.init.wipeclean
bootarg.init.console_muted

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.

[markkulacz]

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.

[scottgelb]

This definitely is the issue.. Set-defaults and bye to clear it.. Then make sure onboard 0c/0d are the same target or initiator as before.

Typos Sent on Blackberry Wireless

[scottgelb]

See my other post below.. if you takeover/giveback again or reboot, I suspect you will lose the settings again... loader env variables that are likely causing this.

[stevecotes]

In this case the issue was having an entry in the rc file for the losk interface.

I had issues with boot env variables in January but got those fixed long ago.

[seginetapp · Accepted solution]

Hi,

Problem solved.

You were right Steve. Many thanks. The root cause was an entry for losk interface in the /etc/rc file. With the assistance of support team, I cleaned up this entry and rebooted filer. The autosupport options are now readable.

An official fix has been released :

https://kb.netapp.com/support/index?page=content&id=2015666

Thanks all for your help.

Best Regards.

[arthursc0]

HI,

We have this issue with 8.02 on a FAS6080 ufter upgrading. The thing with our issue is that there is NO -losk entry in the rc file so the bug fix resolution doesn't apply here.

Any ideas anyone?

regards

Colin.