Beware of EMC switches sold as Mellanox SX6XXX on eBay

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

cktm57

New Member
Mar 1, 2021
22
1
3
/opt/tms/bin/mellaggra _write_fru 1 0x51 1000 fru_patched.bin

btw do not use `eeprom write` from the U-Boot command line. you will brick your switch
Just wanted to say a huge thank you for the exact syntax: /opt/tms/bin/mellaggra _write_fru 1 0x51 1000 /tmp/fru_patched_new.bin. I had been trying various combinations of addresses and offsets with no success. Your command executed without errors, and cmp -l confirms that the data was written correctly to the EEPROM.
Unfortunately, even with a properly written FRU, the system (both 3.5.1006 and 3.4.0012) still reports the model as 'ppc', and the SX driver loads but doesn't create any IB/net devices. It seems the OS is ignoring the FRU or the profile is stuck.
My next step is to try a clean installation via Manufacturing Environment (MFG), hoping that manufacture.sh will build a fully valid FRU and system profile from scratch on a wiped partition. I'll report back on how that goes. Thanks again for the invaluable help!
 

cktm57

New Member
Mar 1, 2021
22
1
3
upgrade to 3.6.8012 or do a factory reset again
@freebsd1976 Thanks again for the offset tip—it was the key to finally getting the FRU written correctly, which felt like a huge win.
Just to close the loop on the upgrade suggestion: I tried a direct upgrade to 3.6.8012 with the newly written FRU, but unfortunately, it still resulted in the cant parse system profile error and a boot loop. It seems my unit is particularly stubborn.
No worries, though—I've got U-Boot access and am falling back to a clean MFG install as the next step. Appreciate all the help!
 

Freebsd1976

Active Member
Feb 23, 2018
430
78
28
get shell access and try this first
touch /etc/.firstboot
touch /var/opt/tms/.firstmfg
then reboot switch
 
Last edited:

cktm57

New Member
Mar 1, 2021
22
1
3
get shell access and try this first
touch /etc/.firstboot
touch /var/opt/tms/.firstmfg
then reboot switch
@freebsd1976 Thank you for the suggestion! The combination of touch /etc/.firstboot and /var/opt/tms/.firstmfg is a great trick to force a clean configuration run. In my case, I had already managed to stabilize the system by performing a clean installation via MFG after unlocking U-Boot, but I've noted this method down for future reference. I appreciate you taking the time to share it!
 

cktm57

New Member
Mar 1, 2021
22
1
3
Hi everyone,

I'm trying to activate the Fabric Inspector (UFM) via the web interface on an SX6012 running MLNX-OS 3.6.8012. This is not specific to a converted EMC model—I've tested the same approach on both a genuine Mellanox SX6012 and a converted one, and the result is identical.

The goal is to get the Fabric Inspector working without an official NVIDIA/Mellanox UFM license.

Here’s exactly what I’ve tried on both switches:
1. Generating a new EFM_SX license key that includes UFM options via genlicense:
/opt/tms/bin/genlicense 2 EFM_SX m210n%0x9 -o 53 true -o 51 true -o 58 true -o 55 200
This key is accepted but shows as 'Invalid'. The 'Max num ufm ports supported: 200' parameter is recognized as (ok).

2. Manually setting the UFM activation flags in the configuration database:
/opt/tms/bin/mddbreq /config/db/initial set modify - /mlx/license/state/ufm_feature_active bool true
/opt/tms/bin/mddbreq /config/db/initial set modify - /mlx/license/state/ufm_ports_limit uint16 200
(followed by 'configuration write' and a full reload)

3. Verified that the ufma process is running (ps aux shows /opt/tms/bin/ufma active).

After all these steps, the 'Fabric Inspector' section in the web UI remains greyed out and inactive, even after restarting the webserver and rebooting the switch.
Since the same behavior occurs on a genuine, non-converted switch, it seems the issue is not related to the EMC conversion itself.

Has anyone successfully gotten Fabric Inspector to work on 3.6.8012 using only locally generated keys and configuration changes? Is a separate UFM installation package (e.g., UFM-SX-*.img) required, or is there another hidden flag that needs to be set?

Any advice or fresh ideas would be much appreciated!
 

cktm57

New Member
Mar 1, 2021
22
1
3
Hi everyone,

I'm trying to activate the Fabric Inspector (UFM) via the web interface on an SX6012 running MLNX-OS 3.6.8012. This is not specific to a converted EMC model—I've tested the same approach on both a genuine Mellanox SX6012 and a converted one, and the result is identical.

The goal is to get the Fabric Inspector working without an official NVIDIA/Mellanox UFM license.

Here’s exactly what I’ve tried on both switches:
1. Generating a new EFM_SX license key that includes UFM options via genlicense:
/opt/tms/bin/genlicense 2 EFM_SX m210n%0x9 -o 53 true -o 51 true -o 58 true -o 55 200
This key is accepted but shows as 'Invalid'. The 'Max num ufm ports supported: 200' parameter is recognized as (ok).

2. Manually setting the UFM activation flags in the configuration database:
/opt/tms/bin/mddbreq /config/db/initial set modify - /mlx/license/state/ufm_feature_active bool true
/opt/tms/bin/mddbreq /config/db/initial set modify - /mlx/license/state/ufm_ports_limit uint16 200
(followed by 'configuration write' and a full reload)

3. Verified that the ufma process is running (ps aux shows /opt/tms/bin/ufma active).

After all these steps, the 'Fabric Inspector' section in the web UI remains greyed out and inactive, even after restarting the webserver and rebooting the switch.
Since the same behavior occurs on a genuine, non-converted switch, it seems the issue is not related to the EMC conversion itself.

Has anyone successfully gotten Fabric Inspector to work on 3.6.8012 using only locally generated keys and configuration changes? Is a separate UFM installation package (e.g., UFM-SX-*.img) required, or is there another hidden flag that needs to be set?

Any advice or fresh ideas would be much appreciated!
Hi everyone,

Just wanted to share a quick but important update for anyone struggling with genlicense on version 3.6.8012. Contrary to some older posts suggesting the secret word changes with each release, I can confirm that the classic word m210n%0x9 (ROT18 of z7y5a%5k4) still works perfectly on this version to generate valid license keys.

Took a bit of digging, but happy to report it's still functional. Hope this saves someone else the trouble.
 
  • Like
Reactions: blunden