Перестал нормально работать контроллер Wiren Board 7.4.3 (s/n AE63EOBY), release wb-2602 (as stable). Настроена автоматическая перезагрузка в 12 ночи, после которой он уже второй раз не может загрузиться. Вчера перезагрузил по питанию после зависания(nginx выдал код 500, по ssh не мог подключится), всё заработало как надо, обновил пакеты через apt, но сегодня ситуация повторилась. Снова удалённо не могу его перезапустить:
root@wirenboard-A4LEEFES:~# ssh ``root@172.28.32.131`` “reboot” root@172.28.32.131``’s password: bash: /etc/bash.bashrc: Input/output error /usr/lib/wb-utils/common.sh: line 67: ./of.sh: Input/output error /usr/lib/wb-utils/ensure-env-cache.sh: line 34: of_has_prop: command not found /usr/lib/wb-utils/ensure-env-cache.sh: line 44: 18143 Segmentation fault rm “$WB_ENV_CACHE” -f /usr/lib/wb-utils/ensure-env-cache.sh: line 1: 18158 Segmentation fault [[ ! -e “$WB_ENV_CACHE” || ! -e “$WB_ENV _HASH” ]] Failed to open initctl fifo: No such device or address Failed to talk to init daemon.
Что может исправить проблему? Как не допустить повторного возникновения?
-6 113bcdf27eb94b8684dabc8f7c19f9e0 Sun 2026-03-01 21:00:28 UTC—Sun 2026-03-08 21:00:06 UTC
-5 609d46b8efa54c86af2be2b50a32bebd Sun 2026-03-08 21:00:26 UTC—Sun 2026-03-15 21:00:06 UTC
-4 35679de9323c474d99211a48f314191b Sun 2026-03-15 21:00:27 UTC—Sun 2026-03-22 21:00:07 UTC
-3 fd270b63551e49e88eb0b2a8a5bab7f0 Sun 2026-03-22 21:00:27 UTC—Sun 2026-03-29 21:00:07 UTC
-2 08ec00c2b4d843a8807243697a64ccc0 Sun 2026-03-29 21:00:27 UTC—Wed 2026-04-01 20:13:55 UTC
Перезагрузка раз в неделю?
Ну, что интересно - то что логов после 23:20 просто нет.
может указывать на недоступность как раз emmc. То есть - невозможность, в том числе, и записать лог.
dmesg не запускали до перезагрузки?
Для точной диагностики неплохо вставить в контроллер SD, если записывать логи на нее - то вероятно можно точно понять. Но и если контроллер доступен по ssh то в логе ядра будет про недоступность разделов.
Да, раз в неделю, в cron задание (0 0 * * 0 /sbin/shutdown -r now). При этом до перезапуска по питанию задание не выполнилось, пришлось ехать и перезапускать руками, SSH не работал вовсе.
dmesg не запускали до перезагрузки?
Не запускал так как не было доступа. По SSH интерактивная оболочка запускалась через раз и сразу обрывалась, получилось только отправить команду перезапуска.
На контроллере работает journald, по умолчанию логи хранит в /var/log/journal
Основной конфиг, соответственно /etc/systemd/journald.conf.wb
Сейчас проверю метод ну и выложу годные команды/изменения.
Заменил контроллер на другой из запаса, с этим буду разбираться на столе. Обновил прошивку со сбросом настроек к заводским и через сутки контроллер опят наглухо завис. В консоли отладки по usb сыпались без остановки сообщения что filesystem is red only, даже залогиниться не смог.
Ну, явно выглядит как проблема аппаратная.
То есть ошибки EMMC
Из журнала: DEVICE_LIFE_TIME_EST_TYP_A = 0x0B : ресурс перезаписи (по оценке контроллера) превышен
Очень жаль, так как этот контроллер пролежал в запасе большую часть времени и был поставлен на замену такому же, с умершей памятью(заводской дефект). Вывод: не покупать оборудование про запас, чтобы гарантия не заканчивалась. Вопрос в том почему мог выработаться ресурс записи меньше чем за год работы? И как следствие: каким образом перевести драйвер wb-mqtt-serial на работу только по стандартному modbus? Настрою опрос датчиков раз в минуту, мне этого в целом хватит. Мне не нужен ещё один контроллер на котором сдохнет память из за постоянной перезаписи.
Ну и последний вопрос: если я перекатаю микросхему памяти как мне потом записать образ на новую флешку?
О, даже так? А как давно поставлен?
Пожалуй, если он работал немного - он может быть интересен для исследования, возможно заменим, если вы согласитесь.
Высоковероятно - количество записей.
Драйвер, вне зависимости от типа обмена с устройствами не пишет ничего на флеш, если, конечно, не включен (не включен) debug.
Да, отключение быстрого возможно путем редактирования шаблонов - но это не влияет никак на работы с файловой системой.
Такого механизма нет, разве что на программаторе; Но не уверен что после подобного будет работать…
О, даже так? А как давно поставлен?
Пожалуй, если он работал немного - он может быть интересен для исследования, возможно заменим, если вы согласитесь.
Не сказал бы что там какая-то сверх нагрузка, к контроллеру подключён один map-3ev, пара mrm2-mini и контроллер высоковольтного стабилизатора, там десяток параметров с медленным опросом.
Дебаг выключен точно.
Я экспериментировал с 6 ревизией (уложил файловую систему попыткой расширить раздел), мне удавалось вывести процессор в режим FEL зажатием кнопки и подключением кабеля от 5-го контроллера (USB A-A), загрузить на него u-boot с минимальным buildroot но дальше поднять скилла не хватило, отправлял вам не перепрошивку. Может быть есть рецепт как собрать uboot сразу с драйверами, чтобы залить образ?
