We recently ran into a situation where all of our SLES 10 SP3 and OES2 SP2 servers that had been upgraded (from SLES 10 SP2 or OES2 SP1 respectively) failed to apply all the post patches via our SMT server.

We would right-click on the ZMD icon, apply the patches and all we would receive was:

Transaction failed - invalid path

We would review the zmd-messages log on the servers and all they would indicate is that they had successfully contacted our SMT server and downloaded the patches. But it failed to indicate which patch or patches was causing the problem.

After spending a few weeks with NTS on this, it was discovered that some of the patches had failed to download problem from Novell's server to the SMT Server. We had a few zero-byte files in the content repository.

We inquired as to why this was possible.

It turns out that the DEFAULT command or cronjob for SMT of:

smt-mirror

ONLY runs an MD5 checksum on the metadata.xml file. It does not actually run an MD5 checksum on the individual patches themselves.

However, there is a way to get SMT to actually verify each and every file:

smt-mirror --deepverify
(that's two dashes in front of the deepverify)

To set this on your SMT configuration:
edit the:

/etc/smt.d/smt-cront.conf

file and find the line for:

MIRROR_PARAMS

By default it will probably look like:

MIRROR_PARAMS="-L /var/log/smt-mirror.log"

Change it so that it looks like:

MIRROR_PARAMS="--deepverify -L /var/log/smt-mirror.log"

Save the file, and on your scheduled run, it should perform a deep verify to ensure the MD5 checksums are correct.

Obviously this will add additional time for the mirroring, but in my opinion, the extra time is worth ensuring that the patches are downloaded correctly.

This is for SMT 1.0, although I imagine the same would work for SMT 1.1