POST: PortASIC RingLoopback Tests : Begin[output truncated]
POST: PortASIC RingLoopback Tests : End, Status Passed
extracting front_end/fe_type_1 (34760 bytes)
extracting front_end/front_end_ucode_info (86 bytes)
extracting front_end/fe_type_2 (73104 bytes)
extracting ucode_info (76 bytes)
Front-end Microcode IMG MGR: Installed 3 image(s) in cache:
Front-end Microcode IMG MGR: found microcode images for 3 devices.
Image for front-end 0: flash:/front_end_ucode_cache/ucode.1
Image for front-end 7: flash:/front_end_ucode_cache/ucode.1
Image for front-end 14: flash:/front_end_ucode_cache/ucode.1
Front-end Microcode IMG MGR: Preparing to program device microcode...
Front-end Microcode IMG MGR: Preparing to program device...26580 bytes.
Front-end Microcode IMG MGR: Programming device 0...rwRrrrrrrwsssspsssspsssspsss
I opened a TAC case to find out what this is, since if you are relying on highly predictable reload times during a maintenance window, this could throw a wrench into your plans.
It turns out that the Catalyst switches have a special-purpose microcontroller that rarely needs to be upgraded. When it does need upgrading, however, the upgrade happens as a normal part of a new IOS image load. This upgrade makes the first reload to the new IOS take much longer than usual--I didn't time it, but I would guess 3-4 times longer than normal.
Microcontroller upgrades are not typically listed in the image release notes, so the only way to know for sure how long a particular upgrade is going to take is to test it in a lab, using the exact same before/after images that you will use in production.