OrangePi apt-get update issues

Orange Pi Plus 2 with Orange Pi Plus image. Several attempts, all with similar errors at the end. Most time the errors are related to failure to update the packages provided by Index of /debian/dists/jessie/main/binary-armhf. From time to time I’m getting also some hashsum mismatch errors.

It usually goes this way:

    1. Writhe the .img to the SD card.

    1. First boot, everything goes fine, I’m seeing ‘DietPi has been updated to the latest version.’

    1. Second boot, trying to finish with ‘Install’, getting ‘Apt-get simulation has failed.’

The error is:

E: Package 'bash-doc' has no installation candidate

The apt-get update errors are:

Err jessie/main armhf Packages                                                                                                         
Err jessie/main armhf Packages
  404  Not Found [IP: 80]
Fetched 12.0 MB in 20s (581 kB/s)
W: Failed to fetch  404  Not Found [IP: 80]

W: Failed to fetch  Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old ones used instead.

So I tried:

apt-get -o Debug::Acquire::http=true  -o Debug::Hashs=true -o Debug::pkgAcquire::Auth=true update

This time it ended up with a bit more errors that can be found in the attached file.

I’m not very familiar with the apt-get update and I’m unable to debug the real cause here. From several runs I’ve spotted different issues each time, so I suspect that something is unstable and causing the errors. The SD Card was used for quite a long time on a Raspberry Pi without issues, so I suspect the OrangePi board itself. One time the gunzip and xz failed to decompress the Packages.gz/Packages.xz from Index of /debian/dists/jessie/main/binary-armhf. Other run usually ends up with different errors, but the one related to Index of /debian/dists/jessie/main/binary-armhf is always present. It is either hashsum mismatch or 404 not found.

I can help by providing ssh access to the OrangePi Plus2 with fresh install if this will be useful (we’ll have to use some 1:1 communication channel to share the details because I don’t want to let everybody in my home network). Or I can dump the SD card once the errors are hit and upload the image.
debug.log.gz (5.43 KB)

Tried a few more things.

First was to test with new SD card (good one, Samsung Evo Plus 32GB). Same error.

Another thing was to interrupt the initial setup process (the one after the first login). Tried to do apt-get update and it passed. Then apt-get upgrade and it passed again. Then did the dietpi-software process to update to version 159. This succeeded. Rebooted, selected ‘Instal’ and the apt-get update failed again.

Tried once again, but on the second reboot I modified the dietpi-software to skip the apt-get clean command. It skipped it, but got similar errors. This time two checksum mismatch errors:

W: Failed to fetch Hash Sum mismatch
W: Failed to fetch Hash Sum mismatch

I’ll try once again by limiting the version for update from 159 to something smaller. If I manage to - I’ll post the results here.

And here is the update.

I disabled the dietpi-update call and forced the dietpi-software to think that the updates have been done. A few lines of code were modified in dietpi-software for that:

		#Check for updates and apply if needed (1=force apply updates).
		# /DietPi/dietpi/dietpi-update 1
		echo 0 > DietPi/dietpi/.update_stage

As result - the dietpi-software did successful apt-get clean and apt-get update and seems to be working fine. Something in the versions between 144 and 159 is causing the apt-get update to fail.

Soooo, this may be non-related to the DietPi processes. Did the following - clean image, stopped the dietpi-software on boot, apt-get update, apt-get upgrade, reboot, apt-get update fails with the same errors. Nothing from the dietpi-software was executed.

I not sure if this is related, but wget to needs to use IPv4, not IPv6 otherwise it fails and dietpi thinks there is no internet connection.
I had to add

inet4_only = on

into /etc/wgetrc to get dietpi-update to work.

Should not be related. I’ve disabled IPv6 and in that exact case - it fails with IPv4 address in the error.