Upgrading to v10.0.1: no more ssh and more

Troubleshooting
1

[ INFO ] DietPi-Update | Current version : v10.0.1

Device model : RPi 4 Model B (aarch64)
arm64
Linux DietPi 6.12.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.62-+162-1+rpt1~bookworm (2026-01-19) aarch64 GNU/Linux
USB-key

Bonjour, et merci pour DietPi !
I made a update from v9.20.1 to v10.01
dietpi-update : Run now to update DietPi from v9.20.1 to v10.0.1
After that I couldn’t use ssh anymore.

ssh root@192.168.0.110

ssh: connect to host 192.168.0.110 port 22: Connection refused

I’m using Nextcloud.
Nextcloud was updated to 32.0.5 a few days before.

Now I just can access to dietpi with a screen, mouse and keyboard.

Since this upgrade, DietPi doesn’t work correctly anymore.
DietPi-Services status gives me FAILED for coturn, dropbear.
And it seems that my USB-key has problems:

critical mdium error, dev sdb, sector 1014384 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class2
and so one…

I don’t realy know what to do now.

2

To gather more information you would need to access the machine somehow, e.g. via UART or you connect a keyboard and a monitor.

3

Merci, that’s what I did.

I can’t copy past the whole upgrade process here. There are too much links in it.

4

You would need to check SSH server service log to get an understanding why it is failing

5 
journalctl -u dropbear.service
Jan 29 19:21:42 DietPi systemd[1]: Started dropbear.service - Lightweight SSH server
Jan 20 19:21:43 DietPi dropbear [594]: [594] Jan 29 19:21:43 Failed loading /etc/dropbear/dropbear_dss_host_key
Jan 20 19:21:43 DietPi dropbear [594]: [594] Jan 29 19:21:43  Not backgrounding
6

A few minutes later - I do not understand why. All the afternoon it didn’t work.

journalctl -u dropbear.service

Jan 29 19:21:42 DietPi systemd[1]: Started dropbear.service - Lightweight SSH server.
Jan 29 19:21:43 DietPi dropbear[594]: [594] Jan 29 19:21:43 Failed loading /etc/dropbear/dropbear_dss_host_key
Jan 29 19:21:43 DietPi dropbear[594]: [594] Jan 29 19:21:43 Not backgrounding
Jan 29 21:57:22 DietPi dropbear[1618]: [1618] Jan 29 21:57:22 Child connection from 192.168.0.48:33896
Jan 29 21:57:22 DietPi dropbear[1618]: [1618] Jan 29 21:57:22 Failed loading /etc/dropbear/dropbear_dss_host_key
Jan 29 21:57:36 DietPi dropbear[1618]: [1618] Jan 29 21:57:36 Password auth succeeded for ‘root’ from 192.168.0.48:33896
7

ssh now working
What’s not working

root@DietPi:\~# dietpi-letsencrypt
whiptail: symbol lookup error: /lib/aarch64-linux-gnu/libslang.so.2: undefined symbol: SLsmg_Tab_Width, version SLANG2

root@DietPi:\~# dietpi-letsencrypt 1

DietPi-LetsEncrypt
─────────────────────────────────────────────────────
Mode: Running Certbot

\[  OK  \] DietPi-LetsEncrypt | Apache webserver detected
\[  OK  \] DietPi-LetsEncrypt | Desired setting in /etc/apache2/sites-available/000-default.conf was already set: 	ServerName xxxx dot net
\[  OK  \] DietPi-LetsEncrypt | a2enmod http2
\[  OK  \] DietPi-LetsEncrypt | systemctl restart apache2
Traceback (most recent call last):
File “/usr/bin/certbot”, line 33, in
sys.exit(load_entry_point(‘certbot==2.1.0’, ‘console_scripts’, ‘certbot’)())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/bin/certbot”, line 25, in importlib_load_entry_point
return next(matches).load()
^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.11/importlib/metadata/**init**.py”, line 202, in load
module = import_module(match.group(‘module’))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.11/importlib/**init**.py”, line 126, in import_module
return \_bootstrap.\_gcd_import(name\[level:\], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “”, line 1206, in \_gcd_import
File “”, line 1178, in \_find_and_load
File “”, line 1149, in \_find_and_load_unlocked
File “”, line 690, in \_load_unlocked
File “”, line 940, in exec_module
File “”, line 241, in \_call_with_frames_removed
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 6, in
from certbot.\_internal import main as internal_main
File “/usr/lib/python3/dist-packages/certbot/\_internal/main.py”, line 31, in
from certbot.\_internal import cert_manager
File “/usr/lib/python3/dist-packages/certbot/\_internal/cert_manager.py”, line 22, in
from certbot.\_internal import storage
File “/usr/lib/python3/dist-packages/certbot/\_internal/storage.py”, line 22, in
import parsedatetime
File “”, line 1178, in \_find_and_load
File “”, line 1149, in \_find_and_load_unlocked
File “”, line 690, in \_load_unlocked
File “”, line 936, in exec_module
File “”, line 1069, in get_code
File “”, line 729, in \_compile_bytecode
ValueError: bad marshal data (unknown type code)
\[FAILED\] DietPi-LetsEncrypt | Certbot failed, please check its above terminal output. Aborting…

root@DietPi:\~# phpenmod phar
Illegal instruction
WARNING:
usage: phpenmod \[ -v ALL|php_version \] \[ -s ALL|sapi_name \] module_name \[ module_name_2 \]

root@DietPi:\~# sudo -u www-data php /var/www/nextcloud/updater/updater.phar
Illegal instruction

root@DietPi:\~# dietpi-config
nothing happens

root@DietPi:\~# dietpi-backup
nothing happens
8

I guess you have some data corruption on your usb key and it is now failing.
Or do you have maybe more usb devices connect, like hard drives?

9

Can you check for kernel error messages

dmesg -l 0,1,2,3
10

Yes, there is also an USB-Hard drive

Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: 0001
Units: sectors of 1 \* 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B641A908-47F4-B543-A12F-CEE0441FDB70

Device          Start        End    Sectors   Size Type
/dev/sda1        2048 1279012863 1279010816 609.9G Linux filesystem
/dev/sda2  1279012864 1875384319  596371456 284.4G Linux filesystem
11 
root@DietPi:\~# dmesg -l 0,1,2,3
\[    5.823871\] Bluetooth: hci0: BCM: firmware Patch file not found, tried:
\[    5.825247\] Bluetooth: hci0: BCM: ‘brcm/BCM4345C0.raspberrypi,4-model-b.hcd’
\[    5.826581\] Bluetooth: hci0: BCM: ‘brcm/BCM4345C0.hcd’
\[    5.827890\] Bluetooth: hci0: BCM: ‘brcm/BCM.raspberrypi,4-model-b.hcd’
\[    5.829228\] Bluetooth: hci0: BCM: ‘brcm/BCM.hcd’
\[    7.082425\] critical medium error, dev sdb, sector 8418176 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
\[    7.177078\] critical medium error, dev sdb, sector 8417312 op 0x0:(READ) flags 0x80700 phys_seg 28 prio class 2
\[    7.259797\] critical medium error, dev sdb, sector 1014656 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
\[    7.378067\] critical medium error, dev sdb, sector 1013792 op 0x0:(READ) flags 0x80700 phys_seg 28 prio class 2
\[    7.420409\] critical medium error, dev sdb, sector 8568864 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 2
\[    7.463490\] critical medium error, dev sdb, sector 1014016 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 2
\[    7.563974\] critical medium error, dev sdb, sector 8417536 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 2
\[    7.596194\] critical medium error, dev sdb, sector 1013792 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[    7.628599\] critical medium error, dev sdb, sector 1013792 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[    7.660322\] critical medium error, dev sdb, sector 1013792 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[   12.295321\] critical medium error, dev sdb, sector 1018144 op 0x0:(READ) flags 0x80700 phys_seg 19 prio class 2
\[   37.507397\] critical medium error, dev sdb, sector 1014384 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 2
\[   38.103732\] critical medium error, dev sdb, sector 1013992 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[   38.219428\] critical medium error, dev sdb, sector 1014272 op 0x0:(READ) flags 0x80700 phys_seg 14 prio class 2
\[   38.269059\] critical medium error, dev sdb, sector 1014376 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[   38.304890\] critical medium error, dev sdb, sector 1014384 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[  192.001285\] critical medium error, dev sdb, sector 1018208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[ 1029.847583\] critical medium error, dev sdb, sector 1014176 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[ 2511.008535\] critical medium error, dev sdb, sector 13113344 op 0x0:(READ) flags 0x80700 phys_seg 20 prio class 2
\[ 2511.080195\] critical medium error, dev sdb, sector 13113440 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[ 2511.393328\] critical medium error, dev sdb, sector 13145880 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
\[ 2512.895711\] critical medium error, dev sdb, sector 13117144 op 0x0:(READ) flags 0x80700 phys_seg 27 prio class 2
\[ 2512.981459\] critical medium error, dev sdb, sector 13117184 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[ 2513.065820\] critical medium error, dev sdb, sector 13117208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[ 9228.480901\] critical medium error, dev sdb, sector 1472288 op 0x0:(READ) flags 0x80700 phys_seg 13 prio class 2
\[ 9228.539021\] critical medium error, dev sdb, sector 1472544 op 0x0:(READ) flags 0x80700 phys_seg 28 prio class 2
\[ 9228.586751\] critical medium error, dev sdb, sector 1472768 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 2
\[ 9228.648814\] critical medium error, dev sdb, sector 1472744 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
\[ 9228.721948\] critical medium error, dev sdb, sector 1472552 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
12 
Disk /dev/sdb: 57.3 GiB, 61524148224 bytes, 120164352 sectors
Disk model:  SanDisk 3.2Gen1
Units: sectors of 1 \* 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc7497348

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sdb1  \*      2048    264191    262144  128M  c W95 FAT32 (LBA)
/dev/sdb2       264192 120164351 119900160 57.2G 83 Linux
13

Looks like your UBS key is dying.
Do not boot from it anymore. If you can, flash a new system to another disk and restore a backup, I hope you have one. The best would be a backup which is already some weeks old, so you can be sure yo didn’t backup any corrupted data already,

You could also try to mount the stick on another system and copy files, but you can not trust it anymore, it’s possible you will copy already corrupted data.

14

can you share following

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid

Usually boot partition is on sda not sdb. I guess there are more devices attached. Are these real HDD/SSD or pend sticks only?

15 
root@DietPi:\~# lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME   FSTYPE LABEL   SIZE RO TYPE MOUNTPOINT      PARTUUID                             UUID
sda                 894.3G  0 disk
├─sda1 ext4         609.9G  0 part /mnt/IronWolf-1 507bcf66-fef7-4563-b7ed-451ad2f40fc9 b1833a7f-e565-404b-a37b-d6a8ddb67275
└─sda2 ext4         284.4G  0 part                 f737680d-f5fb-4b24-b435-f92848cfe325 2cd4df77-863c-4389-8b6d-131036980f89
sdb                  57.3G  0 disk
├─sdb1 vfat           128M  0 part /boot/firmware  c7497348-01                          B2B3-E3EB
└─sdb2 ext4          57.2G  0 part /               c7497348-02                          c61029cd-9530-49f2-a9eb-52d8117beb38

sda is the SSD in a USB ICY BOX with its one electric power with all the user data from Nextcloud.

Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: 0001
Units: sectors of 1 \* 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B641A908-47F4-B543-A12F-CEE0441FDB70

Device          Start        End    Sectors   Size Type
/dev/sda1        2048 1279012863 1279010816 609.9G Linux filesystem
/dev/sda2  1279012864 1875384319  596371456 284.4G Linux filesystem

sdb is the USB stick with the boot partition and the dietpi.

Disk /dev/sdb: 57.3 GiB, 61524148224 bytes, 120164352 sectors
Disk model:  SanDisk 3.2Gen1
Units: sectors of 1 \* 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc7497348

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sdb1  \*      2048    264191    262144  128M  c W95 FAT32 (LBA)
/dev/sdb2       264192 120164351 119900160 57.2G 83 Linux
16

Ok this unfortunately confirms your boot media has serous issues and corruption leading to the effects you see.

17

Merci, Joulinar, and Jappe, for your answers and this analysis.
I have a backup of all the data from the harddrive (sda), but not from the boot media (sdb).
What would be your solution to reinstall a boot media and link the hard drive with all the data ?
I am a bit disappointed, I have changed the boot media from sdcard to a USB-stick because of a lot of problems with the sdcards…

18

You don’t need a backup of the harddrive (sda) you need a backup of the stick (sdb) or at least of sdb2, this is where your DietPi system lives, right?
At least this is how it looks to me

sda is just an external hard disk with some data on it? But the DietPi system is on sdb, sdb1 is the boot partition and sdb2 the system.
Did you maybe made a backup with dietpi-backup somewhen?

19

I don’t have any backup of the USB-stick (sdb).
What would be your solution to reinstall a boot media and link the hard drive (sda) with all the data ?

20

You have only Nextcloud installed on the system? Is /mnt/dietpi_userdata still located on the USB stick or is that as a whole on the external SSD?

Generally, to preserve the Nextcloud instance, /var/www/nextcloud, /mnt/dietpi_userdata/mysql (database), and of course /mnt/dietpi_userdata/nextcloud_data, or whichever alternative Nextcloud data dir you chose via dietpi.txt, are needed.

Safer than the raw database files would be an SQL dump. For for this, MariaDB would need to be running:

systemctl status mariadb

If so, you could create a backup, e.g.:

sudo mysqldump nextcloud > /mnt/dietpi_userdata/nextcloud.sql

If this works, you could flash a completely fresh system, copy the Nextcloud data dir, /var/www/nextcloud and the nextcloud.sql to specific locations of the new system, from where dietpi-software would import them on a Nextcloud installation.

2nd best, if the mysqldump fails, e.g. because MariaDB fails due to the USB stick issues, would be to copy the raw database files + /var/www/nextcloud (and Nextcloud data) to the same locations of the new system before installing Nextcloud. It should also migrate things then, would would additionally require MariaDB to upgrade the older (Bookworm) database to the newer MariaDB version, leaving possibly older table/data types in place etc.