Very Computer

After downloading the *dsk files from
ftp://ftp.boulder.ibm.com/ps/products/os2/fixes/v4warp/german/xrgm015/ I
got a message that the checksum on several files is wrong when I try to
install the FP15. Although finely unpacked using diunpack.

Using the zip'ed files from
ftp://ftp.boulder.ibm.com/ps/products/os2/rsu/xrgm015/ worked without
any errors

Was it only a download problem on my side, or are the *dsk files corrupt
?

Klaus Staedtler

Klaus, I need some help from you.

I just d/l'ed the diskette image files and got this :

 1-23-01   3:50p   1451153           0  xrgm015.1dk
 1-23-01   3:50p   1472145           0  xrgm015.2dk
 1-23-01   3:50p   1472145           0  xrgm015.3dk
 1-23-01   3:50p   1472145           0  xrgm015.4dk
 1-23-01   3:51p   1472145           0  xrgm015.5dk
 1-23-01   3:51p   1472145           0  xrgm015.6dk
 1-23-01   3:51p   1472145           0  xrgm015.7dk
 1-23-01   3:51p   1472145           0  xrgm015.8dk
 1-23-01   3:51p   1472145           0  xrgm015.9dk
 1-23-01   3:51p   1472145           0  xrgm015.adk
 1-23-01   3:51p   1472145           0  xrgm015.bdk
 1-23-01   3:51p   1472145           0  xrgm015.cdk
 1-23-01   3:51p   1472145           0  xrgm015.ddk
 1-23-01   3:51p   1472145           0  xrgm015.edk
 1-23-01   3:52p   1472145           0  xrgm015.fdk
 1-23-01   3:52p   1472145           0  xrgm015.gdk
 1-23-01   3:52p   1472145           0  xrgm015.hdk
 1-23-01   3:52p    885393           0  xrgm015.idk

I compared them to what should have been posted and they are IDENTICAL.

Can you be more specific on the fails?

Was the CHECKSUM error coming up from the FixTool itself? If it was,
tell me the file names, it will be in the os2\install\service.log file.

If it wasn't, and was coming from DIUNPACK for instance, you probably
hadn't set the d/l to BIN or had some communication problem.

Irv

(etc)

A suggestion, Irv. In the Linux world (among others, it isn't
exclusively there) people publish a checksum file when they put up
disk images. It's easy to generate and everyone can (if they want)
check images without actually unpacking them. The checksum file just
looks like:

-------------------------------------
xrgm015.1dk 123456768789
xrgm015.2dk 234567687890
..
etc

When I say 'checksum', they tend to use the MD5 algorithm which is
excellent at picking up any error at all. You just say:

   md5 xrgm015.1dk

and itspits out a number, repeatable on the exact same file but
INCREDIBLY unlikely (like, really, really, unlikely) on ANY other
file.

I wrote an MD5 program for OS/2; see:

   http://www.tavi.co.uk/os2pages/md5.html

I would guess that generating and including the small text file of MD5
signatures 9as they are called) would add about ten minutes to the
release task. Or about one minute using a REXX script!
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..

Bob,

DSK images *are* checksummed. The problem here is that DIUNPACK
doesn't check the damn thing to make sure it matches. LOADDSKF does
check it as, I believe, does dskxtrct.

--
Trevor Hemsley, Brighton, UK.

Yes, I realise that. But the checksums from somethig like MD5 are more
secure.

Also, one doesn't want to use LOADDSKF to check the images out....it
means unpacking them even if just to a convenient RAM drive (which has
to be set up). Same with DIUNPACK.

One could imagine a nice little REXX script to generate a
one-disk-per-line 'checksum' file at Irv's end...and another to check
them all the the user end.
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..

Irv Spalten schrieb:

Quote:

> Klaus, I need some help from you.

Thanks for your quick response.

After downloadeing all the described *.dsk files I used diunpack which
worked flawlessly. But whenever I tried to install the fixpack using
service.exe or fservice.exe they aborted with saying there is a checksum
error in TRC00C0.TF_. Afterwards I wanted to take a look into the
readme.1st (located at xrgm0015.1dsk) to find out on what disk the file
is located, but it was completly empty. So I decided to download the
whole fixpak again, but this time as zipped version (which worked, so
I'm now on FP15, which works very fine Thanks to you and everybody else
at IBM for the release).

Klaus

Irv Spalten schrieb:

Quote:

> Klaus, I need some help from you.

Dear Irv it seems that the problem was only on my side cause others had
no problems. The only strange thing was, that diunpack unpacked the
downloaded *.dsk files without any complain - normally if the downloaded
files (e.g. zip-files) are not complete - I'm unable to use them.

But thanks again for your efforts

Klaus

Klaus, thanks.

I'd still like to know if you could verify that the problem was on your
end? The files 'look' good here. I just d/l'ed image 1dk and used
LOADDSKF to create the diskette. I can see and read README.1ST...

==============
The volume label in drive I is CSF DISK 1.
The Volume Serial Number is E233:5C15.
Directory of I:\

CSF_DISK          114   1-12-01  10:04a
FIX          <DIR>      1-12-01  10:04a
README   1ST   139253   1-12-01  10:44a
README2         92720  12-05-00  11:37a
README   CID    14065   7-24-98  12:34p
README   REG    11082   7-24-98  12:34p
        6 file(s)     257234 bytes used
                       24064 bytes free
======================

Unless you had data on that diskette, you would have NEVER been able to
start the install? in FIX\OS2.1 is SRV_PROD.OS2, and that is one of the
first files looked for. Don't have that, you are done. TRC00C0.TF_ is
located on diskette 1 as it turns out. It appears that you might have
had a problem.

So, I will assume the files are OK. If you feel like it, try to D/L just
the first image and see if you can make them. If not, OK by me, but I'll
assume you had the problem.

Irv

Bob, I'll look at this.

The reason we don't really do this is that LOADDSKF actually gives you
the same info, well, not exactly, it says the file is corrupt.

In addition, there are cases when the CRC value is correct, I understand
specific bits can be dropped and get the same CRC, and the FixTool was
recently upgraded to check the CRC's of the INDIVIDUAL files within the
FP being bad.

Part of out process in sending the FP's to an FTP site for testing
included the CRC check and a small file. I guess we figure once we get
that clean, we know we have golden masters <G>. Actually, the ONLY time
I recall and error was twice, once where the transmission up caused a
file to go bad (we heard about that real fast <G>) and another time when
someone short cut the process and only replaced on diskette image when
two were required.

Irv

Irv Spalten schrieb:

Quote:

> So, I will assume the files are OK. If you feel like it, try to D/L just
> the first image and see if you can make them. If not, OK by me, but I'll
> assume you had the problem.

As I stated In my follow-up post the problem seemed to be on my side.
For what curious reason ever, some files from xrgm015.1dk where empty
after unpacking them with diunpack, I first looked into them with fc/2
and then with a hex-editor: I saw only dots - 00. So it seems that
during download at least xrgm015.1dk went corrupt. The curiosity (who
led me on the wrong path) was that I can unpack it, although it was
damaged (so I falsly thought that maybe the disk-image itself is
broken).

Thanks again

Klaus

Irv Spalten schrieb:

Quote:

> Klaus, thanks.

> I'd still like to know if you could verify that the problem was on your
> end? The files 'look' good here. I just d/l'ed image 1dk and used
> LOADDSKF to create the diskette. I can see and read README.1ST...

To add some more curiosity ;-)

A poster at os2.org told similar problems that I have, but he used wget
for os/2 not netscape like me. Just for testing he downloaded the whole
fixpak again today, but used this time wget on BSD and: no errors. It
seems that yesterday night was a 'bad conjunction between moonlight and
downloading FP15 German as dsk-Image Version'. Sorry for not having a
more rational explanation.

Klaus

Just an idea. Most people don't use LOADDSKF these days, because they
want to do hard drive or CD based fixpack application (I think).

Quote:> In addition, there are cases when the CRC value is correct, I understand
> specific bits can be dropped and get the same CRC

That's where MD5 wins. The 'signature' is 128 bits (I think it's 32
bits with LOADDSKF) and it's mathematically almost impossible to get
the same fingerprint from a corrupt file.

Quote:> Part of out process in sending the FP's to an FTP site for testing
> included the CRC check and a small file. I guess we figure once we get
> that clean, we know we have golden masters <G>.

But it'd be nice to be sure that those of us downloading the FPs also
got 'golden slaves' <G>! I guess that's a more likely source of error
in many ways....more of us doing it for a start.

Here's a taste of MD5:

----------------------------------------------------------------------
----------------
[E]md5 xr_m015.1dk
MD5 (xr_m015.1dk) = b8646506066fecf70d0f0fd703de5287

[E]md5 xr_m015.2dk
MD5 (xr_m015.2dk) = 14d972b653cd9a40a06e4cc71c97497c

[E]md5 -h
md5: MD5 digest utility
Synopsis: md5 [-pqrtx] [-s string] [file ...]
 Options:
    -h           display this help
    -p           echo input to output, and append the digest value
    -q           quiet mode; generate only the MD5 digest. Overrides
-r
    -r           reverse the format of the output; does nothing when
                 combined with the -ptx options
    -s string    generate a digest of string
    -t           run a built-in time trial
    -x           run a built-in test script; -q and -r must precede
this
                 option to be effective

The program generates a 128-bit fingerprint (or 'digest') of a string
or file. If no file or string is specified, standard input is used.

----------------------------------------------------------------------
----------------

--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..

Quote:>Just an idea. Most people don't use LOADDSKF these days, because they
>want to do hard drive or CD based fixpack application (I think).

true, actually most people use diunpack to unpack the disks to the harddrive
before applying the fix.

most people dont use disks anyway. none of my systems even have a diskdrive,
but thats an extreme situation.

t H.I.C. & D.B.S. t OS/2 Warp t Hellas t
t ServerConfig t ConfigEdit t OS/2 UK UG t

On Thu, 25 Jan 2001 00:49:01, "Dimitris 'sehh' Michelinakis"

Exactly. Unfortunately, DIUNPACK does NO checking at all. DSKXTRCT is
better, it checks CRCs but doesn't work on all LOADDSKF files. And
there's still the problem that the CRCs are not foolproof.

As I said, I'm more concerned with corruption 'public site -> user'
than I am with 'Irv -> public site'!
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..

OK Bob, I have MD5 and will look further.

We did discuss this, and we sort of think it is unnessecary. We
basically provide two ways to get the FP, RSU, which in my estimation is
equivalent to all the other methods people are using if not using
diskettes, and LOADDSKF to create diskettes. We all check the images
placed out there before announcing. We feel very confident that the
files are correct before we announce the availability.

To my knowledge, and this goes back a few years, I can not recall any
problems we created, save the few times someone didn't follow procedures
in putting up a FP.

Even if we posted the CRC's from MD5, how do we 'make' others using
varied processes use it? Heck, some people never read README's.

I do like the large 128 bit though. As for "it's mathematically almost
impossible",