I had to RMA the switch. These things are super buggy. They have an engineering fix in the works, but they're still like beta switches. Once you get them setup...don't change anything...but I'm now ONLY upgrading firmware on them from the console. I had an X1026P brick itself on boot. With random PoE errors on initial boot. Firmware .80 and firmware .70 are pretty *** too.
So if you can't boot it on reboot, you'll have to RMA it to Dell and hope they have them in stock.
We have had six X1026P switches fail after upgrading firmware to the .80 version. They will work for about a day and then become unmanageable. It took me 6 hours to get a tech-support dump for support. Only way to use them is to downgrade firmware to .64
Not sure the X series switches ready for prime time yet
did not know 3.0.0.82 is out, my contact Dell told me they wanted me to try 3.0.0.81 firmware and I have updated about six switches so far with no issues yet.
I upgraded my X1026P to .81 without issue. I have ONLY been updating them via the console and TFTP. I don't trust the web interface. I hasn't seen that .82 was released. I also always update the boot-code even if it's the same version as on the device. The new note in the firmware update is interesting and should be noted:
"FW Release 3.0.0.81 and later (3.0.0.82) requires both firmware-image and boot-code update on X10xx Series switches. After X10xx Series switches upgraded to firmware version 3.0.0.81 and later along with the boot-code version 1.0.0.21, the switches will automatically update CPLD to the latest version (X1018/P: Rev07, X1026/P: Rev08, X1052/P: Rev0B) on boot up. This CPLD update will take at least 10 to 15 minutes to complete. If switch seems to become unresponsive, please check the System LED at the front. If System LED is blinking green, the switch is still going through the system upgrade and should NOT be reloaded/power cycled. Power cycling the switch during the CPLD update is likely to cause the switch to become inoperable and require switches to be RMA'ed for factory re-installation of the firmware."
I've installed the .82 update on 11 different X1052 - 5 of them worked, 6 of them are now bricked...
I initially used the Web interface on the first 2 switches and it worked fine. Next 2 switches bricked, so started using the CLI and TFTP. Next 3 switch bricked. The CLI messages and the LED pattern wasn't even consistent across the bricked switches.
First switch just sat with a blinking Green light for over an hour, CLI said:
The third one, same messages as the first, but after a minute the light turned blue and it never made any progress.
The 4th one I tried, seemed like it bricked (started updating, sat there for a long while, then eventually LED was solid blue), but by some miracle it came up after I finally power cycled it.
The 5th switch worked perfectly.
I also tried 1 switch with the .81 firmware. Blinked green for a few seconds, then turned blue on it's own and it's been sitting like that for hours now).
What a terrible firmware update...50/50 chance of bricking
Okay, thank you for following up, clarifying, acknowledging the issue, and assuring people that a fix is in the works.
You might think of changing the update to Optional or Experimental (instead of Recommended), or put something on the update download site to clarify that people should only upgrade if they are having issues that are addressed in the fix or need one of the features. Otherwise people will continue to download and install the update as part of a routine maintenance or initial setup without understanding the risks.
So, I don't normally waste my time to call someone out...but this is such a useless response - all you did was repeat the instructions that come with the firmware update. Most of the issues people are listing in this thread clearly state that they followed the instructions and took all the precautions. People even went to the trouble to try and diagnose the problem by giving all the details. Some people even tried to see if different upgrade steps would make a difference and pretty much everyone has made specific reference to the amount of time waited (which has always been way in excess of the 10-15 minutes).
What about the cases I presented that performed completely different that the scenario in the instructions? In one case, where I followed the instructions EXACTLY (set static ip -> tftp firmware -> tftp bootcode -> reload), during the reload, green light flashed for about 5 minutes, then turned solid blue completely on it's own (I watched it very carefully during this and did not touch it at all). I then left the switch running like this overnight and it was still solid blue in the morning and completely unresponsive. On another switch, exact same steps, but this switch stayed flashing green for OVER 3 HOURS - I left it sitting overnight and it was still flashing green the next morning. And what about the various logs and error messages people have upload that showed they followed all the steps but it still failed?
I have updated 17 switches so far - 9 OF THEM ARE NOW INOPERABLE. I always followed the instructions and always waited AT LEAST 1 HOUR (usually 2-3 HOURS or OVERNIGHT) before power cycling them. I had one switch that actually did come back to life after power cycling and it finished the update, so I don't even know what it was doing that whole time it sat there stuck with the solid blue light.
There is clearly a SERIOUS issue with this firmware update and rather than acknowledging the issue you pretend like all these dozens of complaints are just the result of people who didn't read the instructions...I used to think very highly of Dell switches, but that is no longer the case and is primarily due to the pathetic responses from the support team on theses forums (why even bother responding if you're not going to say anything useful).
In our case we had so many issues with the X1026P & X1018P switches on firmware .80
Units would become unable to manage and in other cases the 18 port switches would stop working except for management only. In these cases we had no choice but to upgrade to .81 or revert back to .6x firmware
What about the cases I presented that performed completely different that the scenario in the instructions? In one case, where I followed the instructions EXACTLY (set static ip -> tftp firmware -> tftp bootcode -> reload)
The instructions I am reading say: update bootcode -> reboot -> update firmware -> reboot. Have the instructions been changed recently or did you mix it up in your post?
There's actually conflicting instructions in that regard. Yes, the UI upgrade instructions tell you to follow that ordering. However, the release notes specifically say to use the CLI upgrade instructions.
Administrators upgrading Dell Networking X1008, X1008P, X1018, X1018P, X1026, X1026P, X1052, X1052P switches to firmwareimage version 3.0.0.82 and Boot-code/PROM version 1.0.0.21 MUST follow the upgrade instructions documented in the “X10xx_X4012_CLI_Software_Upgrade_Instructions.pdf” procedure. Failure to follow the procedures described in that document when upgrading firmware may result in an inoperable switch!
The CLI upgrade instructions follow these steps:
1. Change the switch mode (X1008/P, X1018/P and X1026/P) from factory-default “Unmanaged” to “Managed” mode by pressing the “MODE” button for more than 7 seconds. X1052/P switch is in “Managed” mode by default.
2. Ensure that an IP address is assigned to at least one port on the switch.
3. Enter console#copy tftp://{tftp address}/{file name} image to copy the software to the switch.
4. Enter console#copy tftp://{tftp address}/{file name} boot to copy the boot software to the switch.
5. Enter console# show bootvar to verify which image is active.
6. Type reload.
The very first switch I upgraded using the UI instructions and it worked just fine. It was the second switch, where I follow the same UI instructions again, where I had my first bricked X1052 switch. Since then I've tried every combination of procedures (UI and CLI) and there doesn't seem to be any rhyme or reason as to what causes the upgrade to either fail or complete successfully.
Still happening, we ordered 3 switches, and the first 2 upgraded fine to 3.0.0.82 via the UI instructions.
3rd switch bricked. So Dell RMA'd. Which took 2 weeks. Just got the replacement today and tried to upgrade the firmware (because there are functions that I need don't seem to work in the .64 it shipped with) and now it's bricked too.
I dunno man, it seems like maybe Dell should take down the bad firmware? I'm going to .80 on the replacement for my replacement I guess.
swhitehead30
2 Posts
0
September 10th, 2016 20:00
Having the same issue and can't get the console to come up regardless. Any thoughts? Light is solid blue after firmware update
Dkalmick
11 Posts
0
September 12th, 2016 01:00
I had to RMA the switch. These things are super buggy. They have an engineering fix in the works, but they're still like beta switches. Once you get them setup...don't change anything...but I'm now ONLY upgrading firmware on them from the console. I had an X1026P brick itself on boot. With random PoE errors on initial boot. Firmware .80 and firmware .70 are pretty *** too.
So if you can't boot it on reboot, you'll have to RMA it to Dell and hope they have them in stock.
pierredubuis
3 Posts
0
September 24th, 2016 07:00
We have had six X1026P switches fail after upgrading firmware to the .80 version. They will work for about a day and then become unmanageable. It took me 6 hours to get a tech-support dump for support. Only way to use them is to downgrade firmware to .64
Not sure the X series switches ready for prime time yet
kslim
4 Posts
0
November 14th, 2016 06:00
Me too, any workaround?
I have upgraded boot code to 1.0.0.21.
and it bricked when i upgrade the firmware to 3.0.0.82.
pierredubuis
3 Posts
0
November 14th, 2016 09:00
did not know 3.0.0.82 is out, my contact Dell told me they wanted me to try 3.0.0.81 firmware and I have updated about six switches so far with no issues yet.
Dkalmick
11 Posts
0
November 14th, 2016 10:00
I upgraded my X1026P to .81 without issue. I have ONLY been updating them via the console and TFTP. I don't trust the web interface. I hasn't seen that .82 was released. I also always update the boot-code even if it's the same version as on the device. The new note in the firmware update is interesting and should be noted:
"FW Release 3.0.0.81 and later (3.0.0.82) requires both firmware-image and boot-code update on X10xx Series switches. After X10xx Series switches upgraded to firmware version 3.0.0.81 and later along with the boot-code version 1.0.0.21, the switches will automatically update CPLD to the latest version (X1018/P: Rev07, X1026/P: Rev08, X1052/P: Rev0B) on boot up. This CPLD update will take at least 10 to 15 minutes to complete. If switch seems to become unresponsive, please check the System LED at the front. If System LED is blinking green, the switch is still going through the system upgrade and should NOT be reloaded/power cycled. Power cycling the switch during the CPLD update is likely to cause the switch to become inoperable and require switches to be RMA'ed for factory re-installation of the firmware."
w8ing4u
1 Rookie
•
23 Posts
0
December 1st, 2016 15:00
I've installed the .82 update on 11 different X1052 - 5 of them worked, 6 of them are now bricked...
I initially used the Web interface on the first 2 switches and it worked fine. Next 2 switches bricked, so started using the CLI and TFTP. Next 3 switch bricked. The CLI messages and the LED pattern wasn't even consistent across the bricked switches.
First switch just sat with a blinking Green light for over an hour, CLI said:
Updating CPLD firmware version....................Second switch did the same thing, but a different CLI message:
Updating CPLD firmware version....................FAIL - Programming error code 6.
Running again...
Updating CPLD firmware version....................
The third one, same messages as the first, but after a minute the light turned blue and it never made any progress.
The 4th one I tried, seemed like it bricked (started updating, sat there for a long while, then eventually LED was solid blue), but by some miracle it came up after I finally power cycled it.
The 5th switch worked perfectly.
I also tried 1 switch with the .81 firmware. Blinked green for a few seconds, then turned blue on it's own and it's been sitting like that for hours now).
What a terrible firmware update...50/50 chance of bricking
gcs.wayman
1 Message
0
December 8th, 2016 08:00
Any fix in sight? I can confirm that the same issue exists with firmware 3.00.82
Downloaded Driver v3.0.0.82, A07: http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=4JTC9
Raw unedited capture of my console session where I upgraded the boot code and firmware image of a Dell X1052P switch.
Putty USB Console Session
User Name:
User Name:admin
Password:
authentication failed
press ENTER key to retry authentication
User Name:admin
Password:*****
console#
console#
console#sh ver
SW version 3.0.0.64 ( date 25-Feb-2015 time 09:05:11 )
Boot version 1.0.0.14 ( date 03-Dec-2014 time 15:04:07 )
HW version 00.00.03
console#
console#
console#
console#
console#
console#
console#
console#sh flash
% Unrecognized command
console#sh flash
% Unrecognized command
console#dir
Directory of flash:
File Name Permission Flash Size Data Size Modified
------------------- ---------- ---------- --------- -----------------------
aaafile.prv -- 262080 -- 01-Oct-2006 14:59:54
debug rw 65520 65520 01-Oct-2006 15:00:31
dhcpsn.prv -- 65520 -- 01-Oct-2006 15:00:31
directry.prv -- 65520 -- 01-Oct-2006 15:00:31
image-1 rw 11509623 11509623 01-Oct-2006 09:08:02
image-2 rw 11509623 11509623 01-Oct-2006 17:21:33
startup-config rw 1048320 31 01-Oct-2006 09:05:45
syslog2.sys r- 131040 -- 01-Oct-2006 15:00:31
Total size of flash: 32899072 bytes
Free size of flash: 8241826 bytes
console#copy tftp
running-config Copy into (merge with) the current running
configuration file.
-- Only from a TFTP server
Example: #copy tftp://10.0.0.9/commands-file
running-config
startup-config Copy to the startup configuration file.
-- Only from another configuration file, or a TFTP
server
Example: #copy running-config startup-config
flash:// Copy to a file on the flash memory (flash://filename)
image Copy to the non-active software image file.
-- Only from another image file, Xmodem or a TFTP
Example: #copy tftp://10.1.2.3/my_image.dos image
boot Copy to the BOOT file.
-- Only from Xmodem or a TFTP server
Example: #copy tftp://10.1.2.3/my_boot.rfb boot
null: Copy to null destination (do the copy, but discard any
result).
Example: #copy startup-config null:
tftp:// Destination URL (tftp://ip address/filename) of a file
to upload to a TFTP network server.
Example: #copy image t10.1.2.3/saved-image-file
flash://startup-config Copy from a file on the flash memory
(flash://startup-config)
console#copy tftp
User Name:admin
Password:*****
console#copy t192.168.12.141/.../01-Oct-2006 09:31:01 %TFTP-N-TIM ERSEND: Session is closed after timeout is expired
console#copy t192.168.12.141/.../x10xx_boot-10021.rfb boot
01-Oct-2006 09:31:30 %COPY-I-FILECPY: Files Copy - source URL t192.168.12. 141/x10xx-30082/x10xx_boot-10021.rfb destination URL flash://BOOT
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!
01-Oct-2006 09:31:38 %COPY-N-TRAP: The copy operation was completed successfully
Copy: 524304 bytes copied in 00:00:08 [hh:mm:ss]
console#show bootvar
Image Filename Version Date Status
----- --------- --------- --------------------- -----------
1 image-1 3.0.0.64 25-Feb-2015 09:05:11 Active*
2 image-2 3.0.0.64 25-Feb-2015 09:05:11 Not active
"*" designates that the image was selected for the next boot
console#copy t192.168.12.141/.../x10xx_boot-10021.rfb boot
01-Oct-2006 09:32:52 %COPY-I-FILECPY: Files Copy - source URL t192.168.12. 141/x10xx-30082/x10xx_boot-10021.rfb destination URL flash://BOOT
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!
01-Oct-2006 09:33:00 %COPY-N-TRAP: The copy operation was completed successfully
Copy: 524304 bytes copied in 00:00:08 [hh:mm:ss]
console#dir
Directory of flash:
File Name Permission Flash Size Data Size Modified
------------------- ---------- ---------- --------- -----------------------
aaafile.prv -- 262080 -- 01-Oct-2006 14:59:54
debug rw 65520 65520 01-Oct-2006 15:00:31
dhcpsn.prv -- 65520 -- 01-Oct-2006 15:00:31
directry.prv -- 65520 -- 01-Oct-2006 15:00:31
image-1 rw 11509623 11509623 01-Oct-2006 09:08:02
image-2 rw 11509623 11509623 01-Oct-2006 17:21:33
startup-config rw 1048320 31 01-Oct-2006 09:05:45
syslog1.sys r- 131040 -- 01-Oct-2006 09:29:46
syslog2.sys r- 131040 -- 01-Oct-2006 09:29:46
Total size of flash: 32899072 bytes
Free size of flash: 8110786 bytes
console#copy t192.168.12.141/.../x10xx_30082.ros image
01-Oct-2006 09:33:47 %COPY-I-FILECPY: Files Copy - source URL t192.168.12. 141/x10xx-30082/x10xx_30082.ros destination URL flash://image
01-Oct-2006 09:33:47 %TFTP-A-TftpRxERROR: An error message was received: 1
01-Oct-2006 09:33:47 %COPY-W-TRAP: The copy operation has failed
Copy: Abort from tftp server - file not found
console#copy t192.168.12.141/.../x10xx-30082.ros image
01-Oct-2006 09:34:08 %COPY-I-FILECPY: Files Copy - source URL t192.168.12. 141/x10xx-30082/x10xx-30082.ros destination URL flash://image
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!01-Oct-2006 09:36:47 %COPY-N-TRAP: The copy operation was completed successfully
!
Copy: 11519908 bytes copied in 00:02:39 [hh:mm:ss]
console#sh bootvar
Image Filename Version Date Status
----- --------- --------- --------------------- -----------
1 image-1 3.0.0.64 25-Feb-2015 09:05:11 Active
2 image-2 3.0.0.82 03-Nov-2016 17:20:11 Not active*
"*" designates that the image was selected for the next boot
console#reload
You haven't saved your changes. Are you sure you want to continue ? (Y/N) N
console#copy run start
Overwrite file [startup-config].... (Y/N) ?Y
01-Oct-2006 09:37:04 %COPY-I-FILECPY: Files Copy - source URL running-config destination URL flash://startup-config
01-Oct-2006 09:37:10 %COPY-N-TRAP: The copy operation was completed successfully
Copy succeeded
console#reload
This command will reset the whole system and disconnect your current session. Do you want to continue ? (Y/N) Y
Shutting down ...
Shutting down ...
Shutting down ...
Resetting local unit
**************************************************
***************** SYSTEM RESET *****************
**************************************************
Boot1 Checksum Test...............................PASS
Boot2 Checksum Test...............................PASS
Flash Image Validation Test.......................PASS
Updating CPLD firmware version....................
Waited 1 hour, console did not make any progress
Disconnected console; came back 16 hours; solid blue indicator on switch.. no progress.
Attempted multiple power cycles; solid blue light; switch does not boot.
w8ing4u
1 Rookie
•
23 Posts
0
December 13th, 2016 07:00
Okay, thank you for following up, clarifying, acknowledging the issue, and assuring people that a fix is in the works.
You might think of changing the update to Optional or Experimental (instead of Recommended), or put something on the update download site to clarify that people should only upgrade if they are having issues that are addressed in the fix or need one of the features. Otherwise people will continue to download and install the update as part of a routine maintenance or initial setup without understanding the risks.
w8ing4u
1 Rookie
•
23 Posts
0
December 13th, 2016 07:00
So, I don't normally waste my time to call someone out...but this is such a useless response - all you did was repeat the instructions that come with the firmware update. Most of the issues people are listing in this thread clearly state that they followed the instructions and took all the precautions. People even went to the trouble to try and diagnose the problem by giving all the details. Some people even tried to see if different upgrade steps would make a difference and pretty much everyone has made specific reference to the amount of time waited (which has always been way in excess of the 10-15 minutes).
What about the cases I presented that performed completely different that the scenario in the instructions? In one case, where I followed the instructions EXACTLY (set static ip -> tftp firmware -> tftp bootcode -> reload), during the reload, green light flashed for about 5 minutes, then turned solid blue completely on it's own (I watched it very carefully during this and did not touch it at all). I then left the switch running like this overnight and it was still solid blue in the morning and completely unresponsive. On another switch, exact same steps, but this switch stayed flashing green for OVER 3 HOURS - I left it sitting overnight and it was still flashing green the next morning. And what about the various logs and error messages people have upload that showed they followed all the steps but it still failed?
I have updated 17 switches so far - 9 OF THEM ARE NOW INOPERABLE. I always followed the instructions and always waited AT LEAST 1 HOUR (usually 2-3 HOURS or OVERNIGHT) before power cycling them. I had one switch that actually did come back to life after power cycling and it finished the update, so I don't even know what it was doing that whole time it sat there stuck with the solid blue light.
There is clearly a SERIOUS issue with this firmware update and rather than acknowledging the issue you pretend like all these dozens of complaints are just the result of people who didn't read the instructions...I used to think very highly of Dell switches, but that is no longer the case and is primarily due to the pathetic responses from the support team on theses forums (why even bother responding if you're not going to say anything useful).
pierredubuis
3 Posts
0
December 13th, 2016 09:00
In our case we had so many issues with the X1026P & X1018P switches on firmware .80
Units would become unable to manage and in other cases the 18 port switches would stop working except for management only. In these cases we had no choice but to upgrade to .81 or revert back to .6x firmware
Fortunalely we had no issues updating to .81
stefan.fleischm
1 Message
0
December 13th, 2016 20:00
The instructions I am reading say: update bootcode -> reboot -> update firmware -> reboot. Have the instructions been changed recently or did you mix it up in your post?
w8ing4u
1 Rookie
•
23 Posts
0
December 14th, 2016 10:00
There's actually conflicting instructions in that regard. Yes, the UI upgrade instructions tell you to follow that ordering. However, the release notes specifically say to use the CLI upgrade instructions.
The CLI upgrade instructions follow these steps:
The very first switch I upgraded using the UI instructions and it worked just fine. It was the second switch, where I follow the same UI instructions again, where I had my first bricked X1052 switch. Since then I've tried every combination of procedures (UI and CLI) and there doesn't seem to be any rhyme or reason as to what causes the upgrade to either fail or complete successfully.
Nuclear_Weapon
3 Posts
0
February 8th, 2017 14:00
We are experiencing this issue as well, add 2 more bricked switches to the count...
Does anyone knows which version is safe to upgrade to? Im getting a replacement tomorrow.
cdog2
1 Message
0
February 21st, 2017 14:00
Still happening, we ordered 3 switches, and the first 2 upgraded fine to 3.0.0.82 via the UI instructions.
3rd switch bricked. So Dell RMA'd. Which took 2 weeks. Just got the replacement today and tried to upgrade the firmware (because there are functions that I need don't seem to work in the .64 it shipped with) and now it's bricked too.
I dunno man, it seems like maybe Dell should take down the bad firmware? I'm going to .80 on the replacement for my replacement I guess.