Dietpi: Problem mit Cron und Auto Backup (von v6.10-6.11)?

@eljotx
Vielen Dank für Ihren Bericht.

G_USER_INPUT=0 sollte bei Cron-Ausführungen automatisch erkannt werden und muss daher nicht zugewiesen werden. Aber wenn Sie möchten, dass es Auswirkungen hat, müssen Sie es exportieren. Dies ist natürlich einen Versuch wert:
export G_USER_INPUT=0

Bei nicht interaktiven Ausführungen wird das Skript beendet, wenn auf dem Ziellaufwerk (nahezu) nicht genügend freier Speicherplatz festgestellt wird: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
Aber Sie sagen, manuelle Ausführung funktioniert gut? Im Falle eines unzureichenden freien Speicherplatzes wird eine Whiptail-Eingabeaufforderung angezeigt, die Ihnen die Wahl lässt, diese zu ignorieren oder zu beenden.

Über die Protokolleinträge werden einige kryptische Farbcodes + checking for elevation root access erwartet. Versuchen:
cat /mnt/rpi/backup.log
um die Farbcodes aktiv und damit das Protokoll formatiert zu haben. Bitte geben Sie diese Ausgabe auch hier an, damit wir überprüfen können, in welchem ​​Stadium das Problem aufgetreten ist.

Das Skript funktioniert gut, wenn ich es manuell ausführe.

Seltsam.

Versuchen Sie, den Cron-Job auszuführen, und fügen Sie die Protokollergebnisse /mnt/rpi/backup.log

NB: dietpi-backup gibt rsync automatisch in die Protokolldatei /var/log/dietpi-backup.log . Sie können dies auch verwenden.

Also versuche ich, den Cron-Job ohne G_USER_INPUT = 0 auszuführen (ich habe dies aus dem Skript entfernt) und ...

Meine Sicherungsprotokolldatei aus /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m

dietpi-backup.log ist leer

Ich habe nach dem Start von cron keinen aktiven Prozess mehr gesehen.

Also habe ich zum Testen eines anderen Skripts hinzugefügt, um die Ausgabe in der Datei nach dem Start von cron zu sehen:

#!/bin/sh

echo 'Cron works!' > /mnt/rpi/cronworks.log

Dieses Skript wurde jedoch nicht gestartet. Es gibt keine Datei "cronworks.log" unter / mnt / rpi /
Es ist seltsam, weil es eine Ausgabedatei (backup.log) von meinem Skript mit Backup (vom 1. meines Beitrags) gibt, aber nein von diesem einfachen

@eljotx
Okay, es scheint mindestens genauso gut einen Fehler mit cron zu geben. Beachten Sie, dass cron die Skripte über run-parts /etc/cron.X/script startet und es einige Regeln gibt, z. B. müssen die Skripte im Besitz von root (AFAIK) sein und sicherer, dass die Skripte keine Dateienden haben dürfen. Das bedeutet, dass /etc/cron.daily/script.sh übersprungen wird, der Name muss stattdessen /etc/cron.daily/script .

Es sollte auch nicht benötigt werden, aber versuchen Sie, #!/bin/bash als Shebang zu verwenden, wenn Sie mit DietPi-Skripten arbeiten. Diese selbst haben #!/bin/bash , aber um ausfallsicher zu sein, versuchen Sie, es auch im Cron-Skript zu verwenden.

Das Skript hatte immer den Namen "backup" (ohne .sh), ich ändere "#! / Bin / sh" auch im Skript in "#! / Bin / bash", und dieses Skript gehört root. Mein "Test" -Skript aus dem letzten Beitrag funktioniert jetzt auch.

Ich habe alles versucht, funktioniert aber immer noch nicht. Ich ändere das Skript so, dass es nach Abschluss eines Jobs in eine Protokolldatei gedruckt wird, und ich habe gesehen, dass das Skript gestartet wird, aber die Sicherung nicht gestartet oder beendet wird (dietpi-backup.log ist leer), da nicht zum nächsten Auftrag wie tar, rclone usw. Und auch nachdem ich cron ausgeführt habe, habe ich gesehen, dass process / usr / sbin / cron -f funktioniert und -bash - ist das normal?

Das Skript funktioniert immer noch, wenn ich es manuell ausführe. Wenn die Sicherung abgeschlossen ist, muss ich auf OK klicken und abbrechen (Whiptail-Bildschirme). Danach werden die nächsten Jobs gestartet.

Ich denke, dass das Problem mit der Verwendung von Dietpi-Backup für Auto-Backup von Cron gestartet ist. Es funktionierte auf Version 6.9, aber nach dem Umschreiben von dietpi-backup funktionierte es nicht mehr.

@eljotx
Also nochmal, nur um sicher zu gehen:

• Wenn Sie manuell ausführen /DietPi/dietpi/dietpi-backup 1 wird erfolgreich durchlaufen?
• Wenn Sie G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1 ausführen, funktioniert dies ebenfalls fehlerfrei und zeigt Folgendes an:
  

root@VM-Jessie:~# G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

[  OK  ] DietPi-Backup | Checking for pre-req APT packages: rsync
[ INFO ] DietPi-Backup | Flagged for installation: rsync
[  OK  ] DietPi-Backup | APT installation for: rsync, please wait...
Selecting previously unselected package rsync.
(Reading database ... 36227 files and directories currently installed.)
Preparing to unpack .../rsync_3.1.1-3+deb8u1_amd64.deb ...
Unpacking rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...
Setting up rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...

[  OK  ] DietPi-Backup | G_AGI: rsync

 DietPi-Backup
─────────────────────────────────────────────────────
 Mode: Backup

[  OK  ] DietPi-Backup | DietPi-Userdata validation: /mnt/dietpi_userdata
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | occ maintenance:mode --on
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ INFO ] DietPi-Backup | Backing up to: /mnt/dietpi-backup
[  OK  ] DietPi-Backup | Free space check: path=/mnt/dietpi-backup/data | available=5695 MB | required=1861 MB
[  OK  ] DietPi-Backup | rsync -aH --delete --delete-excluded --exclude-from=/tmp/.dietpi-backup_filter_inc_exc -v --log-file=/var/log/dietpi-backup.log / /mnt/dietpi-backup/data/
[ INFO ] DietPi-Backup | Backup Completed:

Backup was saved to:
- /mnt/dietpi-backup
- Log file: /var/log/dietpi-backup.log
[ SUB1 ] DietPi-Services > start
[  OK  ] DietPi-Services | start : mysql
[  OK  ] DietPi-Services | start : php5-fpm
[  OK  ] DietPi-Services | start : lighttpd
[  OK  ] DietPi-Services | start : sonarr
[  OK  ] DietPi-Services | start : cron
[ SUB2 ] DietPi-Process_tool > Apply
[  OK  ] DietPi-Process_tool | Completed
[  OK  ] DietPi-Services | occ maintenance:mode --off

• Ausführen der genauen Befehlszeile aus dem Skript

/DietPi/dietpi/dietpi-backup 1 > /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: -L >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz >> /mnt/rpi/backup.log && reboot

funktioniert auch und zeigt, dass alle in /mnt/rpi/backup.log ausgeführt und beendet wurden?

• run-parts --test /etc/cron.daily listet Ihr Skript auf (wenn es täglich verfügbar ist, ansonsten anpassen)
• /usr/sbin/cron -f + -bash wird ja erwartet, da es aufgrund von #!/bin/bash eine Bash-Umgebung startet.

Wenn all dies zutrifft, können Sie versuchen, Run-Parts manuell zu starten und zu prüfen, ob sie wie erwartet ausgeführt werden:

• Verschieben / Kopieren des Skripts in einen separaten Ordner, z. B. ~/testdir/backup
• Dann run-parts ~/testdir

Ich habe getestet, wie Sie zeigen, und bei jeder Ihrer Fragen: Ja, alles funktioniert, wenn ich es manuell starte.
Ich habe es mit dem Befehl run-parts getestet, aber es funktioniert immer noch - wenn ich es manuell mache.

Mein Skript wird nach der Verwendung von run-parts --test /etc/cron.daily aufgelistet

Wenn ich G_USER_INPUTS = 0 hinzufüge und das Skript manuell starte, sollte ich dann die Bildschirme (Whiptail) mit Informationen zum Protokoll usw. sehen? Weil ich es immer sehe.

@eljotx
G_USER_INPUTS=0 deaktiviert nur die Anzeige von Whiptail-Menüs. Informationen werden nur als Terminalnachrichten angezeigt und Fragen werden mit "Nein" beantwortet (Abbrechen bei unzureichender Überprüfung des freien Speicherplatzes, keine Protokollansicht).

Um es für das Skript zu erzwingen, müssen Sie es entweder exportieren, bevor Sie das Skript ausführen:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

oder einfacher, geben Sie es einfach direkt weiter: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1

Ich habe gerade erkannt, dass Sie G_USER_INPUT=0 oben ohne S haben. Es muss G_USER_INPUTS=0 mit S .

Wenn die Variable nicht exportiert wird, bestimmen Skripte, ob Benutzereingaben vorgenommen werden können oder nicht. Bei der Ausführung von Cron- und z. B. Systemd-Einheiten sollten alle DietPi-Skripte automatisch G_USER_INPUTS=0 ermitteln und zuweisen.
Sie können überprüfen, ob unsere Methode funktioniert, indem Sie zum Start Ihres Cron-Jobs (oder eines Testjobs) Folgendes hinzufügen:
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
Wenn das Skript manuell ausgeführt wird, sollte angegeben werden, dass Benutzereingaben zulässig sind (Whiptail-Menüs werden angezeigt). Wenn es über Cron gestartet wird, sollte dies nicht der Fall sein, und keine Whiptail-Menüs sollten das Skript hängen lassen.

Zuerst teste ich G_USER_INPUTS=0 und wenn ich das Skript manuell starte, logge ich mich ein:
This environments allows user inputs
sonst wenn mit cron anfangen:
This environment does not allow user inputs

Als nächstes versuche ich mein Skript folgendermaßen zu ändern:

#!/bin/bash
export G_USER_INPUTS=0
date > /mnt/rpi/backup.log && /DietPi/dietpi/dietpi-backup 1 && (echo "Backup: DONE. " >> /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ && echo "Tar backup: DONE. " >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: && echo "Copy to GDrive: DONE. " >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz && echo "Remove tar: DONE." >> /mnt/rpi/backup.log && reboot) || echo "Backup failed!" >> /mnt/rpi/backup.log

und dietpi-backup.log ist noch leer, aber backup.log:

als cron gestartet wurde und dieses Skript automatisch startet:

pon, 9 lip 2018, 18:54:01 CEST
Backup failed!

als ich das Skript manuell startete:

pon, 9 lip 2018, 18:58:40 CEST
Backup: DONE.
Tar backup: DONE.
Copy to GDrive: DONE.
Remove tar: DONE.

Es ist sehr nervig ... als nächstes hat mein Skript nur:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

und funktioniert immer noch nicht, wenn dieses Skript von cron gestartet wird.

Das Problem ist immer noch, dass Dietpi-Backup von Cron ab Version 6.10 gestartet wurde. Ich denke, das ist ein Problem mit den Änderungen, die Sie in Version 6.10 im Dietpi-Backup-Skript vorgenommen haben.

dietpi-backup.log ist noch leer

@eljotx
Vielen Dank für Ihre Testanstrengungen.
Ich werde unsere veränderten durchgehen. Habe bisher keine Ahnung. Zumindest nach Ihren Tests hängt das Skript tatsächlich nicht (whiptail / G_USER_INPUTS ist nicht das Problem), aber es schlägt fehl.

Einige eigene Tests durchgeführt:

[......] Checking for (elevated) root access

Nach dem Kommentieren der Root-Benutzerprüfung führt die Ausführung innerhalb von dietpi-backup über cron zu:
[FAILED] RootFS is currently Read Only, unable to continue.
Aber:

root@VM-Jessie:~# G_CHECK_ROOTFS_RW
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

@eljotx

tput ist das Problem:
tput: No value for $TERM and no -T specified

• Interessant, wie wir das auch mit v6.9 nannten 🤔.

Fix: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090

Dieser Patch behebt auch ein anderes Problem: "run_ntpd 1", das täglich oder stündlich von cron ausgeführt wird, synchronisiert die Zeit nicht (der Zeitstempel von / var / lib / systemd / clock ändert sich nicht).

@kmakisara
Jep du hast recht, das macht Sinn.
Um zu vermeiden, dass manuelle Skripte bearbeitet werden, um Korrekturen anzuwenden, sollten alle mit demselben Problem Folgendes tun: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

Ich denke, einige unserer offenen Fragen hängen damit zusammen. Wenn run_ntpd in cron.hourly fehlschlägt, wird dietpi-logclear auch danach nicht mehr aufgerufen, was zum Auffüllen von / var / log führt: https://github.com/Fourdee/DietPi/issues/ 1920

Ich frage mich nur, warum dieses Problem zuerst mit Version 6.10 + aufgetreten ist, da wir bereits zuvor tput in unseren Cron-Jobs verwendet haben.
Vielleicht kann jemand die Veränderung finden, die die Probleme verursacht hat, damit wir wissen, wie wir uns in Zukunft besser darum kümmern können:

• Aufruf der animierten Prozessbenachrichtigung v6.9: https://github.com/Fourdee/DietPi/blob/7b682286e72ef339518d110892a54e7ce405b648/dietpi/func/dietpi-globals#L301 -L315
• Mit Version 6.10 vorgenommene Änderungen: https://github.com/Fourdee/DietPi/pull/1867/files
• tput cuu und tput cols in beiden Fällen sowie tput ed bei jeder anderen DietPi-Benachrichtigung beim Löschen der Verarbeitungsanimation aufgerufen.
• Möglicherweise waren es nicht die Änderungen an den Benachrichtigungen, die das Problem verursacht haben, sondern die Cron-Behandlung von Fehlern (oder Tputs) nach bestimmten Aktualisierungen.

Weitere Tests dazu:

root@VM-Stretch:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root@VM-Stretch:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified

• $TERM auf cron ist auf dumb
• tput behauptet, dass es keinen Wert für die Variable gibt, auch wenn dieser ungültig ist.

root@VM-Stretch:/tmp# TERM='dumb' tput cols
237
root@VM-Stretch:/tmp# export TERM='dumb' tput cols
root@VM-Stretch:/tmp# export TERM='dumb' tput cols && echo continue
continue

• Da ungültiges $ TERM zu keinem Fehler führt (nur zu keiner Ausgabe von tput), scheint der Fehler von cron tput damit zu zusammenhängen, dass -T fehlt, [[ -t 0 ]] zu false führt. Vielleicht hat sich auch das vorher anders verhalten. Letztes ncurses-bin APT-Update am 15.02.2018: http://ftp.de.debian.org/debian/pool/main/n/ncurses/

• Wir hatten bereits Probleme mit nicht interaktiven / ungültigen Terminals. Beenden Sie daher jetzt Dietpi- * Skripte, wenn leere $ TERM oder ' unknown ' gefunden werden: https://github.com/Fourdee/DietPi/blob/ Testen / Dietpi / Funk / Dietpi-Globals # L30 -L35

• Ein inkonsistentes Gebot, da wir möglicherweise nicht interaktive Ausführungen zulassen möchten (auch ohne angeschlossenes Terminal), aber darauf achten müssen, tput bzw. andere Befehle aufzurufen, die ein gültiges Terminal benötigen.

Test auf v6.9:

root<strong i="6">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Der Fehler wird angezeigt, das Skript wird jedoch fortgesetzt.

Das APT-Update enthält keine Cron und / oder Flüche (Reduzierung durch getestete, nicht verwandte Pakete):

• Auch nach apt-get dist-upgrade und Neustart stoppt cron die Ausführung nach einem Eingabefehler nicht:

root<strong i="15">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="16">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• dietpi-update bis v6.11 master: Sehr seltsam, immer noch kein Problem ...

root<strong i="22">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Hinzufügen einer Dietpi-Backup-Ausführung:

root<strong i="27">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
/DietPi/dietpi/dietpi-backup 1 &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="28">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
[......] Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 266: ( 38 + 6 ) /  : syntax error: operand expected (error token is "/  ")
finish

• Das Skript schlägt fehl, aber der Cron-Job wird fortgesetzt. Test mit dietpi-globals v6.9:

root<strong i="34">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
         Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
tput: No value for $TERM and no -T specified
[  OK  ] Root access verified.
         DietPi-Run_ntpd | systemctl restart systemd-timesyncdtput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
[..    ] tput: No value for $TERM and no -T specified
[  OK  ] DietPi-Run_ntpd | systemctl restart systemd-timesyncd
[ INFO ] DietPi-Run_ntpd | NTPD: Waiting for completion of systemd-timesyncd (1/60)
[  OK  ] DietPi-Run_ntpd | NTPD: systemd-timesyncd synced
[  OK  ] NTPD: time sync | Completed
finish

- Okay, es hängt mit globalen Änderungen zusammen, aber da tput fehlgeschlagen ist und nicht, warum werden unsere Skripte jetzt beendet und nicht auf Version 6.9 beendet?

Verwandte Änderungen identifiziert: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) )) führt zum vollständigen Beenden des Skripts, während (vorherige)

local lines
(( lines=(${#input_string}+6)/$(tput cols) ))

zeigte den Fehler, ließ aber das Skript weiterlaufen (siehe oben).

Fix https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 funktioniert und ist auch die sauberste Lösung, da tput in nicht interaktiven Shells vollständig übersprungen werden. Um jedoch ausfallsicher zu sein, sollten wir zur vorherigen Methode zurückkehren, um zuerst die Variable zu deklarieren und anschließend in der arithmetischen Umgebung einen Wert zuzuweisen: Commit done https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

@eljotx @kmakisara
Um ein Gebot zu bereinigen, habe ich ein neues Problem eröffnet. Versuchen Sie, das dort erwähnte Update anzuwenden, und melden Sie es zurück, wenn alle Probleme behoben sind :

Ich werde dieses Problem zugunsten des neuen schließen.

Ich konnte erfolgreich in meine v6.13 ssh, aber es würde gleich danach hängen.

Der Befehl "tput cols" gab tput: unknown terminal "rxvt-256color" aus , was zu einem leeren Wert in Zeile 328 der dietpi-Anmeldung führte, sodass er nach dem erfolgreichen Lesen der Datenbank beim ersten Start für immer hängen blieb.

Das Exportieren von TERM = xterm, einem hässlichen Hack, schien das Anmeldeskript behoben zu haben und kann nun mit der Installation beginnen.

Wenn dies der falsche Abschnitt ist, haben Sie bitte etwas Geduld, da ich nicht wirklich weiß, wie man Github-Probleme verwendet. Ich habe diesen Thread nach stundenlangem nutzlosem googeln nach einem Fehler gefunden. Wenn Sie ihn verschieben, bleibt möglicherweise ein Rest über rxvt-256color-Fehler übrig, falls jemand das gleiche Problem hat.

Freundliche Grüße!

@ Wuhei

Hallo,

Danke für den Bericht und die Lösung 👍

Welchen SSH-Client verwenden Sie?

@ Vierer
Ich habe dafür eine separate Ausgabe eröffnet. Identifizierte das Problem: https://github.com/Fourdee/DietPi/issues/2034

@ Wuhei
Nachdem Sie sich bei SSH angemeldet haben, versuchen Sie bitte: export TERM='xterm-256color' €: Ah, das ist im Grunde das, was Sie bereits herausgefunden haben 😄.
Wenn dies funktioniert, können Sie /etc/profile.d/ ein Skript hinzufügen, das Folgendes enthält:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• In Worten: Wenn es sich um eine SSH-Verbindung handelt und der SSH-Client ein 256-Bit-Farbterminal übergeben hat, passen Sie es auf xterm-256color , was von DietPi unterstützt wird.

Eine Alternative wäre, ein Paket zu installieren, das mehr Terminaldefinitionen enthält: G_AGI ncurses-term

@Fourdee OpenSSH_7.7p1, OpenSSL 1.1.0h unter Arch Linux

@MichaIng danke froh, dass ich zufällig helfen konnte!

Bitte denken Sie daran, dass ich ein schlechter Systemadministrator bin. Wenn ich diesem Artikel von Tom Ryder folge, habe ich herausgefunden, dass ich eine ziemlich falsch konfigurierte Terminal "Deklaration" -Konfiguration hatte.

Am Ende war das Problem für mich behoben

• Exportieren des korrekten $ TERM in /root/.bashrc
• Kopieren des korrekten terminfo-Eintrags aus meiner Arch-Installation in den Ordner /root/.terminfo des pi

Ich konnte die terminfo-Datei nicht auf meinen pi scp, da scp nicht installiert ist (vielleicht sollten Sie sie zusammen mit dem Dropbear-Server installieren?), Also habe ich sie auf einen Server hochgeladen, den ich besitze, und sie einfach vom pi heruntergeladen.

Ich bin froh, dass ich helfen konnte, Prost und entschuldige mich noch einmal für das Chaos - rock on!

@ Wuhei
Jep, das Setzen von $ TERM innerhalb von /root/.bashrc funktioniert natürlich auch, wenn es zu /etc/profile[.d/] hinzugefügt wird, wird es systemweit für alle Benutzer gelöst, was eine Lösung ist, die wir mit DietPi anstreben würden.

Der Artikel, den Sie verlinkt haben, ist ziemlich nett und erklärt alles und die Möglichkeiten sehr gut 👍. Sie haben den erforderlichen Terminaltyp also grundsätzlich manuell installiert. In dem Artikel wird auch das Paket ncurses-term als Option zur Installation einer Vielzahl von Terminaldefinitionen erwähnt. Aber um DietPi schlank zu halten, möchte ich dieses Paket für solche seltenen Fälle nicht vorinstallieren. Verwenden Sie stattdessen besser die bashrc / profile-Lösung. Es ist auch möglich, einfach die Terminalunterstützung zu überprüfen, bevor das Update auf die SSH-Anmeldung angewendet wird.

Zum Testen mit dem PuTTY-Client: PuTTY> Connection > Data > Terminal-type string

Informationen zur Installation von SCP: Es gibt verschiedene andere Dateiübertragungsprotokolle, FTP, SFTP oder Netzwerklaufwerke NFS, SMB, um Dateien zu übertragen. Ich würde keine Vorinstallation durchführen, sondern dem Benutzer die Wahl überlassen, wie Dateien vom Client zum Server übertragen werden sollen. USB-Stick, externes Laufwerk ist natürlich auch möglich oder einfach kopieren und in SSH-Terminal einfügen, falls. Aber als allgemeine Lösung würde ich trotzdem einen der beiden oben genannten Wege wählen.