Dietpi update for armbian-firmware apt upgrade fails

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | 9.9.0
  • Distro version | bookworm
  • Kernel version | 6.6.56-current-rockchip64
  • Architecture | arm64
  • SBC model | Rock 4C Plus

Additional Information (if applicable)

  • Software title | apt upgrade

Steps to reproduce

  1. apt update
    system output:
    The following packages will be upgraded:
    armbian-firmware
  2. apt upgrade

Expected behaviour

apt upgrade should complete successfully

Actual behaviour

apt upgrade hangs and never completes
System output:
Get:1 Index of /apt all/rock4cplus all armbian-firmware all 25.02.0-trunk-dietpi1 [91.7 MB]

Extra details

I have had v9.9.0 on Rock 4C Plus working perfectly and had prompt for 1 apt update available. On following the update steps, it detected armbian-firmware package (25.02.0-trunk-dietpi1) available to update but had some error message and did not complete. Initially ignored thinking temporary issue but then I decided to do a fresh install of Dietpi and now initial first run setup is stuck trying to update the same package and hangs forever.

Here is printout from console:

 ─────────────────────────────────────────────────────
 DietPi v9.9.0 : 23:13 - Sun 05/01/25
 ─────────────────────────────────────────────────────
 - LAN IP : 192.168.1.94 (wlan0)
[  OK  ] DietPi-Software | Initialised database
[  OK  ] DietPi-Software | Reading database

 DietPi-Software
─────────────────────────────────────────────────────
 Step: Applying initial first run setup steps

[  OK  ] DietPi-Software | Checking IPv4 network connectivity
[  OK  ] DietPi-Software | Checking IPv6 network connectivity
[  OK  ] DietPi-Software | Checking DNS resolver
[  OK  ] DietPi-TimeSync | systemctl stop systemd-timesyncd
[  OK  ] DietPi-TimeSync | mkdir -p /run/systemd/timesync
[ INFO ] DietPi-Software | APT update, please wait...
Hit:1 https://deb.debian.org/debian bookworm InRelease
Hit:2 https://deb.debian.org/debian bookworm-updates InRelease
Hit:3 https://deb.debian.org/debian-security bookworm-security InRelease
Hit:4 https://deb.debian.org/debian bookworm-backports InRelease
Hit:5 https://dietpi.com/apt bookworm InRelease
Hit:6 https://dietpi.com/apt all InRelease
Reading package lists...
[  OK  ] DietPi-Software | APT update
[ INFO ] DietPi-Software | APT dist-upgrade, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  armbian-firmware
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 91.7 MB of archives.
After this operation, 134 kB of additional disk space will be used.
Get:1 https://dietpi.com/apt all/rock4cplus all armbian-firmware all 25.02.0-trunk-dietpi1 [91.7 MB]

Wifi connection seems ok as NTP server check is working.

I have rebooted the server multiple times but since it’s fresh install, it’s trying to go through apt upgrade and this is the only particular package it has to update but never completes.

I cannot think of any other way to bypass this step and complete the setup it needs to.

Is there an issue with this armbian-firmware package or something inside dietpi script?

How long did you wait? It might take a while to download the package. Personally I have seen some really rar cases where a package download could be extremely slow

Twice I waited for 15 mins before restarting session. I noticed command sequence of multiple attempts being made.

Get 1…
Ign 1…
Get 1…
Ign 1…
Get 1…

Edit: corrected typo for Get.

Please keep it running for a while and share the log. At least I don’t see the ignore within the log above

I retried today and had a success. The same package downloaded and install without much trouble. I will take that yesterday’s experience was just one off taking infinite to download.

Thanks @Joulinar for your swift guidance and it worked. Much appreciated!

We know, some ISP in EU have a very poor peering with Cloudflare, where our side is hosted behind. It’s a rar case but could happen. https://community.cloudflare.com/t/bad-latencies-and-download-rates-due-to-missing-peering-with-deutsche-telekom-ag/681147

But nobody from Cloudflare or ISP side is willing to solve this.