I have searched the existing open and closed issues
Required Information
DietPi version | G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=6 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng'
Distro version | bookworm
Kernel version | Linux pihole 5.10.160 #1 SMP Tue Jul 4 15:42:58 CST 2023 aarch64 GNU/Linux
Architecture | arm64
SBC model | NanoPi R5S/R5C (aarch64)
Power supply used | 5V 3A
SD card used | internal flash used
Device model : NanoPi R5S/R5C (aarch64)
Additional Information (if applicable)
Steps to reproduce
Try to install dietpi v9.7.1
after sometime Vorbereitung zum Entpacken von .../armbian-firmware_24.8.0-trunk-dietpi2_all.deb ... Entpacken von armbian-firmware (24.8.0-trunk-dietpi2) über (24.8.0-trunk-dietpi2) ... client_loop: send disconnect: Broken pipe
connection is lost after sometime reestablished and I need to »sudo dpkg --configure -a« ausführen, um das Problem zu beheben.
after doing sudo apt-get upgrade -y manually same behaviour
Expected behaviour
normal install
Actual behaviour
broken pipe after sometime during instalation of armbiam firmware
sudo dpkg --configure -a goes through without issues?
In which state is the package after that?
dpkg -l armbian-firmware
So you are running the update via SSH and are connected via Ethernet or WiFi? It seems like replacing the firmware binaries aborts the network connection of the adapter which uses this firmware. But it is weird, since AFAIK the firmware is only loaded once with the kernel module/driver, and is not required anymore afterwards. I regularly upgrade firmware packages for WiFi adapters in use, and it does not affect current connections. Also I never heard of such ever happening in any other case. But it is maybe too much of a coincidence that this very package unpacking aborts the network connection for a while.
EDIT: Is it an Intel or Qualcomm/Atheros WiFi adapter? I see you are likely doing the major kernel upgrade, in which case the firmware packages for those two are purged first, the Armbian firmware package installed afterwards. It is needed since there are conflicts for those missing, else it would be done in one step, with less time between them, If this turns out to be the issue, I’ll manually add the missing conflicts to our package, and crate a fork to have this added in all feature builds of the package as well.