Dietpi: مشكلة في cron والنسخ الاحتياطي التلقائي (من الإصدار 6.10 إلى 6.11)؟

تضمين التغريدة
شكرا لك على التقرير الخاص بك.

يجب أن يتم اكتشاف G_USER_INPUT=0 تلقائيًا في عمليات تنفيذ cron ، وبالتالي ليس من الضروري التعيين. ولكن إذا كنت تريد أن يكون لها تأثير ، فأنت بحاجة إلى تصديرها ، وهذا بالطبع يستحق المحاولة:
export G_USER_INPUT=0

في عمليات التنفيذ غير التفاعلية ، سيتم إنهاء البرنامج النصي ، إذا تم اكتشاف مساحة خالية غير كافية (قريبة من) على محرك الأقراص الهدف: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
لكنك تقول ، التنفيذ اليدوي يعمل بشكل جيد؟ في حالة عدم وجود مساحة خالية كافية ، سترى رسالة whiptail ، فهذا يمنحك خيار التجاهل أو الخروج.

حول إدخالات السجل ، من المتوقع وجود بعض رموز الألوان المشفرة + checking for elevation root access . محاولة:
cat /mnt/rpi/backup.log
لتنشيط رموز الألوان وبالتالي تنسيق السجل. يرجى أيضًا تقديم هذا الناتج هنا ، حتى نتمكن من التحقق من المرحلة التي حدثت فيها المشكلة.

البرنامج النصي يعمل بشكل جيد عند تشغيله يدويًا.

غريب.

جرب تشغيل مهمة cron والصق نتائج السجل /mnt/rpi/backup.log

ملاحظة: يقوم dietpi-backup بإخراج rsync تلقائيًا إلى ملف السجل /var/log/dietpi-backup.log ، يمكنك استخدام ذلك أيضًا.

لذا ، أحاول تشغيل وظيفة cron بدون G_USER_INPUT = 0 (أزلت هذا من البرنامج النصي) و ...

ملف سجل النسخ الاحتياطي الخاص بي من /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m

dietpi-backup.log فارغ

لم أر أي عملية نشطة بعد الوقت عندما بدأ cron.

لذلك ، أضفت إلى اختبار برنامج نصي آخر ، لرؤية الإخراج في الملف بعد بدء cron:

#!/bin/sh

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

لكن هذا البرنامج النصي لم يبدأ - لا يوجد ملف "cronworks.log" في / mnt / rpi /
إنه أمر غريب نظرًا لوجود ملف إخراج (backup.log) من البرنامج النصي الخاص بي مع نسخة احتياطية (من أول منشور لي) ، ولكن ليس من هذا البسيط

تضمين التغريدة
حسنًا ، يبدو أن هناك أيضًا خطأ في cron على الأقل. لاحظ أن cron يبدأ البرامج النصية عبر run-parts /etc/cron.X/script وهناك بعض القواعد ، على سبيل المثال يجب أن تكون البرامج النصية مملوكة لـ root (AFAIK) وأكثر تأكد من أن البرامج النصية غير مسموح لها بنهايات الملفات. هذا يعني أنه سيتم تخطي /etc/cron.daily/script.sh ، ويجب أن يكون الاسم /etc/cron.daily/script بدلاً من ذلك.

أيضًا لا ينبغي أن تكون هناك حاجة إليها ، ولكن حاول استخدام #!/bin/bash كـ shebang عند استخدام نصوص DietPi. هؤلاء أنفسهم لديهم #!/bin/bash ، لكن لكي تفشل بأمان ، حاول استخدامها أيضًا في نص cron.

يحتوي البرنامج النصي دائمًا على اسم "backup" (بدون .sh) ، أقوم بتغيير "#! / bin / sh" إلى "#! / bin / bash" في البرنامج النصي أيضًا ، وهذا البرنامج النصي يمتلكه الجذر. البرنامج النصي "الاختباري" من آخر مشاركة يعمل الآن أيضًا.

لقد جربت كل شيء ، لكن ما زلت لا أعمل. أقوم بتغيير البرنامج النصي للطباعة إلى ملف السجل بعد الانتهاء من مهمة واحدة ورأيت أن البرنامج النصي يبدأ ، لكن النسخ الاحتياطي لم يبدأ أو ينتهي (dietpi-backup.log فارغ) ، لأنه لا يمكن الانتقال إلى الوظيفة التالية مثل tar و rclone إلخ وأيضًا بعد تشغيل cron رأيت عملية / usr / sbin / cron -f تعمل و -bash - إنها طبيعية؟

لا يزال البرنامج النصي يعمل إذا قمت بتشغيله يدويًا - ولكن عند انتهاء النسخ الاحتياطي ، يجب أن أقوم بالنقر فوق موافق وإلغاء (شاشات whiptail) ، وبعد ذلك - تبدأ المهام التالية.

أعتقد أن المشكلة تكمن في استخدام dietpi-backup للنسخ الاحتياطي التلقائي الذي بدأ بواسطة cron. عملت على إصدار 6.9 ، لكن لم تعمل بعد إعادة كتابة نسخة احتياطية من dietpi.

تضمين التغريدة
لذا مرة أخرى ، فقط للتأكد:

• إذا تم تنفيذ /DietPi/dietpi/dietpi-backup 1 يدويًا بنجاح؟
• إذا قمت بتشغيل G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1 فهو يعمل بدون أي خطأ أيضًا ، ويظهر شيئًا مثل:
  

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

• تشغيل صف الأوامر بالضبط من البرنامج النصي

/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

يعمل أيضًا ، مع إظهار كل ما تم تنفيذه وإنهائه في /mnt/rpi/backup.log ؟

• run-parts --test /etc/cron.daily نصك (إذا كان يوميًا ، فاضبطه بخلاف ذلك)
• /usr/sbin/cron -f المتوقع أن يكون -bash نعم ، لأنه يبدأ بيئة bash بسبب #!/bin/bash .

إذا كان كل ما سبق صحيحًا ، فهل يمكنك محاولة بدء تشغيل أجزاء يدويًا ومعرفة ما إذا كان سيتم تنفيذها كما هو متوقع:

• نقل / نسخ البرنامج النصي إلى مجلد منفصل ، على سبيل المثال ~/testdir/backup
• ثم run-parts ~/testdir

لقد اختبرت كما تظهر وعلى كل سؤالك: نعم ، كل شيء يعمل عندما أبدأه يدويًا.
لقد اختبرته باستخدام أمر أجزاء التشغيل ، لكنه لا يزال يعمل - عندما أقوم بذلك يدويًا.

تم إدراج البرنامج النصي الخاص بي بعد استخدام run-parts --test /etc/cron.daily

إذا قمت بإضافة G_USER_INPUTS = 0 وبدأت البرنامج النصي يدويًا ، فهل يجب أن أرى الشاشات (whiptail) مع معلومات حول السجل وما إلى ذلك؟ لأنني أراه دائمًا.

تضمين التغريدة
G_USER_INPUTS=0 فقط يعطل قوائم whiptail لإظهارها. تظهر المعلومات فقط كرسائل طرفية ويتم الرد على الأسئلة كـ "لا" (إلغاء في حالة عدم كفاية التحقق من المساحة الخالية ، عدم عرض السجل).

لفرضه على البرنامج النصي ، تحتاج إما إلى تصديره قبل تنفيذ البرنامج النصي:

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

أو أسهل ، فقط أعطه مباشرة: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1

لقد أدركت للتو أنك استخدمت G_USER_INPUT=0 أعلى بدون S ، يجب أن تكون G_USER_INPUTS=0 مع S .

ولكن إذا لم يتم تصدير المتغير ، فستحدد البرامج النصية ، ما إذا كان يمكن إجراء مدخلات المستخدم أم لا. داخل cron وعلى سبيل المثال ، عمليات تنفيذ وحدة systemd ، يجب أن تحدد جميع البرامج النصية لـ DietPi تلقائيًا وتعين G_USER_INPUTS=0 .
يمكنك التحقق من أن طريقتنا تعمل ، من خلال إضافة لبدء وظيفة cron الخاصة بك (أو وظيفة اختبار):
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
عند تشغيل البرنامج النصي يدويًا ، يجب أن يُذكر أن مدخلات المستخدم مسموح بها (تظهر قوائم whiptail) ، إذا تم تشغيلها عبر cron ، فلا ينبغي أن تفعل ذلك ، ولا يجب أن تجعل أي قوائم whiptail النص معلقًا.

أولاً أختبر G_USER_INPUTS=0 وإذا بدأت البرنامج النصي يدويًا ، فقم بتسجيل:
This environments allows user inputs
وإلا إذا بدأت بـ cron:
This environment does not allow user inputs

بعد ذلك ، أحاول تغيير البرنامج النصي الخاص بي إلى هذا:

#!/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

و dietpi-backup.log لا يزال فارغًا ، لكن backup.log:

عندما بدأ cron وبدء هذا النص تلقائيًا:

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

عندما بدأت البرنامج النصي يدويًا:

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

إنه أمر مزعج للغاية ... بعد ذلك ، يحتوي النص الخاص بي على:

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

ولا يزال لا يعمل إذا بدأ هذا النص البرمجي بواسطة cron.

لا تزال المشكلة في نظام dietpi-backup الذي بدأ بواسطة cron من v6.10. أعتقد أن هذه مشكلة في التغييرات التي أجريتها في الإصدار 6.10 في البرنامج النصي الغذائي الاحتياطي.

dietpi-backup.log لا يزال فارغًا

تضمين التغريدة
شكرا لجهد الاختبار الخاص بك.
سوف أذهب من خلال تغييرنا. ليس لدي أي دليل حتى الآن. وفقًا لاختباراتك على الأقل ، فإن النص في الواقع ليس معلقًا (whiptail / G_USER_INPUTS ليست هي المشكلة) ، ولكنه فشل.

أجرى بعض الاختبارات الخاصة:

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

بعد التعليق على فحص المستخدم الجذر ، في حدود dietpi-backup ، يؤدي تنفيذه عبر cron إلى:
[FAILED] RootFS is currently Read Only, unable to continue.
لكن:

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

تضمين التغريدة

tput هي المشكلة:
tput: No value for $TERM and no -T specified

• مثير للاهتمام ، كما أطلقنا عليه مع الإصدار 6.9 أيضًا 🤔.

الإصلاح: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090

يعمل هذا التصحيح أيضًا على إصلاح مشكلة أخرى: "run_ntpd 1" الذي يتم تشغيله بواسطة cron يوميًا أو كل ساعة لا يقوم بمزامنة الوقت (لا يتغير الطابع الزمني لـ / var / lib / systemd / clock).

تضمين التغريدة
جيب أنت على حق ، هذا منطقي.
فقط لتجنب التعديل اليدوي للبرنامج النصي لتطبيق الإصلاح ، يجب أن تفعل كل نفس المشكلة: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

أعتقد أن بعض مشكلاتنا المفتوحة مرتبطة بهذا. إذا فشل run_ntpd داخل cron.hour كل ساعة ، فلن يتم استدعاء dietpi-logclear بعد ذلك أيضًا ، مما يؤدي إلى ملء / var / log: https://github.com/Fourdee/DietPi/issues/ 1920

أنا فقط أتساءل ، لماذا ظهرت هذه المشكلة أولاً مع v6.10 + ، حيث استخدمنا tput قبل في وظائف cron الخاصة بنا.
ربما يمكن لشخص ما العثور على التغيير ، الذي تسبب في حدوث المشكلات ، لذلك نحن نعرف كيفية العناية بهذا الأمر بشكل أفضل في المستقبل:

• استدعاء إعلام العملية المتحركة v6.9: https://github.com/Fourdee/DietPi/blob/7b682286e72ef339518d110892a54e7ce405b648/dietpi/func/dietpi-globals#L301 -L315
• التغييرات التي تم إجراؤها باستخدام الإصدار 6.10: https://github.com/Fourdee/DietPi/pull/1867/files
• يتم استدعاء tput cuu و tput cols في كلتا الحالتين ، بالإضافة إلى tput ed في كل إشعار آخر لـ DietPi عند مسح الرسوم المتحركة للمعالجة.
• ربما لم تكن التغييرات على الإشعارات هي التي تسببت في حدوث المشكلة ، ولكن معالجة cron للأخطاء (أو tput) بشكل مختلف بعد تحديث معين.

مزيد من الاختبارات على هذا:

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 على cron على dumb
• يدعي tput أنه لا توجد قيمة للمتغير ، حتى لو كان غير صالح.

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

• نظرًا لأن $ TERM غير صالح لا يؤدي إلى أي خطأ (يؤدي فقط إلى عدم وجود ناتج tput) ، يبدو أن خطأ cron tput مرتبطًا بفقدان -T ، [[ -t 0 ]] النتائج خاطئة. ربما هذا أيضًا تصرف بشكل مختلف من قبل. آخر تحديث لـ ncurses-bin APT في 2018-02-15: http://ftp.de.debian.org/debian/pool/main/n/ncurses/

• كان لدينا مشاكل مع المحطات غير التبادلي / غير صالحة بالفعل، وبالتالي الخروج الآن dietpi- البرامج النصية *، إذا فارغة $ الأجل أو " unknown 'وجدت: https://github.com/Fourdee/DietPi/blob/ الاختبار / dietpi / func / dietpi-globals # L30 -L35

• عرض سعر غير متسق ، نظرًا لأننا قد نرغب في السماح بعمليات تنفيذ غير تفاعلية (أيضًا بدون أي محطة طرفية مرفقة) ، لكننا بحاجة إلى الاهتمام باستدعاء tput على التوالي أوامر أخرى تحتاج إلى محطة طرفية صالحة.

اختبار على v6.9:

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

• يظهر الخطأ ، ولكن يستأنف البرنامج النصي.

لا يحتوي تحديث APT على cron و / أو ncurses (يتم تقليله بواسطة الحزم غير ذات الصلة المختبرة):

• حتى بعد apt-get dist-upgrade وإعادة التشغيل ، لا يتوقف cron عن التنفيذ بعد خطأ tput:

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 إلى الإصدار 6.11 الرئيسي: غريب جدًا ، لا توجد مشكلة حتى الآن ...

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

• إضافة تنفيذ dietpi-backup:

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

• فشل البرنامج النصي ولكن تستمر وظيفة cron. اختبار باستخدام 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

- حسنًا ، يتعلق الأمر بتغييرات globals ، ولكن نظرًا لأن tput حدث وفشل ، فلماذا تخرج البرامج النصية الخاصة بنا الآن ولم تخرج في الإصدار 6.9؟

تم تحديد التغيير ذي الصلة: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) )) إلى الخروج من البرنامج النصي بالكامل ، بينما (السابق)

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

أظهر الخطأ ، لكن سمح للبرنامج النصي بالاستمرار (انظر أعلاه).

إصلاح https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 يعمل وهو أيضًا الحل الأنظف ، حيث سيتم تخطي tput بالكامل داخل الأصداف غير التفاعلية. ولكن أن يكون الفشل آمنة، ونحن يجب أن تعود إلى الطريقة السابقة لمتغير تعلن أولا ثم بعد ذلك قيمة تعيين ضمن بيئة الحسابية: ارتكاب فعل https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

تضمين التغريدة
لتنظيف عطاء فتحت مشكلة جديدة ، يرجى محاولة تطبيق الإصلاح المذكور هناك والإبلاغ عنه مرة أخرى ، إذا كان يحل جميع المشكلات: https://github.com/Fourdee/DietPi/issues/1923

سأغلق هذه المسألة لصالح القضية الجديدة.

يمكنني بنجاح ssh في الإصدار 6.13 الخاص بي ولكنه سيتوقف بعد ذلك مباشرة.

كان الأمر "tput cols" يخرج tput: غير معروف Terminal "rxvt-256color" ، مما أدى إلى وجود قيمة فارغة في السطر 328 لتسجيل الدخول إلى dietpi ، مما يجعلها معلقة إلى الأبد بعد قراءة قاعدة البيانات بنجاح عند التمهيد الأولي.

يبدو أن تصدير TERM = xterm ، وهو اختراق قبيح ، قد أصلح برنامج تسجيل الدخول ، ويمكنه الآن بدء التثبيت.

إذا كان هذا هو القسم الخطأ ، فيرجى التحلي بالصبر ، لأنني لا أعرف حقًا كيفية استخدام مشكلات github ؛ لقد وجدت هذا الموضوع بعد ساعات من البحث عن خطأ في googling عديم الفائدة ، إذا قمت بنقله فربما يترك الباقي حول أخطاء rxvt-256color ، في حالة وجود شخص ما لديه نفس المشكلة.

تحياتي الحارة!

تضمين التغريدة

مرحبا،

شكرا على التقرير والحل 👍

أي عميل SSH تقوم بتشغيله؟

تضمين التغريدة
كنت أفتح قضية منفصلة لهذا الغرض. حددت المشكلة: https://github.com/Fourdee/DietPi/issues/2034

تضمين التغريدة
بعد تسجيل الدخول إلى SSH ، يرجى المحاولة: export TERM='xterm-256color' €: آه ، هذا ما اكتشفته بالفعل 😄.
إذا نجح ذلك ، يمكنك إضافة نص برمجي إلى /etc/profile.d/ يحتوي على شيء مثل:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• بالكلمات: إذا كان هذا اتصال SSH ، وقام عميل SSH بتمرير محطة ألوان 256 بت ، فاضبطه على xterm-256color ، وهو مدعوم من DietPi.

سيكون البديل هو تثبيت حزمة تحتوي على المزيد من تعريفات المحطة الطرفية: G_AGI ncurses-term

Fourdee OpenSSH_7.7p1 ، OpenSSL 1.1.0h على Arch Linux

MichaIng شكرا سعيد لأنني يمكن أن تساعد بالصدفة!

من فضلك ضع في اعتبارك أنني مسؤول نظام سيئ ، وباتباع هذه المقالة التي كتبها توم رايدر ، اكتشفت أن لدي تكوينًا خاطئًا "لإعلان" طرفي.

في النهاية كان ما أصلح المشكلة بالنسبة لي

• تصدير المصطلح الصحيح بالدولار في /root/.bashrc
• نسخ إدخال معلومات المصطلح الصحيح من تثبيت القوس الخاص بي في مجلد pi /root/.terminfo

لم أتمكن من scp ملف terminfo إلى pi ، لأن scp غير مثبت (ربما تفكر في تثبيته مع خادم dropbear؟) ، لذلك قمت بتحميله إلى خادم أملكه ولم أحصل عليه من pi.

يسعدني أن أتمكن من المساعدة ، وأبتهج وآسف مرة أخرى على الفوضى - صخرة!

تضمين التغريدة
Jep ، تعيين $ TERM ضمن /root/.bashrc بالطبع يعمل أيضًا ، إضافته إلى /etc/profile[.d/] يحل النظام على مستوى جميع المستخدمين ، وهو حل نختاره مع DietPi.

المقالة التي ربطتها لطيفة جدًا ، وتشرح كل شيء والإمكانيات جيدًا 👍. لذلك قمت بتثبيت نوع المحطة المطلوبة يدويًا. يذكر المقال أيضًا الحزمة ncurses-term كخيار لتثبيت مجموعة واسعة من تعريفات المحطة الطرفية. ولكن للحفاظ على SlimPi ، لست حريصًا جدًا على التثبيت المسبق لهذه الحزمة لمثل هذه الحالات النادرة. بدلاً من ذلك ، من الأفضل استخدام حل bashrc / profile ؛ من الممكن أيضًا التحقق من الدعم الطرفي قبل تطبيق الإصلاح على تسجيل الدخول إلى SSH.

للاختبار مع عميل PuTTY: PuTTY> Connection > Data > Terminal-type string

حول تثبيت SCP: هناك العديد من بروتوكولات نقل الملفات الأخرى ، FTP ، SFTP أو محركات أقراص الشبكة NFS ، SMB ، لنقل الملفات. لن أقوم بالتثبيت المسبق ، ولكن أترك الخيار للمستخدم كيفية نقل الملفات من عميل إلى خادم. USB ، محرك أقراص خارجي بالطبع ممكن أيضًا أو ببساطة نسخ ولصق في محطة SSH في حالة. لكن على أي حال كحل عام ، سأذهب بإحدى الطريقتين المذكورتين أعلاه.