how to synchronize your juniper ex-series virtual chassis member’s junos alternate boot partition software images with the primary after an upgrade

problem: you just finished upgrading (okay, maybe the upgrade was done quite some time ago!) and you never thought to check to see if the image you last upgraded to was placed on both the primary slice (boot partition) and the secondary (or alternate) boot partition. in fact, you halt/restart one of your virtual chassis members only to have it boot up to the alternate partition and present you with the all too confusing and scary message:

— JUNOS 10.4R3.4 built 2011-03-19 22:06:32 UTC **************************************************************************** ** ** ** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE ** ** ** ** It is possible that the primary copy of JUNOS failed to boot up ** ** properly, and so this device has booted from the backup copy. ** ** ** ** Please re-install JUNOS to recover the primary copy in case ** ** it has been corrupted. ** ** ** ****************************************************************************

so, my good buddy terrance and i have been upgrading Juniper virtual chassis (plural) and started to notice that for some reason, after you upgrade, junos does not synchronize the software image to which you just upgraded to the alternate/backup slice on the ex4200 series switches. in fact, on newer switches that ship with the 11.x branch of junos after upgrading to the jtac recommended (as of march 2012) 10.4R9.2 code you will be left with your primary slice booting to 10.4R9.2 code and the 11.x code is on your backup slice. now, we are working with virtual chassis configurations (from as few as 2 switches to as many as 6), but we have also replicated this behavior to upgrading single ex4200-series switches. so how do you check to see which slice if your primary boot slice and, more importantly, which slice is the backup and what version of software will it boot to if it has to? run the following command:

user@juniperex4200> show system snapshot media internal all-members slice 1

that will show you the information for slice 1 (which is not always the primary slice) and the command:

user@juniperex4200> show system snapshot media internal all-members slice 2

that command will show you whether or not slice 2 is the primary boot partition for the switch in question. here is another great example on a 3 switch virtual chassis that shows that slice 1 is actually the backup boot slice for fpc0 and fpc2:

user@ex4200> show system snapshot media internal all-members slice 1 fpc0: ———————————————————– Information for snapshot on internal (/dev/da0s1a) (backup) Creation date: Mar 19 19:37:05 2011 JUNOS version on snapshot: jbase : 10.4R3.4 jcrypto-ex: 10.4R3.4 jdocs-ex: 10.4R3.4 jkernel-ex: 10.4R3.4 jroute-ex: 10.4R3.4 jswitch-ex: 10.4R3.4 jweb-ex: 10.4R3.4 jpfe-ex42x: 10.4R3.4 fpc1: ———————————————————— Information for snapshot on internal (/dev/da0s1a) (primary) Creation date: Jun 14 01:47:52 2011 JUNOS version on snapshot: jbase : 10.4R5.5 jcrypto-ex: 10.4R5.5 jdocs-ex: 10.4R5.5 jkernel-ex: 10.4R5.5 jroute-ex: 10.4R5.5 jswitch-ex: 10.4R5.5 jweb-ex: 10.4R5.5 jpfe-ex42x: 10.4R5.5 fpc2: ———————————————————– Information for snapshot on internal (/dev/da0s1a) (backup) Creation date: Mar 19 19:37:07 2011 JUNOS version on snapshot: jbase : 10.4R3.4 jcrypto-ex: 10.4R3.4 jdocs-ex: 10.4R3.4 jkernel-ex: 10.4R3.4 jroute-ex: 10.4R3.4 jswitch-ex: 10.4R3.4 jweb-ex: 10.4R3.4 jpfe-ex42x: 10.4R3.4

so you can clearly see that /dev/da0s1a is actually the backup boot image instead of the primary boot image. from this you can deduce that we are actually running 10.4R5.5 and that we upgraded from 10.4R3.4. you can also see that the backup boot slice was never upgraded. so, that begs the question: how do i make sure those images are in sync? simply, run the following command:

user@ex4200> request system snapshot media internal slice alternate all-members

this command will sync the primary boot slice to the backup (or alternate) boot slice. i have also done up a quick video that walks through this entire process on a 6 switch juniper ex4200 virtual chassis and you can click on the link below to view what happens when you run the above command:

how to synchronize the boot partitions after a junos upgrade on ex4200 virtual chassis

i also need to give full credit to “adam at leff” whose post we ran across that put us on the right track!!! thanks adam!

okay, i hope this helps someone out there on the wire and, as always, best of luck from the dark side…

/dev/null