Indeed this vendor kernel, built from Hardkernel sources, has been used for our images until about 2 years ago. It did already cause too much issues (being too old) that time (with Debian Bullseye) so that we switched to Armbian’s mainline kernel builds.
It is sadly not trivially possible to migrate to the Armbian kernel, as, AFAIK, the /boot partition is too small to reliably hold the kernel and initramfs. The new images are shipped without dedicated /boot partition.
So easiest/cleanest surely is to flash a new image. If it causes you too much work, we could at least try the kernel upgrade with the /boot partition and if it really is too small just remove/ignore it and use the roofs only.
Same thing happened on my M1Plus. Reference code: abc0b41e-af6e-4b2f-acf0-e92af179f693
If I exit and manually install bluetooth, my bluetooth seems to work:
sudo apt install bluetooth bluez bluez-tools
Pretty sure a disk or RAM space issue. The script technically does the exact same thing with these packages, with the only difference that a large number of additional packages are upgraded in the same turn, hence downloaded and unpacked. Probably the download cache cleanup implied with our functions seems to solve it so that another attempt after exiting the script succeed.
We’ll see whether more users report this issue. We could hack one automated cleanup and retry into the script.
If you face it again, could you enter a subshell (from the error handler) and check:
This pretty sure is the issue: By default, packages are downloaded all to disk. A distro upgrade means several hundred MiB of packages, which are all downloaded in one batch, then (copied to /tmp one by one, it seems, and from there) unpacked one by one to replace the old files. apt itself removes all packages only after the whole process has successfully finished. Our wrapper function removes then also after a failure, i.e. when you exit the error handler.
So I am pretty sure that the disk simply was temporarily full while that bluez firmware was tried to be unpacked.
We could add a free rootfs space check to the script and warn users that this may happen in case of less than 2 GiB free space, and that in this case repeating the upgrade usually works, i.e. having package upgrades done in multiple batches.
I am really not sure about that. I think it’s related to bluez-firmware. Here is another error from my N2Plus which has ample space and RAM. Seems to fail when trying to install bluez-firmware.
root@N2Plus:/tmp/DietPi-Set_hardware# apt install bluez-firmware
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
bluez-firmware
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/185 kB of archives.
After this operation, 353 kB of additional disk space will be used.
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 35020 files and directories currently installed.)
Preparing to unpack .../bluez-firmware_1.2-9_all.deb ...
Unpacking bluez-firmware (1.2-9) ...
dpkg: error processing archive /var/cache/apt/archives/bluez-firmware_1.2-9_all.deb (--unpack):
trying to overwrite '/lib/firmware/brcm/BCM43430A1.hcd', which is also in package armbian-firmware 23.02.2
Errors were encountered while processing:
/var/cache/apt/archives/bluez-firmware_1.2-9_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Reference code: 98303d81-d3fd-4eec-bf65-2b1cc56da027
When I manually install bluetooth support using:
sudo apt install bluetooth bluez bluez-tools
I have no errors.
This is the issue. Same file is available in 2 different packages causing a conflict if you install them together. This as well explains why you are able to install them individually.
Yes exactly. I get this error when trying to turn on Bluetooth from dietpi-config. When I install manually I can skip installing the bluez-firmware which is automatically added by dietpi bluetooth install. Perhaps there is a way to remove that option or turn it off? This only happens after upgrading to Bookworm.
Ah good find. This error log line was missing somehow in the first output.
Hmm, so indeed, other than Debian’s firmware packages, Armbian’s contains two files which are as well in bluez-firmware. But several other files are missing. Not sure whether we can assume that all SBCs supported by Armbian will work without bluez-firmware then?
The BCM203x dongles, which, according to code comments, are the initial reason why bluez-firmware is now installed, will most likely not work anymore, but they are probably very old and many SBCs have onboard WiFi.
Can this script already be used on a ‘vanilla’ (ie, normal non-dev) version of DietPi with a certain level of confidence? Or should it still be considered pre-alpha?
The script can be used without problems. It’s not within an Alpha phase anymore. However this is still a Debian destro version upgrade including the usual risk
Sorry, I’m seeing the same error message when I reboot my newly bought Radax Zero. I’ve just installed the 8.19.1, which was downloaded 3-4 few days. I bet the script is for Bulleye rather than Bookworm, right?
Guess this didn’t cause much trouble apart from the prompt message. If so, I will wait till a fix is out. Thanks for the attention.
My bad, I thought it’s known. Here is the prompt after the command poweroff is executed.
Failed to set wall message, ignoring:
Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists
Call to PowerOff failed:
Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists
Or should it still be considered pre-alpha?