On 21 Aug 2023 19:53, Tim Woodall wrote:
On Mon, 21 Aug 2023, Tim Woodall wrote:
On Wed, 24 Aug 2022, Tim Woodall wrote:
I got this error while installing build-essential
Preparing to unpack .../03-libperl5.34_5.34.0-5_arm64.deb ...
Unpacking libperl5.34:arm64 (5.34.0-5) ...
dpkg-deb (subprocess): decompressing archive
'/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb'
(size=4015516) member 'data.tar': lzma error: compressed data is corrupt
dpkg-deb: error: <decompress> subprocess returned error exit status 2
dpkg: error processing archive
/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb
(--unpack):
cannot copy extracted data for
'./usr/lib/aarch64-linux-gnu/libperl.so.5.34.0' to
'/usr/lib/aarch64-linux-gnu/libperl.so.5.34.0.dpkg-new': unexpected
end of file or stream
Am I right that this must be a local error - apt will have verified the
checksum while downloading the deb? (and it worked on rerunning - the
deb was in acng)
I can find nothing anywhere that suggests anything has gone wrong (other
than this error) but (and I'm sure it's a coincidence) since installing
ACNG (on the same machine) I've been getting a number of errors similar
to things like this where files appear to be corrupted but work on the
next attempt.
There's no SMART errors or anything like that either.
Anyone got any ideas - any logging I should add to try and track down
where the issue might be?
Tim.
Just a FYI, I've been battling this, and errors like this for almost a
year. The last but one kernel upgrade seems to have fixed it. :-)
I've been reverting all the changes I made trying to track it down and,
touch wood, it's not come back.
One of these two upgrades fixed it. (the first doesn't seem plausible)
Start-Date: 2023-08-11 06:25:52
Commandline: apt-get -y upgrade
Upgrade: usbip:amd64 (2.0+5.10.179-3, 2.0+5.10.179-5)
End-Date: 2023-08-11 06:25:53
Start-Date: 2023-08-12 08:16:59
Commandline: apt-get -y dist-upgrade
Install: linux-image-5.10.0-24-amd64:amd64 (5.10.179-5, automatic)
Upgrade: linux-image-amd64:amd64 (5.10.179-3, 5.10.179-5)
End-Date: 2023-08-12 08:23:07
I cannot tell which machine mattered, could be the xen host, the guest
running apt, the guest running apt-cacher-ng or the one running the
squid proxy. (the last two feel impossible given the symptoms above)
The disk was mounted via iscsi on the xen host, so it's not quite as
simple as saying apt got the right file over the network therefore it
must be the guest.
I'm not going to try to reproduce and track down exactly what fixed it.
Tim.
So I spoke too soon. Reverting the last change I made, resulting in
halving the memory and leaving only one vcpu in the guest, meaning that
the guest is severely loaded and I got a one bit error in a downloaded
(Packages.xz) file.
Some ideas :
- Are the iscsi drives served by a local domU or from remote ?
- Have you tried moving all the iscsi-backed drives on the local dom0
filesystem ?
- Maybe the problem is with slow syncing data to source disk(s) ? (as
you wrote "files appear to be corrupted but work on the next attempt").
[
I had a (somewhat similarly strange ?) problem trying to install Qubes
as a domU, from an ISO served by an NFS mount from another domU, like :
domU --[NFS]--> dom0 --[use ISO on NFS mount]--> Qubes domU
The install failed with "Payload SHA256 digest: BAD", although the ISO
file was OK (verified with sha256).
When I COPIED the same ISO (ie. no re-download) from the NFS mount to
the dom0 local FS (ext4), the install went fine.
In both runs, the Qubes domU was using local ext4 disk images, so in my
case only the source was giving errors, maybe error in transit ?
I didn't try more tests to discover what was causing this.
Also, it was in february 2022, so things may have changed, didn't test
since.
For reference, the related Qubes post, although not containing much more
info:
https://forum.qubes-os.org/t/installation-report-payload-digest-error-for-pkg-xen-hypervisor-2001/9644
(remove bracket stuff when replying)
]
--
++
zithro / Cyril
