Can someone explain why upgrade-all deletes the old package before verifying the new one? I have had several instances where the new package failed the verification, but the old one was already deleted. The first few were outliers, and simple to reinstall. The last one was glibc-zoneinfo, which, while also easy to reinstall, is a little more alarming. What would happen if it is a core library?

slackpkg uses upgradepkg, which doesn't at all do that, so I don't see how slackpkg could possibly do that.

My guess is that rmcconnell is referring to slackpkg removing the old txz package files when it's downloading updated ones (assuming that's how slackpkg works, but I'm too lazy to dig into it to find out). So if the new packages have problems, the older ones had already been removed.

I have never encountered errors such as the ones OP reported, and I've been using Slackware since April 2005 (I remember it well--Slackware is so easy to install that I installed it three times that Saturday!).

Nevertheless, I would be happy to see an authoritative answer to his question.

upgradepkg first installs the new package (installpkg). If it succeeds, it then removes the old one (removepkg), and then installs the new package again (installpkg). Installpkg always tests the tar package integrity first and only then extracts it for real. But without --verbose, upgradepkg sends the output of the first installpkg to /dev/null, so the OP does not see that it verified the package there, too.

(So, it seems upgrading a package runs the xz uncompressor four times. Or six times if it needs to look for the description file inside the package.)

I think the OP has a hardware problem because the packages extracted fine in the first installpkg run (with output to /dev/null) and failed in the final installpkg. I would try memtest.

I ran Memtest86+ v5.01 for over eight hours. It completed five passes with no errors reported. Is there a better test utility?

You might also have a problem with the hard drive.

First option would be to run the hard disk manufacturer's diagnosis tool to check for bad sectors and other issues on the physical hard disk. Those diagnosis tools are usually available as a DOS bootdisk or ISO image.

Also the "Ultimate Boot CD" (available as an ISO image) is a free tool with many of the hard disk manufacturer's diagnosis tools included. Included are diagnostic tools from Western Digital, Seagate/Maxtor, IBM/Hitachi, Maxtor/Quantum, Samsung, Fujitsu and others. They are mostly DOS tools, which can do much more than just read S.M.A.R.T data. These tools can also do integrity tests.

Taken from the ArchLinux website,

"During Filesystem Check
Incorporating bad sectors can be done using the filesystem check utility (fsck). fsck can be told to use badblocks during a check. To do a read-write (non-destructive) test and have the bad sectors made known to the filesystem run:

# fsck -vcck /dev/<device-PARTITION>
The -cc option tells run fsck in non-destructive test mode, the -v tells fsck to show its output, and the -k option preserves old bad sectors that were detected."



"badblocks is a program to test storage devices for bad blocks.

In case of a HDD the whole sector should get retired. A sector is a subdivision of a track on a storage device and sectors that have become bad cannot be used because they have become permanently damaged (a bad sector can have adverse effects ranging from changing a letter in a text file to causing a binary program to have a segmentation fault).

S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) is hardware-featured in almost every HDD still in use nowadays and in some cases it can automatically retire defective HDD sectors. Anyhow S.M.A.R.T. only passively waits for errors while badblocks writes simple patterns to every block of a device and then reads and checks them searching for damaged areas. (Just like memtest86* does with RAM.)

This can be done in a destructive write-mode that effectively wipes the device (do backup!) or in non-destructive read-write (backup advisable as well!) and read-only modes."


read-write Test (non-destructive)
This test is designed for devices with data already on them. A non-destructive read-write test makes a backup of the original content of a sector before testing with a single random pattern and then restoring the content from the backup. This is a single pass test and is useful as a general maintenance test.

# badblocks -nsv /dev/<device>

The -n option signifies a non-destructive read-write test.



From Linux you can test the S.M.A.R.T status with these commands from the shell or terminal as root, or from Linux boot disk:


My opinion is to look in SMART with:

smartctl --all /dev/sdX (where X is your actual partition number)

You can also do as follows:

smartctl -a /dev/sda1 (to examine stats)

smartctl -t long /dev/sda (to run a self test)


You can also use the badblocks command. If the drive is /dev/sda (booting from a linux bootable disk)

Code:
badblocks -s /dev/sda


Leave it running until it finishes (typically a few hours or less). If it finds many bad blocks, then the drive is failing, or has failed.





P.S.

Naturally with any of these commands, please substitute your actual hard drive, for the <device>, sda1, or sdX which was written above.