Hash Checking Rare Tips - Wizards Corner

wizardfromoz

Administrator
Staff member
Gold Supporter
Joined
Apr 30, 2017
Messages
9,976
Reaction score
8,876
Credits
45,262
AFTER THE EVENT

eg checking a USB stick after the .iso has been burned -

BACKGROUND

https://www.linux.org/threads/installing-lm-on-a-ssd.13200/page-3#post-45796

Subject Distro is Linux Mint 18.2 ‘Sonya’ 64-bit.

.iso is linuxmint-18.2-cinnamon-64bit.iso

For the User, this might be residing in eg /home/<yourusername>/Downloads

In my case in the Garage on the Acer -

cd /media/chris/Loaddowns/Downloads/64-bit-iso/

So for the User, likely

Code:
cd Downloads

FROM TERMINAL

First we need to establish the size of the Linux .iso – my File Manager, Nemo, says it is 1.7 GB but we need this in Linux-readable terms.

STEP 1

Where the .iso is stored, I enter the following command, and the numeric output is returned.

Code:
stat -c '%s' linuxmint-18.2-cinnamon-64bit.iso

1676083200

That sounds reasonable.

STEP 2

Your USB stick (or DVD for that matter, output will then differ) should be in place, or if not, insert it now.

Code:
df

,,, tells me my Drive & Partition information, in this case, my bottom line tells me


/dev/sdb1

The df output tells me that my stick contains 1636800 1KB blocks. This is a 16GB stick, but that does not matter, because the burning operation has effectively filled it with the burned .iso, with zero bytes remaining.

1635800 x 1024 = guess what?

1676083200

… so the content of the stick is the same size exactly as the content of the .iso in my downloads source.

Target size = Source size, that’s gotta be good!

STEP 3

Here we are going to determine the hash algorithm of the downloaded .iso to establish that what we have downloaded is


  • The Real McCoy, it has not been tampered with and

  • It has not been compromised by a glitch in the downloading process
Hash sum types include but are not limited to:


  • MD5 aka md5sum … basically obsolete but still used by some websites

  • SHA1 aka shasum, sha1sum (interchangeable) – more secure, but on its way to being deprecated (made redundant) and

  • SHA256 aka sha256sum – becoming the industry standard, and used by Linux Mint since they had a compromise April to June 2016
I have already established by using GtkHash (read about it here - https://www.linux.org/threads/gtkhash-–-hashing-out-the-basics.4430/ ) that the following applies to linuxmint-18.2-cinnamon-64bit.iso

MD5: 702baacedc9a117e5c5aa9fda0dd73b0

SHA1: 0294fdedfd0fecb84f8b10e290461003da675229 and

SHA256: d50e69a3e6d6b9d4b9cbe56cd3736cef665b708a4a2e5d9024f8eef439a91bba

Given what I have said above, I am only interested in the sha256sum (very long) output, it is just that I have GtkHash set up (by default) with the three fields. But we are talking about Terminal methods, so let’s get into it.

Going to my Downloads folder, I type and enter

Code:
sha256sum linuxmint-18.2-cinnamon-64bit.iso

and the output is

d50e69a3e6d6b9d4b9cbe56cd3736cef665b708a4a2e5d9024f8eef439a91bba linuxmint-18.2-cinnamon-64bit.iso

That’s a match. Good.

Further, atanere has provided us elsewhere with a page here https://ftp.heanet.ie/mirrors/linuxmint.com/stable/18.2/sha256sum.txt showing the sha256sums for all the ‘Sonya’ series, and 2nd from the top is a match for us. (That page was travelled to from a link here https://linuxmint.com/edition.php?id=237 , which is where you should have downloaded from. It says in friendly words “Don’t forget to verify your download”).

That means what we have downloaded is kosher. Good.

STEP 4

… is where the wizardry lies.

It has been asked “Can I verify the integrity of the burned .iso?” … that is, from the bootable stick or medium we are going to use to install.

The answer is usually “No”, and in truth you will not find it in a month of Sundays of examining the contents of your medium. But there is a fingerprint of it, and here is how we find it.

Remember that size figure we established before, of 1676083200?

We will take that and insert or paste that into the following command, as shown

Code:
sudo head -c 1676083200 /dev/sdb1 | sha256sum

What appears to be a vertical line between sdb1 and sha is actually two short vertical dashes, and you have it on your keyboard, perhaps above your backslash key and accessed by holding down Shift, or elsewhere.

It is often referred to as “the pipe key”, as it pipes and redirects information from a source to a target.

Press Enter and you will be prompted for your password (no movement, security). The output will take a short while to generate, but in the end the following appears

d50e69a3e6d6b9d4b9cbe56cd3736cef665b708a4a2e5d9024f8eef439a91bba -

There are a couple of spaces and a small dash, but you should recognise that big long number?

STEP 5

… is optional, but particularly useful if you are in the middle of an install and something is not going right. Or you think “Damn, I forgot to verify”.

The above I performed from the Acer in my Garage, with the burned Cinnamon stick inserted but not in use.

Now, at time of writing, I have rebooted and gone into the install process, but not started the installer.

I go to Terminal (Ctrl-Alt-t will do it for many) and type and enter what follows the $ up until the end of “sha256sum”:

Code:
mint@mint ~ $ sudo head -c 1676083200 /dev/sdb1 | sha256sum
d50e69a3e6d6b9d4b9cbe56cd3736cef665b708a4a2e5d9024f8eef439a91bba  -
mint@mint ~ $

… looks good to me.

In the live environment no need to enter your sudo password.

So an understandable mistake by people saying eg “Too late, you have already burned the iso to stick/dvd”, or you thinking it, is just that, a mistake.

All of the above is with the proviso that you have:

  1. One USB stick formatted to FAT32, with only one Linux Distro burned to it and

  2. Persistence is not enabled
TEST ENVIRONMENTS:

Debian-based

Linux Mint 18.2 ‘Sonya’

Ubuntu 16.04 ‘Xenial Xerus’

RPM-based

Gecko Linux (based on OpenSUSE Tumbleweed)

PCLinuxOS – requires “su” & password to assume Root, followed by the rest of the “head” command

Fedora 26 Workstation Beta

Gentoo-based

Sabayon 17.08

Arch-based

Bluestar Linux

Enjoy your Linux



Wizard
 


That is pretty stunning work there, young man! I am duly impressed! :D:D

I'll have to go play and watch that work too, but you've done enough testing with various other distros that I don't doubt you a bit. I am first amazed at just the simple fact that the expanded files on the USB match the size of the original .iso file. I think of the .iso like a zip file, but there must obviously be no compression involved or this trick couldn't work.

Well done, my friend!

P.S. I can call you "young man" because I am almost 3 whole months older than you! :p
 
I am first amazed at just the simple fact that the expanded files on the USB match the size of the original .iso file. I think of the .iso like a zip file, but there must obviously be no compression involved or this trick couldn't work.

Likewise, me. I think we can all become prisoners of our prior conditioning, having learned backups with compression under Windows, self-extracting executables, cabinets, archiving &c ... and then assuming it applies throughout systems. Not always the case.

While I was working through the Families, under RPM I was using Fedora on the laptop in the laundry, and had not then set up my openSSH folder sharing so could not access the LM .iso from the Garage, so I used that porky 3.1GB Slackware .iso you and Paul were working on - same results.

What impressed me was being able to work the voodoo from within the Live environment, which is tailor-made to circumstances such as those of PcBuilderEd and any number of others, where you might be installing Linux on a drive that has no other OS on it. But you can establish an Internet connection and follow (what Elaine and I call) the Destructions above to get a satisfactory outcome.

Cheers, off to find some more Mythbusting target matter, lol. Keep calling me "young man" and we'll always be Mates :D

Wizard
 

Members online


Top