Problem after ontap upgrade 7.32 - 7.351

[mhellberg]

Hi All,

Was helping a customer with a ontap upgrade.

The installation went fine, no errors.  Before the reboot,disk firmware etc. was upgraded.

I rebooted the system, waited 10 minutes but the system did´nt come back up.

Went down to the serverroom, connected thru serial and the system had stoped at the boot menu:

(1)    Normal boot.

(2)    Boot without /etc/rc.

(3)    Change password.

(4)    Initialize all disks.

No errros before that what i could see. i choosed nr:1 and the system booted fine.

So i run version:

NetApp   Release 7.3.2: Thu Oct 15 04:17:39 PDT 2009

Still the old version?

If i run version -b:

1:/x86_elf/kernel/primary.krn:   OS 7.3.5.1

Rebooted the filer again. Same problem. The boot menu first, then if choosing number one, the old version.

Any one got a clue?

[mhellberg]

Was a little worried to run set-defaults, what exactly does it reset ?

Missed printenv, its on the checklist for next window.

[scottgelb]

It resets the factory environment options.  After set-defaults, you have to run bye to restart.  You could also "printenv" on both controllers in a cluster and compare to the one that works...then see the environment options to modify "setenv" or remove "unsetenv" manually.

Thomas - For the fc ports...there is a note in the fcadmin admin page..looks like the wrong driver came up to cause the onboard fc ports change.  If the logs show the ems error below, then that was the cause.  I have never seen it but shows up on the man page, so others defintely have had it happen.

http://now.netapp.com/NOW/knowledge/docs/ontap/rel80/html/ontap/cmdref/man1/na_fcadmin.1.htm

Automatic Reconfiguration
Under some circumstances, the filer may boot with the wrong driver attached. When this happens the embedded adapters are reprogrammed to their proper type and state and the filer is automatically rebooted to attach the correct driver. Before rebooting, the fci.config.autoReboot EMS message displays on the console. Events that can cause this problem include maintenance head swaps, use of the console set-defaults command, and other operations that affect the filer's boot environment state.

[thomas_glodde]

Scott, thanks for the info, yep, that was the case.

as for non-proper boot, customers sometimes experience an unplaned power outage so a fully clustered system gets completaly shutdown. upon boot, single heads as well as cluster nodes stay on LOADER prompt although printenv autoboot true, boot primary, whatever, everything fine on all nodes. its just that some boot, others doesnt.

or you have a planed maintenance, you "halt" the filers, mess around with power, then power them back on again (actualy using the real power switches, not some RLM stuff or just pulling cables, and some boot, some dont ; (

[mhellberg]

The system is now updated.

I downloaded the update again, run software update command, rebooted and everything worked.

Before that I halted the system I checked the preboot environment with: printenv

AUTOBOOT             true

AUTOBOOT_FROM        BACKUP

I am sure that "set-defaults" hade solved the problem, but i choosed the safe path to run the upgrade again.

Thanks for your help.