ASR920 IOS XE filename _get_version_from_file() issues

[falz]

I am testing iosfw on an ASR920 with this filename:

asr920-universalk9_npe.16.09.05f.SPA.bin

It fails with:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/falz/testscripts/iosfw/iosfw/iosfw.py", line 149, in __init__
    self.firmware_installed = self.check_firmware_installed()
  File "/home/falz/testscripts/iosfw/iosfw/iosfw.py", line 757, in check_firmware_installed
    if version in files:
TypeError: 'in <string>' requires string as left operand, not NoneType

Cisco appears to have thrown a wrench in to _get_version_from_file() in that the 'f' character is inserted in this IOS version. The problematic line in iosfw.py is:

pattern = r"(\d+\.\d+\.\d+)\.SPA"

browsing filenames on downloads for this device, some releases have a letter there, some do not:
https://software.cisco.com/download/home/286288711/type/282046477/release/Fuji-16.9.5f

I see an example of "f" in my case, "a" in another case.

I tested changing from pattern

(\d+\.\d+\.\d+)\.SPA

to

(\d+\.\d+\.\d+)([a-z]|)\.SPA

And it seemed to work (on regexpal.com), but there's something off about the pipe followed by nothing.. I'm not sure the most efficient way to match a string OR nothing.

Another potential issue after this is that this will return a string instead of an integer, which I suspect may break something further in the code.

[austind]

Updated the pattern in the dev branch to this: (\d+\.\d+\.\w+)\.SPA

Changing to \w+ means it will match one or more alphanumeric characters.

[falz]

Seems sane, thanks. ASR920 being pain in other ways, it doesn't support the same request platform software package install switch command as it's being fed.

Instead of switch it seems like it should be node. However, I need to RTFM for the proper command. From everything ive tested, this command doesn't even accept a url to download it, so a different method is likely required on this platform. getting the file (.bin) on the flash and then setting boot: config is our current manual method. FYI.

LMK and ill break this in to a separate case once I figure out how cisco 'actually' wants one to use this.

[austind]

First step: research & document the install process.

[falz]

From what I can see, there is no archive or request platform command that will do this. It's "place .bin on bootflash: and update boot system config statemen"t.

This platform also requires(?) a ROMMON upgrade, which is a separate file and separate command.

That second part seems out of scope, but if there's an easy way to tie this device type to that upgrade method somehow, or better yet, specify the preferred method in the config, that would be keen.

[austind]

Upgrade one manually and document each command for both IOS and ROMMON.

[falz]

Finally had a chance to look further at this. First, rommon, while important, seems out of scope for this ticket. I've opened issue 8 for this.

Out of the 4 possible methods that are currently available in iosfw, only copy and then set boot will work. Code appears to make an exception for ISR devices where it will change request platform software package install switch to request platform software package install node, but on this platform, one cannot pass it a url, only a local filename.

r-asr920-lab#request platform software package install node file ?
  bootflash:  RP-relative file path
  flash:      RP-relative file path

It has a similar command using rp 0 instead of node but it fails as this is a fixed rp platform. I may open a TAC case with cisco to see whats up, but we know that the copy method works.

So, the only supported upgrade process on this platform is good 'ol copy. We typically use HTTP, but I do not know if that's supported here (or is it secretly and undocumented?) Per config, it says tftp and ftp only. In our case, HTTP is preferred so we don't have to setup an FTP server. Also TFTP is ungodly slow as we all know. Images for this platform are approximately 400m.

copy http://<url>/asr920-universalk9_npe.16.09.05f.SPA.bin bootflash:
verify /md5 bootflash:asr920-universalk9_npe.16.09.05f.SPA.bin
no boot system flash bootflash:/<oldimage.bin>
boot system flash bootflash:/<newimage.bin>
wr mem

r-asr920-lab#show bootvar
BOOT variable = bootflash:/asr920-universalk9_npe.16.09.05f.SPA.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable does not exist
Configuration register is 0x2102

[austind]

Added an exception to get_upgrade_cmd() to use copy ... instead for ASRs. Give the latest dev commit a shot.

[falz]

I was finally able to test this out, consider it working!

A few other notes, which arent necessarily related, but came up when testing:

1. I also tested http method, since tftp is so slow and we dont use ftp anywhere currently. config.yaml was transfer_proto = http, transfer_source: '1.2.3.4/subdir/' - since we have images in a subdir. it surprisingly worked fine, and was equal to `copy http://1.2.3.4/subdir/imagename.bin bootflash:/imagename.bin. Im happy to test http test methods further if desired, and will likely be using this unofficially for further testing internally.

2. I encountered a reload issue at the end. I believe it is because reload_range is commented out in the dev branch's config. I added it to the config, ran again and it scheduled the reload fine (note I wasn't using the range feature, I just uncommented the default value)

Connected to r-asr920-lab (ASR-920-4SZ-A) as wopat via ssh
Running version: 16.9.5f
Upgrade version: 15.6(2)SP7
Upgrade status: NEEDS UPGRADE
>>> device.upgrade()
Starting upgrade on r-asr920-lab at 07:45:13 2020-05-26...
Disabling line vty exec-timeout...
Checking free space...
Found enough free space!
Installing new firmware...
Starting transfer. Expect this to take several minutes...
Transfer complete! Verifying hash...
Hash verified!
Checking boot image...
Setting boot image to bootflash:/asr920-universalk9_npe.03.18.07.SP.156-2.SP7-ext.bin...
Success! New boot image set to bootflash:/asr920-universalk9_npe.03.18.07.SP.156-2.SP7-ext.bin.
Scheduling reload...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/falz/testscripts/iosfw-devbranch/iosfw/iosfw/iosfw.py", line 1236, in upgrade
    self.ensure_reload_scheduled()
  File "/home/falz/testscripts/iosfw-devbranch/iosfw/iosfw/iosfw.py", line 966, in ensure_reload_scheduled
    return self.schedule_reload()
  File "/home/falz/testscripts/iosfw-devbranch/iosfw/iosfw/iosfw.py", line 866, in schedule_reload
    reload_range = self.config["reload_range"]
KeyError: 'reload_range'
>>> 

[austind]

Latest dev commit includes several bugfixes for schedule_reload(). Give it a shot.

[falz]

Just did this, checked the changes in the config file which now recommend "1" as immediate. set it to that, worked great.

settings in my config for future humans:

reload_in: 1
#reload_at: '00:00'
#reload_range: 120
reload_range: 0

[austind]

Thanks for reporting back.