Using Primary and Secondary flash image options
The switches covered in this guide feature two flash memory locations for storing switch software image files:
Primary Flash: The default storage for a switch software image.
Secondary Flash: The additional storage for either a redundant or an alternate switch software image.
With the Primary/Secondary flash option, you can test a new image in your system without having to replace a previously existing image. You can also use the image options for troubleshooting. For example, you can copy a problem image into Secondary flash for later analysis and place another, proven image in Primary flash to run your system. The switch can use only one image at a time.
The following tasks involve primary/secondary flash options:
Displaying the current flash image data and determining which switch software versions are available
Switch software downloads
Replacing and removing (erasing) a local switch software version
System booting
Displaying the current flash image data
Use the commands in this section to:
Determine whether there are flash images in both primary and secondary flash
Determine whether the images in primary and secondary flash are the same
Identify which switch software version is currently running
Viewing the currently active
flash image version. Use the show version command
to identify the software version on which the switch is currently
running, and whether the active version was booted from the primary
or secondary flash image.
For example, if the switch is using a software
version of K.12.XX stored in Primary flash, show version produces
the following:
The identity of the current flash image
switch(config)# show version
Image stamp: /su/code/build/info(s01)
Dec 01 2006 10:50:26
K.12.XX
1223
Boot Image: Primary
Determining whether the flash images are different versions. If the flash image sizes in primary and secondary are the same, then in almost every case, the primary and secondary images are identical. This command provides a comparison of flash image sizes, plus the boot ROM version and from which flash image the switch booted. For example, in the following case, the images are different versions of the switch software, and the switch is running on the version stored in the secondary flash image:
Different flash image versions
switch(config)# show flash Image Size(Bytes) Date Version ----- ---------- -------- ------------- Primary Image : 7493854 03/21/10 K.15.01.0001 Secondary Image : 7463821 03/23/10 K.15.01.0001 Boot Rom Version: K.15.08 Default Boot : Primary
Determining which flash image versions are installed. The show version command displays which software
version the switch is currently running and whether that version booted
from primary or secondary flash. Thus, if the switch booted from primary
flash, you will see the version number of the software version stored
in primary flash, and if the switch booted from secondary flash, you
will see the version number of the software version stored in secondary
flash. Thus, by using show version, then rebooting
the switch from the opposite flash image and using show version again,
you can determine the version(s) of switch software in both flash
sources. For example:
Determining the software version in Primary and Secondary flash
switch(config)# show version
Management Module 1: Active
Image stamp: /sw/code/build/btm(ec_K_15)
Aug 2 2012 09:06:58
K.15.12.001
152
Boot Image: Primary
switch(config)# boot system flash secondary
Device will be rebooted, do you want to continue [y/n]? y
.
.
.
switch(config)# show version
Management Module 1: Active
Image stamp: /sw/code/build/btm(ec_K_15)
Aug 2 2012 09:06:58
K.15.12.001
1753
Boot Image: Secondary
Switch software downloads
The following table shows the switch’s options for downloading a software version to flash and booting the switch from flash.
Primary/Secondary memory access
| Action | Menu | CLI | Web Agent | SNMP |
|---|---|---|---|---|
| Download to Primary | Yes | Yes | Yes | Yes |
| Download to Secondary | No | Yes | No | Yes |
| Boot from Primary | Yes | Yes | Yes | Yes |
| Boot from Secondary | No | Yes | No | Yes |
The different software download options involve different copy commands, plus xmodem, usb, and tftp.
Download interruptions. In most cases, if a power failure or other cause interrupts a flash image download, the switch reboots with the image previously stored in primary flash. In the unlikely event that the primary image is corrupted, as a result of an interruption, the switch will reboot from secondary flash and you can either copy the secondary image into primary or download another image to primary from an external source.
Replacing or removing local switch software
This section describes commands for erasing a software version and copying an existing software version between primary and secondary flash.
![[NOTE: ]](images/note.gif) | NOTE: It is not necessary to erase the content of a flash location before downloading another software file. The process automatically overwrites the previous file with the new file. If you want to remove an unwanted software version from flash, Hewlett Packard Enterprise recommends that you do so by overwriting it with the same software version that you are using to operate the switch, or with another acceptable software version. To copy a software file between the primary and secondary flash locations, See "Copying a switch software image from one flash location to another", below. The local commands described here are for flash image management within the switch. To download a software image file from an external source, see "File Transfers" in the Management and Configuration Guide for your switch. |
Copying a switch software image from one flash location to another. When you copy the flash image from primary to secondary or the reverse, the switch overwrites the file in the destination location with a copy of the file from the source location. This means you do not have to erase the current image at the destination location before copying in a new image.
![[CAUTION: ]](images/caution.gif) | CAUTION: Verify that there is an acceptable software version in the source flash location from which you are going to copy. Use the show flash command or, if necessary, the procedure under Displaying the current flash image data to verify an acceptable software version. Attempting to copy from a source image location that has a corrupted flash image overwrites the image in the destination flash location. In this case, the switch will not have a valid flash image in either flash location, but will continue running on a temporary flash image in RAM. Do not reboot the switch. Instead, immediately download another valid flash image to primary or secondary flash. Otherwise, if the switch is rebooted without a software image in either primary or secondary flash, the temporary flash image in RAM will be cleared and the switch will go down. To recover, see "Restoring a Flash Image" in the Management and Configuration Guide for your switch. |
Syntax
copy flash flash <destination flash>
where: destination flash = primary or secondary:
For example, to copy the image in secondary flash to primary flash:
Verify that there is a valid flash image in the secondary flash location. The following figure indicates that a software image is present in secondary flash. (If you are unsure whether the image is secondary flash is valid, try booting from it before you proceed by using
boot system flash secondary.)
Indicating two different software versions in Primary and Secondary flash
switch(config)# show flash Image Size (bytes) Date Version ----------------- ------------ -------- -------------------- Primary Image : 10167529 10/14/11 K.14.89 Secondary Image : 15085139 08/17/12 K.15.10.0001 Boot ROM Version : K.15.28 Default Boot : Primary
Execute the copy command as follows:
switch(config)# copy flash flash primary
Erasing the contents of Primary or Secondary flash. This command deletes the software image file from the specified flash location.
| CAUTION: No undo! Before using this command in one flash image location (primary or secondary), ensure that you have a valid software file in the other flash image location (secondary or primary). If the switch has only one flash image loaded (in either primary or secondary flash) and you erase that image, then the switch does not have a software image stored in flash. In this case, if you do not reboot or power cycle the switch, you can recover by using xmodem or tftp to download another software image. |
Syntax
erase flash [primary | secondary]
For example, to erase the software image in primary flash, do the following:
First verify that a usable flash image exists in secondary flash. The most reliable way to ensure this is to reboot the switch from the flash image you want to retain. For example, if you are planning to erase the primary image, then first reboot from the secondary image to verify that the secondary image is present and acceptable for your system:
switch# boot system flash secondary
Then erase the software image in the selected flash (in this case, primary):
Type ‘y’ at the prompt to complete the flash erase.
Use
show flashto verify erasure of the selected software flash image. The “0” shows that the primary flash has been erased.
In redundant management systems, this command will erase the selected flash in both the active and the standby management modules. If redundancy has been disabled or the standby module has failed self-test, this command only affects the active management module.
Rebooting the switch
Setting the default flash for bootup
Use the boot set-default flash command to specify the default flash (primary or secondary) to boot from on the next boot. The syntax is as follows:
boot set-default flash [ primary|secondary ]
Boot set-default command with default flash set to Secondary (with a redundant management module present)
switch(config)# boot set-default flash secondary switch(config)# show flash Image Size(Bytes) Date Version ------ ---------- ------- ------------- Primary Image : 7476770 03/15/10 K.15.01.0001 Secondary Image : 7476770 03/15/10 K.15.01.0001 Boot Rom Version: K.15.08 Default Boot : Secondary switch(config)# boot This management module will now reboot from secondary and will become the standby module! You will need to use the other management module's console interface. Do you want to continue [y/n]?
Booting from the default flash or configuration file
Use the boot command to boot the switch from the default flash (primary or secondary) image. This command allows a boot sequence that includes the complete set of self-tests.
The switch is booted either from the flash (primary or secondary) that you are currently booted on or from the flash image that was set by the boot set-default command or by the last executed boot system flash <primary | secondary> command. You can select which image to boot from during the boot process itself (you are prompted with a message which will indicate the flash being booted from). When using redundant management, the switch will fail over to the standby management module.
Use the boot config <filename> command to boot from a configuration file. This command allows a boot sequence that includes the complete set of self-tests.
Boot command (default Primary flash) with redundant management
switch(config)# boot This management module will now reboot from primary image and will become the standby module! You will need to use the other management module's console interface. Do you want to continue [y/n]? y Do you want to save current configuration [y/n]? n
In the above example, typing either a ‘y’ or ‘n’ at the second prompt initiates the reboot operation. (Entering ‘y’ saves any configuration changes from the running-config file to the startup-config file; entering ‘n’ discards them.)
Boot command booting from a different flash than the current flash (with redundant management module present)
switch(config)# show flash Image Size(Bytes) Date Version Primary Image : 7497114 03/29/10 K.15.01.0001 Secondary Image : 7497114 03/29/10 K.15.01.0001 Boot Rom Version: K.15.08 Default Boot : Primary switch(config)# boot set-default flash secondary This command changes the location of the default boot. This command will change the default flash image to boot from secondary. Hereafter, 'reload' 'boot' commands will boot from secondary. Do you want to continue [y/n]? y switch(config)# boot This management module will now reboot from secondary image and will become the standby module! You will need to use the other management module's console interface. Do you want to continue [y/n]? n
Booting from a specified flash
Use the boot system flash primary command to reboot from primary flash. This command allows a boot sequence that includes the complete set of self-tests.
Use the boot system flash secondary command to reboot from secondary flash. This command allows a boot sequence that includes the complete set of self-tests.
The following example shows use of the command to reboot the switch from secondary flash when there are no pending configuration changes in the running-config file. Typing either a [y] or [n] at the second prompt initiates the reboot operation.
Enabling and disabling the fastboot option
Use the fastboot command to enable the fastboot option. When this option is enabled, the bootup sequence does not include the internal power-on self-tests, resulting in a faster boot time.
Use the no fastboot command to disable the fastboot option. When this option is disabled, the bootup sequence includes the complete set of self-tests.
Use the show fastboot command to display the status of the fastboot feature, either enabled or disabled.
When using redundant management and fastboot is enabled, it is saved to the standby management module when the config files are synchronized. Fastboot is used during the next bootup on either management module.
Using reload
The reload command reboots the switch from the flash image that you are currently booted on (primary or secondary) or the flash image that was set either by the boot set-default command or by the last executed boot system flash <primary | secondary> command. Because reload bypasses some subsystem self-tests, the switch reboots faster than if you use either of the boot command options. If you are using redundant management and redundancy is enabled, the switch will failover to the other management module.
Syntax
reload
For example, if you change the number of VLANs the switch supports, you must reboot the switch in order to implement the change. The reload command prompts you to save or discard the configuration changes.
Using reload with redundant management and pending configuration changes
switch(config)# max-vlans 12 Command will take effect after saving configuration and reboot. switch(config)# reload This command will cause a switchover to the other management module which may not be running the same software image and configurations. Do you want to continue [y/n]? y
Scheduled reload. Beginning with software release K.11.34, additional parameters have been added to the reload command to allow for a scheduled reboot of the switch via the CLI.
Syntax
[no] reload [after <[dd:]hh:] [mm>] | [at <hh:mm[:ss]>] [<mm/dd[/[yy]yy]>]
Enables a scheduled warm reboot of the switch. The switch boots up with the same startup config file and using the same flash image as before the reload.
| CAUTION: When using redundant management, the reload at/after command causes a switchover at the scheduled time to the other management module, which may not be running the same software image or have the same configurations. |
Parameters include:
after: Schedules a warm reboot of the switch after a given amount of time has passed.
at: Schedules a warm reboot of the switch at a given time.
The no form of the command removes a pending reboot request.
For more details and examples, see the following.
The scheduled reload feature removes the requirement to physically reboot the switch at inconvenient times (for example, at 1:00 in the morning). Instead, a reload at 1:00 mm/dd command can be executed (where mm/dd is the date the switch is scheduled to reboot).
| NOTE: Configuration changes are not saved with reload at or reload after commands. No prompt to save configuration file changes is displayed. See Comparing the boot and reload commands. |
Examples of scheduled reload commands:
To schedule a reload in 15 minutes:
To schedule a reload in 3 hours:
To schedule a reload for the same time the following day:
To schedule a reload for the same day at 12:05:
To schedule a reload for some future date:
The reload command with a redundant management system
switch(config)# reload after 04:14:00
Reload scheduled in 4 days, 14 hours, 0 minutes
This command will cause a switchover at the scheduled
time to the other management module which may not be
running the same software image and configurations.
Do you want to continue [y/n]?Module reload. The module reload feature allows you to reset a module by initiating a warm reboot of a specified module or modules. This saves time over rebooting the entire switch, which can take several minutes to complete and disrupts all users on the switch. The specified module has its power turned off, and then turned on again. This causes the module to reset to a known good state and reload its software.
Syntax
[no] reload [[after <[[DD:]HH:]MM>] | [[at HH:MM[:SS] [MM/DD[/[YY]YY]]]] | [[module <slot-id-range>]]]
When specified with the module parameter, initiates a reload of the module in the specified slot or slots by turning the slot power off, then on again. A valid slot or range of slots must be specified. The at and after parameters are not allowed with the module option. The no version of the command is not valid with the module option.
When the reload command is executed without any parameters, an immediate switch reload occurs.
| NOTE: This feature is not supported for HPE One modules. |
module: Powers
the module on or off, forcing a software reload of the specified module
or modules.
Reloading a specified module
switch(config)# reload module C The ‘reload module’ command will shutdown the specified modules. Ports on specified modules will no longer pass traffic. Any management traffic to the switch which passes through the affected modules will be interrupted (e.g. ssh, telnet, snmp). This command may take up to 2 minutes to power down all specified modules. Please check the event log for current status of module power down, power up cycle. Continue [y/n]?
Displaying reload information. Use the show reload command to display the reload information. This can include:
A scheduled, pending reload of the entire switch
A statement that no reload is scheduled
The time of the last reload of each module on the system
The scheduled reload at information
switch(config)# reload at 23:45 Reload scheduled at 23:45:47 6/16/2012 (in 0 days, 1 hours, 41 minutes switch(config)# show reload at Reload scheduled for 23:45:47 06/16/2012 (in 0 days, 1 hours, 40 minutes) switch(config)# show reload after Reload scheduled for 23:45:47 6/16/2012 (in 0 days, 1 hours, 40 minutes)
Boot and reload command comparison
The switch offers reboot options through the boot and reload commands, plus the options inherent in a dual-flash image system. Generally, using boot provides more comprehensive self-testing; using reload gives you a faster reboot time.
Comparing the boot and reload commands
| Actions | Included in Boot? | Included in Reload | Note |
|---|---|---|---|
| Save all configuration changes since the last boot or reload | Optional, with prompt | Optional with reload <cr>, when prompt displays. Not saved with reload at/after commands; No prompt is displayed. | Config changes saved to the startup-config file if "y" is selected (reload command). |
| Perform all system self-tests | Yes | No | The reload command provides a faster system reboot. |
| Choice of primary or secondary flash image | Yes | No—Uses the current flash image. | |
| Perform a scheduled reboot | No | Yes | Use the reload command with after/at parameters (see Using reload for details). |
Operating notes about booting
Default boot source. The switch reboots from primary flash by default unless you specify the secondary flash by entering either the boot system flash [primary | secondary] or boot set-default flash [primary | secondary] command. Both the boot command and the reload command will reboot based on how these options have been selected.
Boot attempts from an empty flash location. In this case, the switch aborts the attempt and displays:
Image does not exist Operation aborted.
Interaction of Primary and Secondary flash images with the current configuration. The switch has one startup-config file (see Configuration file management), which it always uses for reboots, regardless of whether the reboot is from primary or secondary flash. Also, for rebooting purposes, it is not necessary for the software image and the startup-config file to support identical software features. For example, suppose that you have just downloaded a software upgrade that includes new features that are not supported in the software you used to create the current startup-config file. In this case, the software simply assigns factory-default values to the parameters controlling the new features. Similarly, If you create a startup-config file while using a version "Y" of the switch software, and then reboot the switch with an earlier software version "X" that does not include all the features found in "Y", the software simply ignores the parameters for any features that it does not support.
Scheduled reload. If no parameters are entered after the reload command, an immediate reboot is executed. The reload at and reload after command information is not saved across reboots. If the switch is rebooted before a scheduled reload command is executed, the command is effectively canceled. When entering a reload at or reload after command, a prompt will appear to confirm the command before it can be processed by the switch. For the reload at command, if mm/dd/yy are left blank, the current day is assumed.
The scheduled reload feature removes the requirement to physically reboot the switch at inconvenient times (for example, at 1:00 in the morning). Instead, a reload at 1:00 mm/dd command can be executed (where mm/dd is the date the switch is scheduled to reboot).