MichaIng

First of all, I think on login, there should be a warning that no matching terminal definition has been found, isn't it? It should even automatically set the `TERM` variable...

As you are not the first running into this, let me reopen and think about how we can solve this a clever way automatically with our login scripts.

It is preserved, which is the problem, as `root` does not have this definition in its home dir. It could be explicitly reset/set to `xterm`, but then the nice kitty...

Many thanks for your report. The reason might be that Dropbear turned into a native systemd service with Bookworm, while previously it was an init.d service. The difference is that...

Sent upstream: https://github.com/fail2ban/fail2ban/pull/3597 When merged, I'll ask Debian to backport this as a patch to their Bookworm package.

Fixed with: https://github.com/MichaIng/DietPi/commit/7095f96 Since my upstream PR is ignored, I'll send a merge request with a patch to Debian instead: https://salsa.debian.org/python-team/packages/fail2ban/-/tree/master/debian/patches

Probably there was a concurrent cron job execution. Oh, I see we need to unmount the temporary rootfs mount on failure. Please run `umount /tmp/dietpi-rpi-firmware-migration/rootfs && rm -R /tmp/dietpi-rpi-firmware-migration` before...

Sent to Debian: https://salsa.debian.org/python-team/packages/fail2ban/-/merge_requests/10 I'l mark this as closed now, as it is solved for DietPi users and I did all I can to solve it for Debian and upstream...

Uhh, there is more broken: https://github.com/fail2ban/fail2ban/issues/3791 One thing in Dropbear itself: https://github.com/mkj/dropbear/pull/316 The most important cases (wrong password) are again successfully tracked, but login attempts with wrong users cannot be...

It generally makes sense to check which process actually accesses `/boot`, before breaking something potentially unintended 😉. Usually nothing but our scripts and APT commands should access this mount point....