Check out this thread for how to do it:
http://androidforums.com/htc-droid-eris/138831-verify-your-files-md5-checksums.html
Unfortunately, I do not see an MD5 sum listed for that ROM in the developer's thread for this ROM on XDA. These checksums should be posted by the devs so you can make sure you've got a complete, uncorrupted, and proper version of the file in question.
Perhaps someone else that has downloaded this custom ROM could publish their MD5 sum so you could at least compare that? Anyone?
Or, at the very least, you can verify that the file you downloaded matches what you placed on you /sdcard (that helps a little).
sa,
I don't think that the "toolbox" executable of the HTC-shipped ROMs supplied a "md5sum" function - so folks that are getting started rooting (i.e., don't already have root) can not run "md5sum" from their phone without installing an app to do that.
There is an alternate way to check that a ROM is at least "intact" - that is, not corrupted or truncated. It does not verify authenticity, however, and it also involves the PC.
That method is to use "jarsigner -verify ROM_name.zip" on the PC ("jarsigner" is included in the JDK - if you set up your PC with the Android SDK, the JDK is required as a prerequisite) It unpacks the zip and compares the SHA1 signatures of every file in the manifest.
This does not verify that it is the same ROM as that published by the author, as the signing keys used by all the "cooks" is the same key, and widely available (not really private any longer) - someone could pick apart a ROM, put some of their own stuff in it, re-sign it with the same keys, and it would pass this test. (The probability of this happening at the download link provided by the ROM author is pretty low, although it would be much easier if someone was "hosting a copy")
I suppose you could do this check on a PC, and if it passes, then look at the length of the file in bytes (on both the PC and the phone); if they are the same, the probability of them being different is pretty darn low. Doing things this way is not as good as performing the MD5 check right on the phone, but it is better than nothing at all.
But, it
does indicate that the ROM file will pass the "verification" phase of the ROM install by the Amon_RA recovery boot.
As a practical matter, though, the problems most folks have with "corrupted" ROMs are due to far simpler problems (rather than single-bit errors):
- Their OS "hides" file extensions (Windows) or Automatically unpacks .Zip files (O/S X)
- Their initial download times out, and they are left with a "short" file.
- They copy the file to their SD card via the USB cable, and fail to properly eject/unmount the SD card, so that the file ends up short/corrupted on the SD card, even though it was intact on the PC.
In the most desirable scenario, the dev would publish both the exact file length (bytes) and MD5 signature when they post a download link. Because it is essentially impossible to make a single-byte change to a file to produce the same MD5 signature, publishing the file length is usually regarded as optional - verifying the MD5 signature validates that you have the same file, even if the file length is not stated.
The thing which should be pointed out is that
it is not possible to install a corrupted ROM - it won't pass the "verification" check performed before any files are being flashed.
My guess is that folks who experience boot-loop symptoms after installing a ROM have this happen for a couple of reasons:
1) They failed to perform a wipe in Amon_RA (where required) prior to the ROM install, or
2) They used a ROM which expects a partitioned SD card for a2sd, or
3) They used a partitioned SD card with an ext format (either ext2 or ext4) which is not supported by the target ROM, or
4) The ROM developer kitted their ROM so that it was necessary to flash a (full-wipe) base ROM, and then overlay some update flashes to get the correct behavior, and the user failed to add the overlay flashes, or
5) They flashed their ROM with a very low battery - say 50% or less, and the installed file really was corrupted (in NAND memory, but not on the SD card), or
6) They had previously rooted and used A2SD, and have some apps in the ext partition on their SD card which are completely incompatible with the new ROM.
(Note that ROMs which are pre-configured to start adbd up on boot will have a shell available which comes alive about 8-9 seconds into the boot - in these cases it is sometimes possible to observe the exact cause of the boot-loop by using either "logcat" or ddms: the kernel is actually booted, but the looping is occurring in the initial housekeeping stage of the Android boot process. But, this is sort of advanced for a casual user - and, as I said, I want this thread to concentrate on phone-only techniques)
I put the suggestion to "check the MD5 or file length" in my original posts mostly so that folks without SD card readers would not end up wiping their phone and then finding out afterward that they had mangled their ROM .zip file when downloading or transferring it to the phone. (Even that is not a disaster, because they would have the "USB-MS toggle" functionality of Amon_RA, but that was a detail that I touched on only lightly).
eu1
) for a highly informative and relevant post! I appreciate all of the bonus and related information too.
