search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.78k stars 494 forks source link

Unable to auto-setup when armbian repo is down #5798

Open ngrigoriev opened 1 year ago

ngrigoriev commented 1 year ago

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:

ngrigoriev commented 1 year ago

It seems I was able to unblock the situation by doing this:

  1. Mounting the SD card
  2. Changing the URL in etc/apt/sources.list.d/armbian.list to "http://apt.armbian.com/region/NA"
  3. (important, not all mirrors seem to be the same) adding 'Acquire::Retries "5";' to etc/apt/apt.conf.d/97dietpi
MichaIng commented 1 year ago

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.

ngrigoriev commented 1 year ago

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.

jahway603 commented 1 year ago

I encountered this same error yesterday on a Rock64 SBC.

ngrigoriev commented 1 year ago

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.

MichaIng commented 1 year ago

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.