FAS still boots Ontap 8.1 after update to 8.1P2

[mheimberg]

We recently updated a FAS2240 from Ontap 8.1 to 8.1P2.

Everything went fine, version -b shows:

sinhfas> version -b

/cfcard/x86_64/freebsd/image1/kernel: OS 8.1

/cfcard/x86_64/freebsd/image2/kernel: OS 8.1P2

/cfcard/x86_64/diag/diag.krn:  5.5.2

/cfcard/x86_64/firmware/excelsio/firmware.img: Firmware 1.9.0

/cfcard/x86_64/firmware/DrWho/firmware.img: Firmware 2.5.0

/cfcard/x86_64/firmware/SB_XV/firmware.img: Firmware 4.4.0

/cfcard/x86_64/firmware/SB_XVI/firmware.img: Firmware 5.1.1

/cfcard/x86_64/firmware/SB_XVIII/firmware.img: Firmware 7.1.2

/cfcard/x86_64/firmware/SB_XIX/firmware.img: Firmware 8.0.0

/cfcard/common/firmware/zdi/zdi_fw.zpk: Flash Cache Firmware 2.2 (Build

0x201012201350)

/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)

sinhfas>

But the system still boots Ontap 8.1 from image1.

What went wrong and how can we switch to image2?

thx

Mark

[thomas_glodde · Accepted solution]

do a software install & download again, then version -b should have both kernels overwritten.

otherwise "halt" the machine and do a "boot_secondary" or "boot_backup" to boot from image2.

[mheimberg]

Hi Thomas

thanks for the input

But isn't the meaning of having 2 images that I can manually go back to a "save harbour" in case of issues?

Therefor just writing into both images the same version is a workaround that makes me feel unhappy

And boot manually into the second image does not help when the storage boots itself after eg a panic.

Aren't there some boot args to tamper with? So it automatically chooses the right version?

thx

Mark

[aborzenkov]

Normally software update makes all required adjustments in environment to automatically boot new version. If it did not happen it could mean either deviation from update procedure or a bug. The former we do not know (do you have any logs of this?) and if you are sure everything was done correctly, you need to open support case so possible bug can be investigated.

[mheimberg]

Unfortunately we have not logged the steps ...

but we took the right version and package and then ... well, I mean updating is really straight forward: software update 81P2_q_image.tgz ; not much, that one could do wrong ...

Case is open at NetApp - but according to my experience: cases other than P1 have rather long response times ... therefore any further comments are still appreciated.

[ismopuuronen]

Hi,

I don't have an experience (yet ), but from loader promt >printenv
You are able to see from where ontap boots up, and with other commands you can change it.
i dont think that's the final solution, but example, you can now determine, from where filer boots, image1 or image2..

P2 cases should be fine

Br.
Ismo.

[mheimberg]

sounds very interesting ... eager to know what env variables I have to change (printenv -> show; setenv -> set) - there are several dealing with booting the system ...

have to check them in a quiet minute

[scottgelb]

I have seen this when a cf takeover -f is done instead of cf takeover.  How was the takeover and giveback done?

[mheimberg]

not at all - because this is a single controller system

[mheimberg]

doing an install again was also recommended by NetApp support.

[tuxotop]

Markus,

What happen after this ?

[mheimberg]

Hi tuxotop

not sure what you mean by "after this" ...

in the meantime I encountered the issue 2 or 3 more times on different controllers and different DOT versions - colleagues of mine as well ...

as NetApp recommended we re-installed the image a second time and went ahead.

[tuxotop]

so re-installing solved it ? , do you remember what are the command you issued to resolve the issue

[mheimberg]

just the commands to update DOT:

>software install ...

If you need more information about command syntax, please have a look at the command line reference (http://support.netapp.com/documentation/bytype/index.html?subtypeID=61030 ), eg for 7G: https://library.netapp.com/ecmdocs/ECMM1278259/html/cmdref/man1/na_software.1.htm

[HYPERHYPO]

hello

i've just encountered same  issueon upgrade from 8.0.2P6 to 8.1.4P3 on an HA V3270....i'm certain i followed same process on both nodes but node02 insisted on booting from image1..... although i recall it stated it was booting from image2.

Node 01 upgraded correctly and booted up off imag2...........i'd checked with version -b to display contents of image1 and image2 before  initiating the upgrade from node 01 with a "cf takeover"

no force flag was used either ...........i was made aware of something wrong when i didn't need to run cf takeover -n the second time around ( the -n flag is required to overcome version mismatch on two nodes) but didn't need  the -n and then realised i was still booted  off 8.0.2P6 !

The fix was to manually boot_backup to get the upgraded 8.1.4P3 and then re-run "software update" to put 8.1.4P3 onto image1.

It caused a P1 as node02 was unbootable for a while but i still don't understand what went wrong. I used same process on a V3240 which was ok.

I'm interested to hear others experience of this ... not least as have to repeat same soon on FAS kit as well as the V-series we've just completed.