Switch 3750E IOS upgrade failure

Hi all,
I have a brand new switch 3750E (Model number : WS-C3750E-48TD-S), which would be upgraded to latest IOS.
I issue the following command to upgrade IOS:
switch#archive download-sw /overwrite tftp://1.1.1.2/c3750e-universal-tar.122-46.SE.tar
The output is below:
examining image...
extracting info (107 bytes)
extracting c3750e-universal-mz.122-46.SE/info (382 bytes)
extracting info (107 bytes)
Stacking Version Number: 1.40
System Type: 0x00000002
Ios Image File Size: 0x00AC0A00
Total Image File Size: 0x00D45A00
Minimum Dram required: 0x08000000
Image Suffix: universal-122-46.SE
Image Directory: c3750e-universal-mz.122-46.SE
Image Name: c3750e-universal-mz.122-46.SE.bin
Image Feature: IP|LAYER_3|PLUS|MIN_DRAM_MEG=128
Old image for switch 1: flash:c3750e-universal-mz.122-35.SE5
Old image will be deleted after download.
The switch got frozen, and I have to power cycle it. Then the switch boots up with old IOS.
It seems new IOS image file didn't overwrite the old one. I tried 3 times, the result. Any suggestion? Should I just delete the old one and archive new one?
Your help is appreciated.
Ethan

Hi Ethan, when the archive download is completed or successful the boot variable will automatically be updated with the new IOS image.
The overwrite keyword deletes the existing or current image in order to make room for the new one. If you use either /leave-old-sw, or /safe then this could cause problems if there is insufficent flash.
In both cases the old software is not deteled, with /safe it will delete the old image once the new one has been downloaded sucessfully.
If the overwrite does not appear to be successful, then I would recommend deleting the current image first before downloading the new archive without the need to overwrite:-
delete /force /recursive flash:/file-url
Hope this helps
Allan.
Pls rate helpful posts.

Similar Messages

Switch stack IOS upgrade

Hi,
I am planning on upgrading a 3750x switch stack to a slightly newer version.
My question is, would I have to load the new image onto each switch in the stack or just the master?
Thanks,
Waqas

I am planning on upgrading a 3750x switch stack to a slightly newer version
Specify the IOS so we can determine if you are going to a bad IOS version.
My question is, would I have to load the new image onto each switch in the stack or just the master?
1. Download the IOS file with the TAR filename from the Cisco website.
2. Compare the MD5 hash value of this file against the one in the Cisco website. The MD5 hash value must match.
3. Use the command to upgrade your IOS: archive download-sw /destination N tftp:///IOS.tar
NOTE: /destination N - The "N" means the switch members in a stack. If you have three switches in a stack then you use /destination 1 /destination 2 /destination 3.

Catalyst 4500 L3 Switch Software IOS upgradation

Hi,
Is it possible to copy IOS from active sup to slave sup ...in cat4500 series switch

Yes it is.
See this link for details -
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/54sg/configuration/guide/config/RPR.html#wp1130150
Jon

CP: I v1.3 Upgrade Switch & Router IOS?

From everything I've read, it does not look like Prime: Infrastructure is capable of upgrading the IOS of Catalyst Switches and IOS Routers. I just wanted to give a shout out incase I am wrong.
Does anyone know if this feature will be available in v2.0?
CCNP, CCIP, CCDP, CCNA: Security/Wireless
Blog: http://ccie-or-null.net/

Hey SOcchiogrosso,
The image management is alrealdy possible on PI 1.2 if you have a lifecycle license.
You can perform an image import to your repository an then disbribute to your devices.
Go to [Operate] > [Software Image Management]. There you will be able to maintain and deploy your images.
If you want to get further on this, take a look on the following document:
http://www.cisco.com/en/US/partner/docs/net_mgmt/prime/infrastructure/1.2/user/guide/maint_images.html
If you want to see what has changed from LMS to CPI I would indicate you to see this document:
http://www.cisco.com/en/US/customer/prod/collateral/netmgtsw/ps6504/ps6528/ps12239/app_note_c27-716230.html
I hope it helps
Kauy Gabriel.

Cisco switch ios upgradation

how can I upgrade cisco 2960s switch's ios.
what commands will be used for it

Hello Anupam,
1. You need to copy the IOS from CCO.
2. The same IOS needs to copied on to the flash.
#copy tftp : flash
#tftp ip address <x.x.x.x>
3. I would suggest before upgrading the IOS. Please verify the MD5 checksum and confirm with CCO that it matches. This confirms that while copying the image didnt get corrupt.
#verify /md5 Flash:<IOSimage>.bin
4. Once you see the IOS in flash. Please configure below.
boot-start-marker
boot system flash <IOS image name>.bin
boot-end-marker
5. Save the confguration.
#wr
6. reload the router. Post reload you can run " show version" to check if device has come up with new IOS.
HTH,
Nikhil

No valid license found after IOS upgrade on C3750x switch

HI,
Two switches below are working fine as a stack with IOS c3750e-universalk9-mz.122-55.SE5.bin & ipbase license.
Switch#1 (Master, WS-C3750X-24P-S)
Switch#2 (Member, WS-C3750X-24P-S)
After IOS Upgrade to c3750e-universalk9-mz.150-2.SE7.bin, The stack was broken. Switch#2 didn’t recognise valid ipbase license with new IOS and came up with lanbase license instead. Therefore stack cannot be composed due to license mismatch between Switch#1 (ipbase) and switch#2(lanbase).
I’m wondering why Switch#2 didn’t recognise ipbase license with new IOS even though IPASE is running well with previous IOS.
Here is excerpt from “show version” with 15.x image on Switch#2.
License Level: lanbase
License Type: Default. No valid license found.
Next reload license Level: lanbase
Here is excerpt from “show version” with 12.x image on Switch Stack.
License Level: ipbase
License Type: Permanent
Next reload license Level: ipbase
Thanks
Jeong

Thanks guys,
I have fixed the issue by configuring 'license boot level ipbase' on the member switch#2. The switch recognised IPBASE license well and joined the stack successfully.

Aironet 1252 IOS Upgrade Radio Failure

Did anyone else learn this the hard way? I upgraded a bunch of 1252's using my WLSE to 12.4(21a)JA1 and the radio's crapped out after the upgrade. I've found references to having to have to shutdown the radios before the IOS upgrade. What's up with that?
brian

Nope. I have autonomous and LWAP APs running this IOS version and I have no issues about it. Can you post the logs during bootup?

POE 3560 Issue after IOS upgrade

Hello,
I having issue where 6 WLAN AP's not coming back uo after reboot and IOS upgrade of 3560 POE swtiches - . Prior to changes here most if not all ALL the 23 Aps were mainly on one switch, Now after these changes they are now spread over three switches ( 3560's) - with 17 coming back on line
I am sure its not the power limitation of the switch(s) as the one switch I am TS at present had a fairly large allocation of the aps attached prior to ios upgrade and reload. and the available power value now showing is applicable.for 8 AP's
I have tried various TS steps to try and bring them back up - A couple of things I would like to try but I am restricted to do so is to check the APS physically or downgrade the ios!
Any input on this matter would be truly appreciated.- (attached is the log buffer debug)
res
Paul

c3560-ipbase-mz.122-25.SEE2.bin
You upgraded the IOS to the switch? I shudder at the thought of what old version did you upgrade FROM.
Available:370.0(w) Used:110.4(w) Remaining:259.6(w)
You've got more than enough PoE left.
Only two things comes to my mind:
1. Cable issue - Unfortunately, the 3560 is a non-GigabitEthernet and this particular sub-model does NOT support TDR.
2. Hardware failure - Read THIS.

Cisco 4500X IOS upgrade through ISSU

Hi,
I am having 2 number of cisco 4500x switch and configured with VSS
so one switch is active and another switch is standby.
I am panning to upgrade IOS through ISSU
i read in document that it required auto boot enable in switch.
My switch current Configuration register = 0x2101
do i need to change config register or this will ok. If need to change then what will be auto boot and after IOS upgrade do i need to change it again.
Please help....

Hello Tarun,
Please find below the steps to perform the ISSU:
ISSU Prerequisites
Before one can perform an ISSU, there are a few prerequisites one must verify for a successful ISSU. The following list explains what is initially required.
• Must be using a redundant Cisco Catalyst 4500 switch with symmetric hardware (that is, supervisors, memory, rommon, NFL daughter card, and so on).
• Both new and old Cisco IOS Software images must be preloaded to the file system on both supervisors.
• SSO must be configured and working properly.
• Config register must be configured to autoboot (that is, the value should have a "2" in the lowest byte).
45010R-203# sh bootvar | i register
Configuration register is 0x2102
Standby Configuration register is 0x2102
Several commands are available to verify if SSO is enabled:
4510R-203# sh module | b Redundancy
Mod  Redundancy role     Operating mode      Redundancy status
----+-------------------+-------------------+-------------------
1   Standby Supervisor   SSO                  Standby hot
2   Active Supervisor    SSO                 Active
45010R-203# sh redundancy states
       my state = 13 -ACTIVE
     peer state = 8   -STANDBY HOT
           Mode = Duplex
           Unit = Secondary
        Unit ID = 2
Redundancy Mode (Operational) =  Stateful Switchover
Redundancy Mode (Configured)  =  Stateful Switchover
Redundancy State              =  Stateful Switchover
             <snip>
4507R-ISSU# sh run | b redundancy
redundancy
mode  sso
As a step prior to the beginning of the ISSU process, the new version of the Cisco IOS Software image needs to be loaded into both the active and standby supervisors' file systems. Both active and standby supervisor need to contain both the new and old images in the file system. In order to store both new and old images, the supervisors should be upgraded to contain sufficient amounts of flash memory prior to the ISSU process.
The new images can be downloaded into both supervisors using commands such as:
copy tftp: bootflash:
copy tftp: slavebootflash:
The example below illustrates this verification:
4510R-203#dir
Directory of bootflash:/
1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1
4510R-203#dir slavebootflash:
Directory of slavebootflash:/
1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1
Once this check is verified, one can now proceed with the ISSU process.
The ISSU process is started by typing the "issu loadversion" command on the active supervisor. This command directs the active supervisor to begin the ISSU process. The active supervisor, through intersupervisor communications, checks that the requested image has been downloaded into both the active and standby supervisors' file systems. If the required images are not present, the command is rejected, and an appropriate warning is generated.
If the "issu loadversion" command is successful, the switch transitions into the "Load Version" ISSU state. The standby supervisor will reset and boot with the new version of the Cisco IOS Software image loaded into the file system.
The following actions take place when the command is implemented:
1. The standby supervisor (B) is reset.
2. The standby supervisor (B) is booted with the new Cisco IOS Software image: Release 12.2(31)SGA1.
3. If both Cisco IOS Software images are declared as compatible, the standby supervisor moves into SSO mode and is fully stateful for all compatible clients and applications. Compatibility allows for in-service software upgrade or downgrade between two versions to succeed with minimal service effect.
4. If both Cisco IOS Software images are incompatible, the system moves into RPR mode, and the ISSU process is terminated with an appropriate message to the user. Images are declared incompatible when "required" clients or applications are not interoperable between two Cisco IOS Software releases.
5. Standby "B" reaches the standby HOT state.
6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
7. The "issu loadversion" command also supports a "forced" option that allows the operator to force the system into entering RPR mode when incompatibility is detected.
Note: When performing an ISSU, disable manual switchovers. Performing manual switchovers during the issu process is strongly discouraged. The current implementation does not prevent it, but it does display a warning to the user.
An example of the CLI for implementing the issu loadversion command is displayed below.
On the active supervisor, one would issue the following command:
4510R-203#issu loadversion 1 bootflash:cat4500-entservices-mz.122-31.SGA1 2 slavebootflash: cat4500-entservices-mz.122-31.SGA1
Syntax - issu loadversion active-slot active-image-new standby-slot standby-image-new
The second step of the ISSU process is to perform the issu runversion CLI.
The user can issue the " issu runversion" command when:
1. The ISSU state is "Load Version"; this can be verified with the "show issu state detail" CLI.
2. The standby supervisor is running the new version of the software.
3. The standby supervisor has moved into the "Standby Hot " state.
The following actions take place when the " issu runversion" command is executed:
1. A switchover occurs; that is, the standby (B) becomes the new active, and the old active (A) is rebooted and comes up as a standby.
2. A timer called "Rollback Timer" is started with a previously configured value.
3. Move both supervisors to "Run Version" state.
4. If the command "issu acceptversion" is not issued before the "Rollback timer" fires, then the entire ISSU process is aborted via the automatic rollback.
5. If the active supervisor console connectivity is established and the "issu acceptversion" command is issued, then the rollback timer is stopped.
6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
An example of the CLI for implementing the issu runversion command is displayed below:
On the active supervisor, one would issue the following command:
4510R-203#issu runversion 2 slavebootflash:cat4500-entservices-mz.122-31.SGA1
Syntax - issu runversion standby-slot [standby-image-new]
Prior to issuing the `issu acceptversion' command the system will be counting down the rollback timer. If `issu acceptversion' is not completed before rollback timer expires an automatic abort will occur. This command stops the "Rollback Timer." This command serves as a feedback mechanism. This is an optional command and can be skipped in the ISSU process with the "issu commitversion" CLI.
If this command is not issued within 45 minutes (default) from the time the standby supervisor moves into the "Standby Hot" state, it is assumed that the new active supervisor is not reachable and the entire ISSU process is rolled back to the previous version of the software. The acceptversion is not intended for long-term network operation. It is also important to note that none of the features available on the new version will work yet.
The following actions take place when the command is implemented:
1. The "Rollback Timer" is terminated. This means that the rollback timer is not looked at anymore. Therefore, the system can run in this state for an extended period.
2. The user has an option to abort the ISSU process by issuing the command "issu abortversion."
Aborting the ISSU process now causes the newly active supervisor (B) to fail over to the standby supervisor (A) running the old image and will also cause the rebooting supervisor (B) to load the original image. The issu acceptversion halts the rollback timer and helps ensure the ISSU process is not automatically aborted during the process.
An example of the CLI for implementing the issu acceptversion command is displayed below:
On the "New" active supervisor, one would issue the following command:
4510R-203#issu acceptversion 2
% Rollback timer stopped. Please issue the commitversion command.
Syntax - issu acceptversion active-slot-number
This is the last stage of the ISSU procedure. Once the user is satisfied with the new version of software, this must be committed by issuing the "issu commitversion" command. This command resets the standby supervisor and boots it with a new version of the software (same as the active supervisor). This concludes the ISSU process, and the new version of software is permanently committed on both supervisors. Since this is the conclusion of the ISSU process, the system can not be reverted back to the previous version of the software from this point onward as a part of this upgrade cycle. However, if for any reason users wish to go back to the previous version of the software, they can do so by starting a new upgrade/downgrade process.
The following actions take place if the command is implemented:
1. The standby supervisor (A) is reset and booted with the new version of Cisco IOS Software image.
2. The standby supervisor (A) moves into the "Standby Hot" state in SSO mode and is fully stateful for all clients/applications that are compatible.
3. Both supervisors are moved into "Final State," which is the same as "Initial State."
4. Users can initiate switchovers from this point onward.
An example of the CLI for implementing the issu commitversion command is displayed below:
4510R-203#issu commitversion 1
Syntax - issu commitversion standby-slot-number
ISSU Process: issu abortversion
One can abort the ISSU process at any stage manually (prior to issuing the issu commitversion command) by issuing the exec-level issu abortversion command. The ISSU process also aborts on its own if the software detects a failure.
If a user aborts the process after issuing the issu loadversion command, then the standby supervisor engine is reset and reloaded with the original software.
If the process is aborted after a user enters either the issu runversion or issu acceptversion command, then a second switchover is performed to the new standby supervisor engine that is still running the original software version.
The supervisor engine that had been running the new software is reset and reloaded with the original software version. The command is accepted only in "Load Version" or "Run Version" states. In "Load Version" state, the active supervisor is running an old image and the standby supervisor is running new image.
Syntax - issu abortversion active-slot [active-image-new]
Let me know if you have any questions.

Help Setting Up A Cisco Lab For IOS Upgrade?

Hi.
I've collected quite a few routers and switches over the past few months that have what seems to be corrupted or no IOS. I have a small lab set up to test parts, and I was wondering how I can network them in such a way where I have an active functional network (for testing purposes, not for actual internet use), that I can connect routers or switches to and upgrade or change the IOS version.
I have all the hardware and cabling needed, and I have the Cisco IOS software for the routers I need, I've just never upgraded or changed an IOS on a router or switch before.
I have:
a Cisco 7505 with an RSP4+, 256MB RAM, 16MB Flash, and it's full of the modules that hold the PA cards (I forget what it's called, but I just use it to throw PA cards in to test 8 at a time).
A Cisco 3450 (I believe, 3400 series anyhow) that I believe is 64/16, that again I use for testing.
Two Cisco 2621 64/16, for testing WIC's, VWIC's and NM's.
Two Cisco 2950 series switches, one I'd like to use to actually connect to my LAN already implimented seperatly, and one to connect to this mini lab LAN.
So again, I'm wondering how I can set these up on a small LAN just for testing purposes and so I can just connect a device and upgrade it's IOS. I also need information about the TFTP server and all of that as I haven't been able to find out much info on it.
Thanks in advance for any help :).

Hi
First of all make sure that the flash is enough for IOS you are loading.Here is guide for loading IOS.
(1)Download and install tftp server from www.solarwinds.net
(2)Give IP on ethernet port of router
(3)Give IP on computer which should be in same subnet that of router
(4)Follow the following steps:
Router#copy tftp: flash:
Address or name of remote host []? 192.168.1.67
Source filename []? c1700-k9o3sy7-mz.122-15.T9.bin
Destination filename [c1700-k9o3sy7-mz.122-15.T9.bin]?
Accessing tftp://192.168.1.67/c1700-k9o3sy7-mz.122-15.T9.bin...
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Loading c1700-k9o3sy7-mz.122-15.T9.bin from 192.168.1.67 (via FastEthernet0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 9190488/18380800 bytes]
Verifying checksum... OK (0xF7C5)
9190488 bytes copied in 129.664 secs (71244 bytes/sec)
(5)Reboot and your new IOS is ready.
Regards
JD

Wlc 5508 ios upgrade in ha mode

I am having 2 wlc 5508 in HA mode, and want to upgrade ios from 7.5 to 7.6
Current IOS file status in primary and secondary.
Primary WLC IOS : AIR-CT5500-K9-7-5-102-0.aes
Standby WLC IOS : AIR-CT5500-LDPE-K9-7-5-102-0.aes
HA WLC ios upgrade procedure is when we upgrade ios in primary wlc it will push to standby wlc and if earlier ios version match it will accept it.
ISSUE : If you check in wlc status detail I have given upper both has same ios version but IOS file are different and currently in HA mode and working.
Now I am trying to upgrade IOS it is not allow me to upgrade it.
Giving below error :
TFTP receive complete... extracting components.
Checking Version Built.
Image version check passed.
Informing the standby to start the transfer download process
Waiting for the Transfer & Validation result from Standby.
Standby - Standby receive complete... extracting components.
Standby - Checking Version Built.
Standby - Image version check passed.
Standby - Transfer failure : Upgrade from non LDPE to LDPE software is not allowed.
Please download AIR-CT5500-K9-x-x-x-x.aes image instead.
Transfer & Validation on Standby failed.
Transfer download failed both on Active & Standby, Please retry download
(Cisco Controller) >
Please suggest how I can upgrade IOS in HA mode.

Primary WLC IOS : AIR-CT5500-K9-7-5-102-0.aes
Standby WLC IOS : AIR-CT5500-LDPE-K9-7-5-102-0.aes
This won't work and you'll see from the error message. Your standby WLC has a particular firmware loaded with LDPE enabled. So first, you need to answer if you need LDPE or not.
Both firmwares has to match, including LDPE. If you need LDPE, the your primary has to be loaded with LDPE before you can proceed. If you don't need LDPE, then you need to downgrade the secondary to non-LDPE version before you can proceed.

WS-X6816-GBIC became PwrDown when IOS upgrade to 12.2(18)SXD7

When IOS upgraded from 12.1(13)E8 to 12.2(18)SXD7, one of WS-X6816-GBIC module (in slot5) become PwrDown in show module output but another one (in slot 4) is ok. The only difference I can find is DFC hardware version. Is there any limitation about this ?
IOS 12.2(18)SXD7
------------------ show module ------------------
Mod Ports Card Type Model Serial No.
1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL0752RJBZ
4 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAD05050HGC
5 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAL08186B80
6 0 Switching Fabric Module-136 (Active) WS-X6500-SFM2 SAL0708DF8W
8 0 2 port adapter FlexWAN WS-X6182-2PA SAD073900JL
Mod MAC addresses Hw Fw Sw Status
1 0009.1246.eba8 to 0009.1246.eba9 5.0 7.1(1) 12.2(18)SXD7 Ok
4 0030.f271.1972 to 0030.f271.1981 1.7 12.1(11r)E2 12.2(18)SXD7 Ok
5 000f.f780.2420 to 000f.f780.242f 1.7 Unknown Unknown PwrDown
6 0001.0002.0003 to 0001.0002.0003 1.4 6.1(3) 8.3(0.156)RO Ok
8 000d.650a.15c0 to 000d.650a.15ff 1.6 12.2(18)SXD7 12.2(18)SXD7 Ok
Mod Sub-Module Model Serial Hw Status
1 Policy Feature Card 2 WS-F6K-PFC2 SAL0752RKWF 3.4 Ok
1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 SAL0752RB28 2.6 Ok
4 Distributed Forwarding Card WS-F6K-DFC SAL08249SUD 2.5 Ok
5 Distributed Forwarding Card WS-F6K-DFC SAL081971W0 2.7 PwrDown
Mod Online Diag Status
1 Pass
4 Pass
5 Unknown
6 Pass
8 Pass
The early show module output;
IOS 12.1(13)E8
TANET_PTC_R6K#sh module
Mod Ports Card Type Model Serial No.
1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL0752RJBZ
4 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAD05050HGC
5 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAL08186B80
6 0 Switching Fabric Module-136 (Active) WS-X6500-SFM2 SAL0708DF8W
8 0 2 port adapter FlexWAN WS-X6182-2PA SAD073900JL
Mod MAC addresses Hw Fw Sw Status
1 0009.1246.eba8 to 0009.1246.eba9 5.0 6.1(3) 7.5(0.6)HUB1 Ok
4 0030.f271.1972 to 0030.f271.1981 1.7 12.1(11r)E2 12.1(13)E8, Ok
5 000f.f780.2420 to 000f.f780.242f 1.7 12.1(11r)E2 12.1(13)E8, Ok
6 0001.0002.0003 to 0001.0002.0003 1.4 6.1(3) 7.5(0.6)HUB1 Ok
8 000d.650a.15c0 to 000d.650a.15ff 1.6 12.1(13)E8 12.1(13)E8 Other
Mod Sub-Module Model Serial Hw Status
1 Policy Feature Card 2 WS-F6K-PFC2 SAL0752RKWF 3.4 Ok
1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 SAL0752RB28 2.6 Ok
4 Distributed Forwarding Card WS-F6K-DFC SAL08249SUD 2.5 Ok
5 Distributed Forwarding Card WS-F6K-DFC SAL081971W0 2.7 Ok

Watch the logs as it boots up , my guess there is a problem with the board . We had a brand new card for a 6500 with a problem and the box will power it off if it see's a problem. Ended up RMA'ing the card . Does it show anything when you do a "show diagnostic result all" command ?

Apple iPad 3. BT email not working. Cannot send emails from btconnect SMTP after iOS upgrade. This is the only difference I am aware of. Can anyone help me please.

BT email not working. Cannot send emails from btconnect SMTP after iOS upgrade. This is the only difference I am aware of. Apple iPad 3. Can anyone help me please.

All resolved at last
Deleted the SMTP setting
Recreated the SMTP using the same settings
Able to send emails now
No logic - as usual - just a bug!

In IOS 6 my date format was YYYY-MM-DD. When I switched to IOS 7, it changed to MM-DD-YYYY. How do you change it?

In IOS 6 my date format was YYYY-MM-DD, which is ISO 8601 standard used in Canada. When I switched to IOS 7, it changed to MM-DD-YYYY format which is very confusing as all my cameras etc use YYYY-MM-DD. How do you change it, like one can in OSX?

It appears previous versions of IOS would pick up your preferred date format from your OSX Mac. You can modify that to whatever you like.
Now if you select Canadian or American in IOS 7 you get only MM-DD-YYYY. This is wrong for Canada as the preferred date format here is YYYY-MM-DD, just check your birth or expiry dates on your Ontario Drivers License or OHIP Health Card. Or the date field at the bottom left of any Government of Canada website.
The trouble with using other Country codes is you tend to get their currency codes like € or £ and the terms like yesterday and today in their language.

Since an ios upgrade on my ipod, my device no longer appears in itunes or my computer

Since a recent ios upgrade, I can not locate my Ipod touch 5th generation in iTunes nor in My Computer. I am working with Windows 7. I have uninstalled and reinstalled itunes, quicktime and Apple Mobile Device Support software programs. I have also gone through the on line Apple Trouble shooting support for this problem with no success.
I did have WiFi syncing turned on before the upgrade and now when I go into settings on my iPod, the sync now option is greyed out.
Any other ideas please...

OK, never mind. After all that, a restart of the iPhone fixed it. That should have been the first thing I tried, of course, before posting. Sorry about that!

Switch 3750E IOS upgrade failure

Similar Messages

Maybe you are looking for