Confused about final DVD size

I downloaded the leap 42.2 iso image and the sha256 checksum. The SHA check output this:

$ sha256sum -c openSUSE-Leap-42.2-DVD-x86_64.iso.sha256 
openSUSE-Leap-42.2-DVD-x86_64.iso: OK
sha256sum: WARNING: 14 lines are improperly formatted

An ambiguous output? There were no errors but something is wrong?

I burned a DVD. The final size was 4.1 GB. The ISO was 4.4 GB (even though the website claimed 4.7 GB).

  1. Is the final DVD size correct?
  2. How do I verify the contents of the DVD against the ISO?

4.1, 4.4, 4.7 – nothing of concern.

4.7 is the max for a DVD image.

The difference between 4.1 and 4.4 depends on whether you are counting by 1000 or by 1024.

Your checksum verification is fine. The “14 lines are improperly formatted” is due to the sha256 file being gpg signed. If you use gpg, you can check its signature. The 14 lines are the signature. I suggest you get used to that warning, because it is the current practice. Several distros do something similar. I do check the signature, and that provides assurance that hackers have not broken in and changed the sha256 file to match a hack iso.

How? Some explanation what statements to use to check the signature might be helpfull.

And yes, “4.7GB DVD” as mentioned on the website is the medium that can be used. It is something you bye in a shop and that is mentioned on the box.
After download, I have this:

-rw-r--r-- 1 henk wij 4384096256 18 nov 15:03 openSUSE-Leap-42.2-DVD-x86_64.iso
-rw-r--r-- 1 henk wij        630 18 nov 14:45 openSUSE-Leap-42.2-DVD-x86_64.iso.sha256

And 4384096256 B is 4.38 Gb. It is also 4.18 GiB. Mark the difference between GB and GiB (as nrickert mentioned). Also remark that often people use GB when they mean GiB. See Byte - Wikipedia

To check the SHA256, I did

cha256sum -c openSUSE-Leap-42.2-DVD-x86_64.iso.sha256

That will read the lines in that file and assume that those lines are formatted with two fields seperated by white space: the sha256 key and the file to be checked.

man sha256sum

Look into that file and you will see that only 1 of the 15 lines there fits. The other 14 are thus rubbish for this action. Thus, like nrickert, after checking the GPG (awaiting how this should be done) you could edit the file and remove those 14 lines. But the OK you saw in your output is enough reassurance for most of us. :wink:

And vefying the DVD against the ISO is a feature of k3b (that I use to burn). I switch it on and the check is done immediatly after the burn.

The trouble is that gpg has a steep learning curve. People familiar with it will already know how to check.

The command that I used to check was:

gpg --verify openSUSE-Leap-42.2-DVD-x86_64.iso.sha256

However, the novice will probably get errors from that. He has to first get the signing key into his keyring.
That can be done with:

gpg --recv-keys 3DBDC284

But then he is going to have to sign the key, or ignore the message that the key might not be valid.

henk@boven:~> gpg --recv-keys 3DBDC284
gpg: no keyserver known (use option --keyserver)
gpg: keyserver receive failed: Syntaxfout in URI


In any case, thanks for the clarification. :slight_smile:

henk@boven:~> gpg --recv-keys 3DBDC284
gpg: no keyserver known (use option --keyserver)
gpg: keyserver receive failed: Syntaxfout in URI

That should have been gpg2:

$ gpg2 --recv-keys 3DBDC284
gpg: requesting key 3DBDC284 from hkp server
gpg: key 3DBDC284: "openSUSE Project Signing Key <>" 12 new signatures
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: Total number processed: 1
gpg:         new signatures: 12


$ gpg2 --verify openSUSE-Leap-42.2-DVD-x86_64.iso.sha256 
gpg: Signature made Tue 15 Nov 2016 10:04:50 AM MST using RSA key ID 3DBDC284
gpg: Good signature from "openSUSE Project Signing Key <>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 22C0 7BA5 3417 8CD0 2EFE  22AA B88B 2FD4 3DBD C284

The fingerprint matches the one shown on the website.

That was all very interesting. The one question that was not answered was: How to verify the data written to the DVD matched that in the ISO image? I seem to recall that the burn program created a checksum before burning, then another afterward. Is considered sufficient for verification.

Yes, thanks.

As said above, k3b offers a check (that is it reads the whole freshly burnt DVD and compares a checksum against the checksum it made in the beginning of the ISO file) that can be switched on.

Also,when boot from it, it offers a Check the Medium item.

hi :wink:

in the above explanations you unfold the process to control the accuracy of the iso. This involves using a checksum and then controlling its gpg signature.
At the end though there still is something confusing from #6 above , or that may scare the beginner, this maybe a good joke though rotfl!

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

Is there a bug, or something missing ? Can you please unfold this part ?

Thanks :wink:

An observation half on topic (make it simple for beginners) and half off (using the gpg check),

The absolute beginner can download using torrent <if you use a torrent client that automatically checks everything>
Not every torrent client checks every individual downloaded chunk and when completed, the entire file so read the application documentation for the feature.
Additional benefits using torrent, you can interrupt the download and resume later, and if any piece (aka chunk) is found to be corrupted then that piece is immediately discarded and downloaded again so that only a few megabytes need are re-downloaded. On the other hand if you downloaded using HTTP or FTP and the file fails the checksum verification, then the entire 4+ GiBytes need to be downloaded again.

Is why whenever possible I always use torrent to download large files where the integrity is critical, I never have to do the checksum verification manually.


That’s why I said (above) that gpg has a steep learning curve.

At this stage you have a key that purports to be “openSUSE project signing key”. And it wrote the signature that you checked. But how do you know that key is real? Anybody can create a key that claims to be by “openSUSE project signing key”, and then upload that to the keyservers. So, ideally, you need to find some other way of deciding if it is a fake key or the real key.

Once you have satisfied yourself that it is real, you can sign that key yourself (with “kgpg” for example). And then you won’t get that message in the future.

For me, I checked the signatures on that key. And one of those was by the opensuse security key. And I had already come to accept that key a decade or more ago. But, getting started can be hard.

If I had zero knowledge, what would I do? I would probably keep the downloaded DVD image, but not use it. Then, maybe a week later, I would download again, and compare with the first download. If it is the same image, that’s good evidence (a hacked download site would have been discovered and fixed by then). And since the key you have on your ring was used to sign a good image, that’s some sort of evidence that it isn’t a fake key.

+1 for downloading large files via torrent but you can repair a broken download also with wget: wget -c /directoryofbrokenimage/opensusebrokenimage.iso

edit: I forgot you can user rsync too

  • HTH