SHA1 Checksum for Physical Switch Binaries

  • 17 January 2017
  • 10 replies

I'm having a slight issue when I try an ONIE install on physical switch via USB - the SHA1 checksums aren't being validated and this is blocking the install.

Expected: 606ea9ad5494d058383be079972d3eece1ae9223
Actual: 2bbdad7812c4455b568c0e45f878c08ee8587001

My MD5 checks out against Cumulus's, so I know I have a good binary.

This is not currently impeding my testing, as I can use the VX, but I have seen this issue a few times with both v3.1.1 and v3.2.0, so I'd like to throw it out there.

Any advice would be appreciated - I hope I'm not being too thick. 🙂

10 replies

Userlevel 5

Thank you for bringing this to our attention. I would recommend opening an official ticket with support on this issue as it could be a sign of a greater issue at hand.
Userlevel 2
Hi Christopher,

Would like to clarify a couple of things. When are you calculating the MD5 checksum? After downloading the image but before copying to the USB drive?

I suspect this may be a case where the downloaded file is fine, but something has been corrupted when copying to the USB. During the ONIE install process, the SHA1 checksum of the binary will be calculated and verified against the expected. This is what is failing for you.

A further data point would be to calculate the md5sum on the binary from ONIE on the switch. If you reboot the switch, select ONIE, and then select Rescue. This will boot into ONIE without running the discovery process, so the image installation will not automatically kick off.

The USB will likely need to be manually mounted. The output of blkid should help determine the correct target to mount:
ONIE:/ # blkid  /dev/sdb1: LABEL="1031_003" UUID="C13C-1601"  /dev/sda2: LABEL="ONIE-BOOT" UUID="a0c5176b-2373-4114-8942-03178f67dbe2"  /dev/sda4: LABEL="CL-SYSTEM" UUID="d6f6db72-206b-41a7-accc-f2071a46e7e6"  /dev/sda3: LABEL="CL-BOOT" UUID="cf4ee7c5-5e71-47cf-9cad-5bf8c5893bf0"
In this case, the USB is /dev/sdb1, and can be mounted with the following commands:
ONIE:/ # mkdir /mnt/usb  ONIE:/ # mount /dev/sdb1 /mnt/usb/
Now the md5sum can be calculated:
ONIE:/ # md5sum /mnt/usb/  
Does this match with the MD5 from the website?
Thanks for the quick responses gentlemen. Lets work to validate this is indeed an issue before opening a full support ticket for it.

I'm attaching a screenshot from a hashing utility I'm running showing the binary at different states.
  • The first is a fresh download, not moved or copied. The MD5 hash matches the download site's one - as expected.
  • The second is after a copy to flash drive.
  • The third is after renaming on that flash drive for an ONIE install.

I'm seeing the hash change with each action, despite the binary being unchanged. This is occurring with binary images downloaded on two different laptops, in both v3.1.1 and v3.2, and when copied to different flash drives.

When manually mounted to the switch hardware, I'm getting the MD5 hash seen below, also incorrect, but matching the renamed binary hash when I create the flash drive:

I hope this helps to clarify. Please let me know if there is any additional information you'd like me to take a look at.
Userlevel 2
    What is the size and format of the USB drives which are being used? Which OS is running on the laptops which have been tried? What method is being used to copy the file to the USB and rename? Is there any virus scan or other software running on the hosts, which may inspect the file and it's contents?
[list] What is the size and format of the USB drives which are being used? Which OS is running on...I used a 4GB flash drive, formatted as FAT32. OSes were Windows 7 & 10 enterprise. Using Windows Explorer for the file copy & rename. Running MacAfee Endpoint Protection....which does whole disk scans on local hard drives, but not removable media.
Userlevel 3
Hi Christopher,

I just did this on my mac, and see no issues. I think the problem may be in the "utilities" you are using. I am using a Mac and iTerm2 application for the command line.

Here are the steps I did, verifying the md5sum at each step (raw output below):
1) Downloaded the file and verified md5.
2) Formatted my 4G USB drive as FAT_32 using diskutil.
3) Copied the file to the mountpoint.
4) Renamed the file.

In your reply, please be this detailed in explaining how you are trying to set this up. As you can see in the output below, each step is verified, and in the end, the switch is booting the NOS from the USB.
Note: It is best to use command line tools for this, rather than "utilities". Worst case, create a vagrant VM of Debian Jessie, and use that.

# 3.2 ARM Image downloaded using chrome browser from  # MD5 matches webpage, and initial sha1 also run.  jguy@jguy-mac ~/Downloads $ md5 cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin  MD5 (cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin) = f64c0f6592753a6b6ba6276533ef6423    jguy@jguy-mac ~/Downloads $ shasum cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin  2bbdad7812c4455b568c0e45f878c08ee8587001  cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin    #format USB disk for FAT32 with MBR (not GPT)  jguy@jguy-mac ~/Downloads $ diskutil partitionDisk /dev/disk2 1 MBR FAT32 CL R  Started partitioning on disk2 ONIE_RECOVERY  Unmounting disk  Creating the partition map  Waiting for partitions to activate  Formatting disk2s1 as MS-DOS (FAT32) with name CL  512 bytes per physical sector  /dev/rdisk2s1: 7860832 sectors in 982604 FAT32 clusters (4096 bytes/cluster)  bps=512 spc=8 res=32 nft=2 mid=0xf8 spt=32 hds=255 hid=2 drv=0x80 bsec=7876222 bspf=7677 rdcl=2 infs=1 bkbs=6  Mounting disk  Finished partitioning on disk2  /dev/disk2 (external, physical):     #:                       TYPE NAME                    SIZE       IDENTIFIER     0:     FDisk_partition_scheme                        *4.0 GB     disk2     1:                 DOS_FAT_32 CL                      4.0 GB     disk2s1    # Check the USB drive mountpoint...looks good.  jguy@jguy-mac ~/Downloads $ mount | grep /dev/disk2s1  /dev/disk2s1 on /Volumes/CL (msdos, local, nodev, nosuid, noowners)    #copy the file to the USB disk and verify the file is there (takes about 35 sec)  jguy@jguy-mac ~/Downloads $ cp cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin /Volumes/CL/  jguy@jguy-mac ~/Downloads $ ls -l /Volumes/CL/  -rwxrwxrwx@ 1 jguy  staff  171139102 Jan 18 14:34 cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin    # verification   jguy@jguy-mac ~/Downloads $ md5 /Volumes/CL/cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin  MD5 (/Volumes/CL/cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin) = f64c0f6592753a6b6ba6276533ef6423    # rename file to work with ONIE discovery  jguy@jguy-mac ~/Downloads $ mv /Volumes/CL/cumulus-linux-3.2.0-bcm-armel-1481677210.43ab48fz7c185f5.bin /Volumes/CL/onie-installer-arm  jguy@jguy-mac ~/Downloads $ ls -l /Volumes/CL/  -rwxrwxrwx@ 1 jguy  staff  171139102 Jan 18 14:34 onie-installer-arm    # verification   jguy@jguy-mac ~/Downloads $ md5 /Volumes/CL/onie-installer-arm  MD5 (/Volumes/CL/onie-installer-arm) = f64c0f6592753a6b6ba6276533ef6423    jguy@jguy-mac ~/Downloads $ shasum /Volumes/CL/onie-installer-arm  2bbdad7812c4455b568c0e45f878c08ee8587001  /Volumes/CL/onie-installer-arm
### Console to 4610_54p, with USB inserted. ###...
Please press Enter to activate this console. Info: eth0: Checking link... etc_watchdog can't access PHY, forcing link up
et0 Link Up: 1000FD
Info: Trying DHCPv4 on interface: eth0
ONIE: Using DHCPv4 addr: eth0: /
ONIE: Starting ONIE Service Discovery
etc_watchdog can't access PHY, forcing link up
et0 Link Up: 1000FD
EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240)
EXT2-fs (sda2): error: couldn't mount because of unsupported optional features (240)
ONIE: Executing installer: file://dev/sdb1/onie-installer-arm
Verifying image checksum ...OK.
Verifying image architecture ...OK.
Verifying system ram ...OK.
Preparing image archive ... OK.
Setting up installer ...Info: The full install log is located at /tmp/ei_runlog.XXVN6d45
Please reboot to start installing OS.
ONIE: NOS install successful: file://dev/sdb1/onie-installer-arm
ONIE: Rebooting...
discover: installer mode detected.
Stopping: discover...start-stop-daemon: warning: killing process 334: No such process
Stopping: dropbear ssh daemon... done.
Stopping: telnetd... done.
Stopping: syslogd... done.
Info: Unmounting kernel filesystems
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
Restarting system.
Looks like it all works here...
Hi Christopher,

I just did this on my mac, and see no issues. I think the problem may be in the ...
I'm not entirely convinced its the utilities verifying the hashes are incorrect, but I do think it could be related to some Windows setting enforced by our InfoSec group or perhaps our security software. I'll try and create an image via a Linux VM cmd line and see if that yields different results. Fingers crossed!
Hi Christopher,

I just did this on my mac, and see no issues. I think the problem may be in the ...
Tried downloading, copying, renaming all from an isolated Linux VM - no problems whatsoever. I'm thinking this might be a case of security software interference.

While a bit frustrating, its definitely not Cumulus' fault and definitely not insurmountable. Thanks for the patience and help gentlemen.
Userlevel 1
Hi Christopher,

I just did this on my mac, and see no issues. I think the problem may be in the ...
"Security Software" that modifies files when copying to external media is behaving more like a virus than anything else ...
Userlevel 3
Hi Christopher,

I just did this on my mac, and see no issues. I think the problem may be in the ...
LOL...Glad it is working Christopher! We are always happy to help.