Open ngrigoriev opened 1 year ago
It seems I was able to unblock the situation by doing this:
Interesting idea with the retries. Better use an own config for this, since 97dietpi
is overwritten on DietPi updates:
echo 'Acquire::Retries "5";' > /etc/apt/apt.conf.d/99retries
It's a pity that some of the Armbian mirrors are so unreliable.
Not sure how to deal with this best. I'm not keen to simply ignore unreachable APT repositories, as this often requires attention, e.g. when outdated repos or suites have been taken down and need to be updated. Also ignoring failure in the update can lead to follow-up issues when actual packages are picked and tried to be installed from the existing (and then outdated) list files, which makes it only harder to debug and error-exiting in a middle of an installation very unclean.
Adding a special case for Armbian repos only? Not sure, probably it's better to keep collecting such reports, and forward to Armbian if not resolved in shorter time, as if bugs their users the same way.
What I can think of is adding a mirror selection for the Armbian repo, region and/or an explicit mirror. The list can be taken from:
Could be a dietpi.txt
setting as well.
Indeed, having this option in dietpi.txt would be great - to unblock the situation like this.
Although I would argue about the update during the initial node setup. Personally, I am for predictable results. To me, all these little SBCs are mainly silent workers, not desktops. Their configuration should be totally predictable and reproducible. Thus, if I download a DietPi image now, burn the image and run a node and I burn the same image 6 months from now for the same board, I should have exactly the same result. And if I want to automatically update, I would update to the same tag/baseline, always.
I think this is a fundamental question of "always latest and hopefully greatest" vs reproducible builds. I am not the side of the latter. I have several PINE64s and I really want to make sure that they are all identical software-wise, no matter when I reimage them.
I encountered this same error yesterday on a Rock64 SBC.
I am looking at dietpi/dietpi-software and around line 16216 there is:
# Full package upgrade on first run installs: https://github.com/MichaIng/DietPi/issues/3098
if [[ ! -f '/boot/dietpi/.skip_distro_upgrade' ]]
then
G_AGUP
# Do not repeat APT update in Run_Installations()
SKIP_APT_UPDATE=1
G_AGDUG
So, it seems that adding this dot-file will disable the auto-update and, thus, will produce the repeatable installations. That can be upgraded later to the level needed.
This flag file is for skipping the "dist-upgrade" only, which assures that kernel upgrades are done once on x86 where they would be othweise skipped. Regular "apt-get upgrades" are still always done.
Repeatable first run installs are conflicting our current aim to always skip up-to-date systems with latest security patches etc, though I see that this sometimes might not be wanted, at least not forced. Currently there are also sometimes package installs done as part of the first run setup, like marching microcode installs based on whether an Intel or AMD CPU is used on x86 systems. It wound require a larger rework to allow this, but has other benefits, like allowing an offline setup, which is a request as well: https://github.com/users/MichaIng/projects/3
So the plan could then be to combine an offline mode with reproducible mode, as one allows/implies the other.
It is not for the first time...Is there a way to specify an alternative repo URL? Right now http://apt.armbian.com/region/NA (NA mirror) works just fine, but the original one constantly fails with HTTP 500. I think it is pretty bad situation when it is impossible to provision a system because of that :(
Details:
Linux pineh64-05 5.10.60-sunxi64 #21.08.1 SMP Wed Aug 25 18:29:57 UTC 2021 aarch64 GNU/Linux
apt-get -q update
Steps to reproduce:
1. ... 2. ... #### Expected behaviour:Actual behaviour:
Extra details:
Additional logs: