Не удалось выполнить автоматическое обновление системы arm64 NanoPi для openssh-сервера

Мой NanoPi по имени Kirke - машина arm64, похожая на Raspberry Pi. Он работает под управлением Ubuntu 16.04.3 LTS и был установлен с дистрибутива FriendlyARM. Обновления запускаются автоматически с момента установки в октябре 2017 года. Приложение является локальным сервером для домашних приложений, может быть, когда-нибудь тоже будет какая-то автоматизация.

Но теперь такое автоматическое обновление (исправление безопасности) для pkg openssh-server не удалось 5 марта 2019 года, сделав систему недоступной для управления с помощью ssh. Веб-сервисы не затрагиваются. Для просмотра журналов Кирке выключен, и системный диск, то есть микро-флеш-карта, просматривается на ноутбуке "Уолтер", так как на Кирке нет ни консоли, ни дисплея, а sshd больше не слушает.

systemd или dpkg, похоже, настаивают на прямой консольной связи. поэтому я, похоже, рано или поздно теряю свою систему. Начиная с первого поста, я пытался использовать Cron для переустановки, но теперь оказался в той же ситуации. Моя корневая запись cron не работает так же, как и python-скрипт для автоматической установки.

Файлы журнала за 5 марта: [root@walter ~]# cat /media/9a463503-3ec8-4cb9-aa50-aaaeae3a9e97/etc/issue Ubuntu 16.04.3 LTS \n \l

[root@walter ~]# cat /media/9a463503-3ec8-4cb9-aa50-aaaeae3a9e97/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Log started: 2019-03-05  06:41:24
Preconfiguring packages ...
(Reading database ... 101242 files and directories currently installed.)
Preparing to unpack .../openssh-sftp-server_1%3a7.2p2-4ubuntu2.8_armhf.deb ...
Unpacking openssh-sftp-server (1:7.2p2-4ubuntu2.8) over (1:7.2p2-4ubuntu2.7) ...
Preparing to unpack .../openssh-server_1%3a7.2p2-4ubuntu2.8_armhf.deb ...
Unpacking openssh-server (1:7.2p2-4ubuntu2.8) over (1:7.2p2-4ubuntu2.7) ...
Preparing to unpack .../openssh-client_1%3a7.2p2-4ubuntu2.8_armhf.deb ...
Unpacking openssh-client (1:7.2p2-4ubuntu2.8) over (1:7.2p2-4ubuntu2.7) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-4ubuntu21.16) ...
Setting up openssh-client (1:7.2p2-4ubuntu2.8) ...
Setting up openssh-sftp-server (1:7.2p2-4ubuntu2.8) ...
Setting up openssh-server (1:7.2p2-4ubuntu2.8) ...
Failed to validate path /var/run/sshd: Bad file descriptor
Job for ssh.service failed because the control process exited with error code. See "systemctl status ssh.service" and "journalctl -xe" for details.
invoke-rc.d: initscript ssh, action "restart" failed.
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2019-03-05 06:41:46 CET; 74ms ago
  Process: 5028 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)

Mar 05 06:41:46 kirke systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 05 06:41:46 kirke systemd[1]: ssh.service: Unit entered failed state.
Mar 05 06:41:46 kirke systemd[1]: ssh.service: Failed with result 'exit-code'.
dpkg: error processing package openssh-server (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 openssh-server
Log ended: 2019-03-05  06:41:59

Старое обновление уже отозвано или заменено чем-то новым? Как мне перейти на предыдущую версию? Мне нужно будет использовать команду загрузочного приложения или запись cron, которая работает без консоли.

Спасибо за любую помощь.

Сегодня, 9 марта, я могу снова войти в систему, но может возникнуть реальная проблема.

Что я сделал:

• Я нашел обходной путь, предложенный в одном из предыдущих постов. С помощью
  mkdir -p /var/run/sshd на автономном диске, положить его обратно на сервер, загрузить. После следующего запуска автоматических обновлений я мог снова войти в систему, используя ssh.

• К сожалению, это не решение, потому что оно разрушает
  Тщательно выполненная настройка других сервисов, так как / var / run это место, которое
  должен быть на оперативном диске и исчезнет при отключении питания.

• Когда я смотрю на все еще существующий скрипт запуска init.d, я вижу его
  обеспечивает существование /var/run/sshd в каталоге / var / run с определенной настройкой chmod. В отличие от этого новый sshd.service
  конфигурации нет. В моем понимании sshd.service заменяет /etc/init.d/sshd, и поэтому каталог не создается.

• Сейчас я не понимаю логику разделения привилегий с помощью /var/run/sshd, поэтому я не могу сказать, будет ли /var/run/sshd создаваться стартовым скриптом sshd или где-то еще раньше.