md5sum - Suse

This is a discussion on md5sum - Suse ; I have 3 computers here, let's call them Proxie, Incinerator and Sputnik. Proxie is low-power, weak and is the gateway to the net. I have grabbed the i386 and x64 versions of 11.0 here via ktorrent and am currently seeding ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: md5sum

  1. md5sum

    I have 3 computers here, let's call them Proxie, Incinerator and
    Sputnik.

    Proxie is low-power, weak and is the gateway to the net. I have
    grabbed the i386 and x64 versions of 11.0 here via ktorrent and am
    currently seeding them to the world again. Proxie also exports to the
    internal network via NFS.

    Incinerator has a DVD burner, as does Sputnik (a laptop).

    - First I used Incinerator to check the md5sums on the Proxie export,
    both values were correct.
    - Then I used tar pipelines to copy the .iso images to Incinerator.
    Both were *wrong*.
    - Then I copied them using cp -a, the i386 value was ok and the x86_64
    value was bad.
    - Then I checked the original values again (on the nfs share) and both
    were now wrong.

    Ok, memchk is my friend. I ran memchk on Incinerator, went away for a
    few minutes and when I came back, Incinerator had died. My initial
    guess is that with memchk not having Cool N'Quiet, Incinerator
    incinerated.

    Well, let's try Sputnik.
    Copying both .iso images to Sputnik, and then running md5sum on the
    originals and the copies showed 4 different values, none of which
    matched the SuSE values.

    Running md5sum on Proxie showed that the i386 iso was ok but that the
    x64 one was bad. Even though the x86_64 value had shown up fine a
    couple of hours earlier when Incinerator was looking at it on Proxie.

    - wtf?
    - I am still seeding both images. Is x86_64 .iso bad?
    - What can be causing md5sums to change?

    Proxie exports the NFS drive with 'async,rw' but everything else
    standard.

  2. Re: md5sum

    Vlad_Inhaler wrote:

    > I have 3 computers here, let's call them Proxie, Incinerator and
    > Sputnik.
    >
    > Proxie is low-power, weak and is the gateway to the net. I have
    > grabbed the i386 and x64 versions of 11.0 here via ktorrent and am
    > currently seeding them to the world again. Proxie also exports to the
    > internal network via NFS.
    >
    > Incinerator has a DVD burner, as does Sputnik (a laptop).
    >
    > - First I used Incinerator to check the md5sums on the Proxie export,
    > both values were correct.
    > - Then I used tar pipelines to copy the .iso images to Incinerator.
    > Both were *wrong*.
    > - Then I copied them using cp -a, the i386 value was ok and the x86_64
    > value was bad.
    > - Then I checked the original values again (on the nfs share) and both
    > were now wrong.
    >
    > Ok, memchk is my friend. I ran memchk on Incinerator, went away for a
    > few minutes and when I came back, Incinerator had died. My initial
    > guess is that with memchk not having Cool N'Quiet, Incinerator
    > incinerated.
    >
    > Well, let's try Sputnik.
    > Copying both .iso images to Sputnik, and then running md5sum on the
    > originals and the copies showed 4 different values, none of which
    > matched the SuSE values.
    >
    > Running md5sum on Proxie showed that the i386 iso was ok but that the
    > x64 one was bad. Even though the x86_64 value had shown up fine a
    > couple of hours earlier when Incinerator was looking at it on Proxie.
    >
    > - wtf?
    > - I am still seeding both images. Is x86_64 .iso bad?
    > - What can be causing md5sums to change?
    >
    > Proxie exports the NFS drive with 'async,rw' but everything else
    > standard.


    Any chance that while a chunk is being uploaded by torrent that it is not
    available to do a checksum on it? Or that even though you have 100% that
    it downloaded a chunk that didn't match, so it was fine the first time and
    then didn't match later. I noticed mine doing an occasional download of a
    chunk several hours after reaching 100%.

    John

  3. Re: md5sum

    On Jun 24, 12:48 am, John Bowling wrote:
    > Vlad_Inhaler wrote:
    > > I have 3 computers here, let's call them Proxie, Incinerator and
    > > Sputnik.

    >
    > > Proxie is low-power, weak and is the gateway to the net. I have
    > > grabbed the i386 and x64 versions of 11.0 here via ktorrent and am
    > > currently seeding them to the world again. Proxie also exports to the
    > > internal network via NFS.

    >
    > > Incinerator has a DVD burner, as does Sputnik (a laptop).

    >
    > > - First I used Incinerator to check the md5sums on the Proxie export,
    > > both values were correct.
    > > - Then I used tar pipelines to copy the .iso images to Incinerator.
    > > Both were *wrong*.
    > > - Then I copied them using cp -a, the i386 value was ok and the x86_64
    > > value was bad.
    > > - Then I checked the original values again (on the nfs share) and both
    > > were now wrong.

    >
    > > Ok, memchk is my friend. I ran memchk on Incinerator, went away for a
    > > few minutes and when I came back, Incinerator had died. My initial
    > > guess is that with memchk not having Cool N'Quiet, Incinerator
    > > incinerated.

    >
    > > Well, let's try Sputnik.
    > > Copying both .iso images to Sputnik, and then running md5sum on the
    > > originals and the copies showed 4 different values, none of which
    > > matched the SuSE values.

    >
    > > Running md5sum on Proxie showed that the i386 iso was ok but that the
    > > x64 one was bad. Even though the x86_64 value had shown up fine a
    > > couple of hours earlier when Incinerator was looking at it on Proxie.

    >
    > > - wtf?
    > > - I am still seeding both images. Is x86_64 .iso bad?
    > > - What can be causing md5sums to change?

    >
    > > Proxie exports the NFS drive with 'async,rw' but everything else
    > > standard.

    >
    > Any chance that while a chunk is being uploaded by torrent that it is not
    > available to do a checksum on it? Or that even though you have 100% that
    > it downloaded a chunk that didn't match, so it was fine the first time and
    > then didn't match later. I noticed mine doing an occasional download of a
    > chunk several hours after reaching 100%.
    >
    > John


    Just adding to the confusion a couple of days later.
    - Since the original x86_64 image on Proxie was generating bad
    checksums, I renamed it and downloaded it again. Both copies (and the
    i386 image) now give the correct checksums on Proxie.
    - Copying the new x86_64 and i386 images to Sputnik (nfs export), the
    x86_64 checksum was ok but the i386 was bad.

    Well, I burnt a DVD with the x86_64 image and installed it to
    Incinerator and Sputnik. Both installs needed a bit of massaging but
    are now up to scratch.
    I'll have another go at copying the i386 image from Proxie to Sputnik
    when I have time (Incinerator is playing up badly, it simply dies
    after a couple of hours. I'm assuming overheating).

    The basic problem with the MD5 sums appears to be 'bit rot'.

+ Reply to Thread