MichaIng
Debian Bookworm testing and upgrade script feedback
This issue aims to collect feedback, testing results and info around the upcoming Debian Bookworm release.
Please read our article to get an overview: T.b.d.
Additional info can be found on our wiki: https://github.com/MichaIng/DietPi/wiki/Debian-Bookworm-testing
To run the Bookworm migration script on Bullseye systems:
sudo bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.meta/dietpi-bookworm-upgrade')
Used the script to update 6 VM's. On 4 it worked without issue on 2 it errored out.
Strange thing is they all had a base template......
Setting up grub-pc (2.06-8) ...
Replacing config file /etc/default/grub with new version
grub-pc: Running grub-install ...
/dev/sda does not exist, so cannot grub-install to it!
You must correct your GRUB install devices before proceeding:
DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
dpkg --configure -a
dpkg: error processing package grub-pc (--configure):
installed grub-pc package post-installation script subprocess returned error exit status 1
can you share following from the 2 VM's having an issue and another example from a system working
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
Working:
NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
xvda 8G 0 disk
|-xvda1 ext4 7G 0 part / 42e48e80-01 7e5234cc-eb02-4544-b50b-9b14cda36655
|-xvda2 1K 0 part 42e48e80-02
└─xvda5 swap 975M 0 part 42e48e80-05 b77c54c2-e515-4c40-b2a5-6297b1a2a944
Not working:
NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
xvda 8G 0 disk
├─xvda1 ext4 7G 0 part / 42e48e80-01 7e5234cc-eb02-4544-b50b-9b14cda36655
├─xvda2 1K 0 part 42e48e80-02
└─xvda5 swap 975M 0 part 42e48e80-05 b77c54c2-e515-4c40-b2a5-6297b1a2a944
Sorry. This is the non working.
NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID xvda 8G 0 disk |-xvda1 ext4 7G 0 part / 42e48e80-01 7e5234cc-eb02-4544-b50b-9b14cda36655 |-xvda2 1K 0 part 42e48e80-02 `-xvda5 swap 975M 0 part 42e48e80-05 b77c54c2-e515-4c40-b2a5-6297b1a2a944
Working: NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID xvda 8G 0 disk ├─xvda1 ext4 7G 0 part / 42e48e80-01 7e5234cc-eb02-4544-b50b-9b14cda36655 ├─xvda2 1K 0 part 42e48e80-02 └─xvda5 swap 975M 0 part 42e48e80-05 b77c54c2-e515-4c40-b2a5-6297b1a2a944 There's a difference in xvda5.
Actually that swap is not needed... Guess it's a leftover off debian 11 install (installed it from debian 11 iso) and then converted via dietpi script.
The GRUB package needs to know where it can flash GRUB to. Since we cannot know the device name you flash the image to, we use ship them with /dev/sda as most common root device name. On first GRUB update, you however needed to change this manually, if it was wrong. Looks like you did this on 4 VMs already, but not yet on 2 of them. Run manually once:
dpkg --configure grub-pc
and select the correct device name, which seems to be /dev/xvda in your case.
Since DietPi v7.5, it is adjusted automatically on first boot: https://github.com/MichaIng/DietPi/commit/d430094 So probably your two affected VMs are the only older ones. Or if the others are older as well, probably the root device name changed after first boot, e.g. if you changed some settings on the hypervisor or moved the drive to another VM.
Tried to run, got:
# dpkg --configure grub-pc dpkg: error processing package grub-pc (--configure): package grub-pc is already installed and configured Errors were encountered while processing: grub-pc
Try
dpkg --configure -a
or
apt -f install
or
apt update
apt install grub-pc
instead. Not sure which state your packages are exactly on each VM.
Doesn't help.
┌──(root💀Wireguard)-[~]
└─# apt -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
┌──(root💀Wireguard)-[~]
└─# apt update
apt install grub-pc
Hit:1 https://deb.debian.org/debian bullseye InRelease
Get:2 https://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Hit:3 https://deb.debian.org/debian-security bullseye-security InRelease
Get:4 https://deb.debian.org/debian bullseye-backports InRelease [49.0 kB]
Fetched 93.0 kB in 1s (97.8 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
grub-pc is already the newest version (2.06-3~deb11u5).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
┌──(root💀Wireguard)-[~]
└─# dpkg --configure -a
┌──(root💀Wireguard)-[~]
└─# dpkg --configure grub-pc
dpkg: error processing package grub-pc (--configure):
package grub-pc is already installed and configured
Errors were encountered while processing:
grub-pc
This is on a system where the Bookworm upgrade script just failed? Seems all fine. You can force the configuration with
dpkg-reconfigure grub-pc
This a bullseye system before the upgrade script (rolled back) because the update script was failing (this is why I reported here as asked on the announcement).
Tried the upgrade script again. Errored out. Entered "dpkg-reconfigure grub-pc" and got
/usr/sbin/dpkg-reconfigure: grub-pc is broken or not fully installed
Now I entered "dpkg --configure -a" and I could choose the device.
Seems OK now.
This would mean the issue was already there on Bullseye and just popped up due to the Bookworm upgrade. Right?
Bullseye was running fine and I had no issue booting..... So I can't tell if there was an issue. Tried the upgrade script and it failed.
Makes all sense then. You could have done dpkg-reconfigure grub-pc already before running the script, to fix the debconf entry in the first place.
OK.... Doesn't make to me but then. As I was not experiencing any issue booting. Anyway fixed now. Can't tell what /when started it.
If you find time, try to restore your backup und fix grub on Bullseye before running the update. This would be helpful and appreciated.
As I was not experiencing any issue booting.
Of course not, because GRUB is shipped with our image. It is only the GRUB package, on upgrade or reinstall, which does not know where to flash GRUB to, if the pre-configured device /dev/sda does not exist. And that package is very rarely upgraded on a stable Debian release.
PHP8.2 is not working on ARMv6
root@DietPi1:~# /usr/sbin/php-fpm8.2 --nodaemonize --fpm-config /etc/php/8.2/fpm/php-fpm.conf
Illegal instruction
root@DietPi1:~#
root@DietPi1:~# journalctl -u php8.2-fpm
Mar 26 18:09:34 DietPi1 systemd[1]: Starting php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager...
Mar 26 18:09:34 DietPi1 systemd[1]: php8.2-fpm.service: Main process exited, code=killed, status=4/ILL
Mar 26 18:09:34 DietPi1 systemd[1]: php8.2-fpm.service: Failed with result 'signal'.
Mar 26 18:09:34 DietPi1 systemd[1]: Failed to start php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager.
root@DietPi1:~#
Same with CLI. Probably a known issue with earlier PHP versions on ARMv6 which was not yet patched for Bookworm/PHP 8.2: https://bugs.launchpad.net/raspbian/+bug/2012833
Domoticz is not working on Bookworm because it requires ibssl1.1. But it is not available on Bookworm
root@DietPiOr5:~# journalctl -u domoticz.service
Apr 05 00:46:38 DietPiOr5 systemd[1]: Started domoticz.service - Domoticz (DietPi).
Apr 05 00:46:38 DietPiOr5 domoticz[2893]: /opt/domoticz/domoticz: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
Apr 05 00:46:38 DietPiOr5 systemd[1]: domoticz.service: Main process exited, code=exited, status=127/n/a
Apr 05 00:46:38 DietPiOr5 systemd[1]: domoticz.service: Failed with result 'exit-code'.
root@DietPiOr5:~#
Reported here: https://github.com/domoticz/domoticz/issues/5233 Generally support was added here: https://github.com/domoticz/domoticz/pull/5264
The problem is:
- When builds are done with libssl1.1 headers, it depends on libssl1.1.
- When builds are done with libssl3 headers, it depends on libssl3.
- So there seems to be no way around providing two builds to not loose support for older platforms.
Not sure whether there is another solution like an intermediate/higher level library which depends on either libssl1.1 or libssl3 depending on platform which can be used to overcome this problem.
EDIT: Updated our test matrix.