![]() You can use the workflow within Automator or save it as an application that allows you to drag and drop the files you want to rename when needed. Create an Automator WorkflowĪutomator allows you to quickly create custom workflows to rename your files. And now it looks like they've fixed it at least as early as 16.3.6.As you can see, there are no shortage of suitable renaming applications, each with slightly different capabilities and prices. So yes, when first implemented, the command and description were not consistent with each other, but it appears to be the description that was wrong, not the command. Any kind of microcode update or other installation does not happen until the device is rebooted. If you perform a verbose installation with the reboot suppressed, you see that all that happens is the software is unpacked and a new nf file is created, pointing to the new. ![]() I agree this is inconsistent with "on the next reboot". The bug report you referenced is for 16.3.3, which I unfortunately do not have on hand, but the report shows the description of "Suppress reload prompt and do not reload after installation". If I log into any of my devices running IOS-XE ranging from 16.3.6 to 17.6.4, typing the "?" after the file prompt shows "on-reboot" with the description "Delay effects until RP reboot", which I find to be consistent with my description of "on-reboot" above, meaning "on the next reboot". Make sure the contents all point to the new package files.Īlso check the boot-variable string is pointing to the "nf" file. ![]() No one can afford for one stack member to be booting into a different firmware version. The command above must be checked in every switch member of the stack. The command to do the check is simple: more flash-X:nf Where I work, I have made it a point to double-check the contents of the nf file to make sure it is pointing to the correct package files. And if the operator is paying attention to this error message he/she must rename the file to "nf". The packages have been successfully unpacked, however, the nf "could not be changed" so the system has created another file. The packages have been successfully unpacked and nf file has been changed to reflect this, HOWEVER, double-checking shows the nf file is still pointing to the old package files.Ģ. Whatever method is used to "unpack" the BIN file, the automated method is meant to change the "nf" file to point to the new package files, however, I have seen times where the script will say either one of the following:ġ. What have I gotten guess my question is, after the install, is manipulating the nf file a valid way to proceed? By replacing the nf file with the one from the new version it would allow you to do a "reload at XX:XX" command for an unattended reboot. This document seems like it was written by someone while actually performing the process and there is no mention of a separate reload step: The release notes actually instruct you to issue a reload command after the install activate is done. But what else? It would be nice to have some more comprehensive documentation. Would that be a valid upgrade procedure? What else does the install activate process do? There is a rollback timer that is set somewhere so that if install commit is not entered in 120 minutes (default) it reverts to the previous image. Rename the nf file file to cat9k_iosxe.16.12.03.SPA.conf.This is going to copy the cat9k_iosxe.16.12.05.SPA.conf file to nf and do a reload. Switch#install activate file flash:/cat9k_iosxe.16.12.05.SPA.bin pkg files and creates a new cat9k_iosxe.16.12.05.SPA.conf file. This just does some validation, unbundles the. Switch#install add file flash:/cat9k_iosxe.16.12.05.SPA.bin Unfortunately I am am doing this on a production switch so I can't play around with it as much as I want to. I am upgrading a 9300 from 12.16.3 to 12.16.5 and I too want to separate the install from the reboot.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |