Контроллер WB8.5 перестал загружаться

Добрый день, команда WirenBoard!
Приобрел себе WB8.5 (4/64ГБ) с предустановленными WBE2R-R-ZIGBEE-SH v1.4 и WBE2R-R-ZIGBEE v2.4 + блок питания MORNSUN LI100-20B24PR2 для построения умного дома на Sput.hub. Настроил SH оперативно, добавил ZigBee устройства и скрипты для них, все шло как по маслу, но при установке microSD карты (SanDisk Ultra 32GB) начались проблемы. Карту не было видно ни в интерфейсе Sprut.hub, ни в интерфейсе WirenBoard. Начал читать форумы, нашел папку монтирования /mnt/sdcard. Доступа к папке нет, все ее реквизиты отображаются знаками вопроса (см. ниже):

root@wirenboard-A5GP4NZN:/mnt# ls -la
ls: cannot access ‘sdcard’: No such device
total 12
drwxr-sr-x 4 root root 4096 Nov 4 00:27 .
drwxr-sr-x 17 root makesimple 4096 Jun 26 00:45 …
drwxr-xr-x 9 root root 4096 Oct 31 16:17 data
d??? ? ? ? ? ? sdcard

Проверил microSD карту, результат - один раздел, формат FAT32, ответы системы приведены ниже:

root@wirenboard-A5GP4NZN:~# fdisk -l /dev/mmcblk1
Disk /dev/mmcblk1: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb3137c90

Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 2048 62333951 62331904 29.7G b W95 FAT32

root@wirenboard-A5GP4NZN:~# lsblk -f /dev/mmcblk1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
mmcblk1
└─mmcblk1p1

На следующий день после тщетной попытки монтирования microSD карты контроллер перестал отвечать по SSH и был обнаружен в циклической перезагрезке. При подаче питания контроллер издает звуковой сигнал и зажигает зеленый светодиод, 11 секунд спустя диод моргает несколько раз красным цветом с частотой примерно раз в секунду и через 2 минуты контроллер уходит в перезагрузку.

Чат поддержки Sprut.hub счел проблему аппаратной и отправил в WirenBoard.

На сайте поддержки Wirenboard я нашел информацию о порте Dedub USB и утилите MobaXterm. Выполнил рекомендации по извлечению всех модулей расширения и выполнил старт с записью лога, выкладываю его в закрепе. Нажатие и удержание кнопки Watchdog таймера не особо меняет поведение контроллера. От так же останавливает загрузку на строке:

2.677736] —[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]—

…но не перезагружается. Диод подолжает мигать красным цветом, последующей попытки загрузки через 2 минуты не происходит.

Прошу меня направить на путь исцеления контроллера.

П.С. Хотелось бы сохранить и как-то выдернуть из его памяти бекап SH, чтобы сохранить настройки сопряженных ZigBee релешек, и не разбирать подрозетники где они спрятаны повторно.

MobaXterm_WB8.5_20251104_144708.rtf (100,7 КБ)

Мне нужно переписать файл бекапа Sprut.hub с встроенной eMMC на установленную microSD, для этого нужно разбираться в u-boot, т.к. мой WB8.5 загрузиться не может. После этого я откачусь к заводстким настройкам через firmware reset и восстановлю Sprut.hub из бекапа.

Прошу помощи тех специалиста WB, разбирающегося в u-boot загрузщике и для кого команды приведенные ниже не пустой звук.

  • mmc list
  • mmc dev 1
  • ext4load mmc 1:6 0xc2600000 /makesimple/.Backup/SprutHub-Auto-20251103231326.tar.gz
  • md.b 0xc2600000 307ff
  • fatwrite mmc 0:1 0xc2600000 backup.file 0x307ff

Получен дамп памяти файла бекапа (прикреплен), как из него сделать человеческий бекап, который примет Sprut.hub?
backup.file.txt (933,6 КБ)

Полное форматирование (не выстрое) microSD карты дало результаты: команда fatwrite mmc 0:1 0xc2600000 sh_backup 0x307ff была исполнена с результатом в виде файла

Как я могу проверить валидный ли это бекап Спрутхаба?

Добрый день.

Какая файловая система на этой карте? Какая кодировка используется на хост-машине? То есть на той с которой вы работаете с контроллером.

Хотя на первый вопрос ответ есть:

Отсутствует часть системных файлов.
Рекомендую выполнить FactoryReset.

Вот тут не подскажу, SprutHub - это закрытое ПО, у нас, к сожалению, нет никакой документации по нему.

Понимаем ваше негодование: к сожалению не можем помогать совместно со спрутхабом на одной площадке, но у нас есть с ними связь. Можете обратиться с вопросом про бэкап к SprutHub и сообщить нам, если не помогут или отправят к нам обратно.

если вы так глубоко залезли, то я бы слил целиком директорию спрутхаба, или вообще побайтный образ всего eMMC целиком. Медленно, но надёжно, и после этого вы можете уже наконец восстановить контроллер и не мучиться с u-boot-ом.

Евгений, спасибо!
Полученный мною бинарник бекапа через ю-бут не был распознан рабочим спрутхабом (есть еще одна жележка в поле доступа). Есть подозрение, что я что-то сделал неправильно. Пожалуйста, научите правильно бекапить директорию спрута или eMMC целиком.

Дмитрий, добрый вечер! Постараюсь вам помочь. Несколько уточняющих вопросов.
Насколько я помню, бекапы SH сохраняются в отдельных файлах вида /makesimple/.Backup/SprutHub-Auto-YYYYmmddHHMMSS.tar.gz – вы такой бекап копировали и проверяли? А через что переносили, через microSD?
Железка с SH – это железка СпрутХаба, или тоже контроллер Wiren Board? На компютере у вас Windows, судя по MobaXterm, машины с Linux нет?

Добрый вечер, JackDallas!
Вы абсолютно правильно помните адрес и формат бекапов спрута. Именно такой файлик (самый свежий судя по времени и дате) я перенес с eMMC на microSD с помощью команд в u-boot. Этот файл является архивом, а потому его разархивация с сохранением структуры каталогов и файлов внем было первым положительным признаком. Второй положительный момент заключался в том, что этот бекап Спрутхаб смог распознать. Да, у меня имеется еще один умный дом на Спруте, где используется контроллер Sprut.hub 2. Машину с Windows пришлось откопать для использования рекомендованного приложения MobaXterm для снятия логов. Найти машину на Linux тоже не составляет труда. Ubuntu 24 Server подойдет?

Спасибо! Понятно: получается, сам архив бекапа вы смогли перенести на спрутхаб, он без ошибок разархивируется, и распознается Спрутхабом, который на Sprut.hub 2. А вот эт, “Полученный мною бинарник бекапа через ю-бут не был распознан рабочим спрутхабом” – это про что-то другое? Кажется, что если сам файл архива не битый, то и Спрут Хаб на контроллере должен его потом подхватить нормально.

К сожалению, директорию целиком переносить можно только пофайлово, архив из ю-бута не создать: надо будет поддиректории на карточке создавать через fatmkdir и каждый файл переносить через ext4load и fatwrite (как вы, наверное, и делали с gz-шником). Поэтому, наверное, проще скопировать в образ весь раздел целиком, и на машине с Ubuntu 24 его замонтировать и вытаскивать уже файлы. Но тут другая сложность: поскольку копирование проходит через оперативную память (4 Gb) а раздел большой (~55 GiB), то копировать придется кусками, переносить и склеивать их в один образ, а потом монтировать.

Но для начала я бы посмотрел, имеются ли другие SprutHub-Auto-…tar.gz-архивы, и попробовал бы их проверить, прежде чем приниматься за ручное копирование большого числа файлов.
Если не получится с архивами, попробую завтра подробно описать, как перенести образ раздела.

JackDallas, благодарю Вас за терпение и желание помочь.
“Полученный мною бинарник” был неудачной попыткой сделать бекап файл из дампа памяти. Вторая попытка привела к архиву, который работает. Его видит другой спрутхаб, он разархивируется без ошибок. Описанная вами схема копирования каталогов под u-boot меня впечатлила настолько, что я решил во что бы то ни стало восстановить систему сегодня, лишь бы не прибегать к такому копированию каталогов )) В итоге у меня получилось и сейчас загружается и WB, и Sprut.hub тоже. К бекапу не пришлось обращаться, т.к. пользовался восстановлением firmware через файл wb_update.fit на microSD. Спрут будучи установленным в прежнюю директорию нашёл все свои файлы конфигурации. Zigbee устройства не пришлось сопрягать. По вашей рекомендации я сделал резервное копирование всей директории /mnt на локальный NAS. Пусть будет!

Поэтому писать инструкцию по переносу образа раздела не требуется. Разве что для будущих запросов на эту нему.

Еще раз огромное спасибо!

Не заметил сразу после восстановления работоспособности контроллера WB8.5 методом возвращения к заводским настройкам, что SD-карта не определяется сразу после перезагрузки. Приходится установить SSH-тунель с контроллером и заходить в папку монтирования карты, чтобы ее увидела система. Без этих действий Sprut.hub не видит карту и не запускает мост “История”. Однако, следует постучаться по SSH на контроллер WB8.5, как ситуация исправляется и до ближайшей перезагрузки все работает штатно.

Вопрос: как можно вернуть автоматическое определение карты после перезагрузки и ее монирование в папку /mnt/sdcard?

Добрый день.
Проверяю.
Для проверки - настроил сервис GitHub - wirenboard/wb-mqtt-db: Wiren Board database logger на сохранение БД в подкаталог смонтированной карты.
В логах сервиса ошибок не вижу, при старте контроллера после первого обращения - SD монтируется и работает как и предполагалось.
Какие параметры раздела на карту у вас? Есть ли ошибки при монтировании?

Доброе утро, BrainRoot!
Ниже реакция моего контроллера WB8.5 на команды fdisk -l /dev/mmcblk1 и lsblk -f /dev/mmcblk1

Полагаю, в ней содержатся ответы на ваши вопросы по параметрам разделов карты и ошибок ее монтирования. Если чего-то не хватает, то пожалуйста научите как это сделать.

root@wirenboard-A5GP4NZN:/mnt/sdcard# fdisk -l /dev/mmcblk1
Disk /dev/mmcblk1: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3124537b

Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 131072 124735487 124604416 59.4G 7 HPFS/NTFS/exFAT

root@wirenboard-A5GP4NZN:/mnt/sdcard# lsblk -f /dev/mmcblk1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
*mmcblk1 *
└─mmcblk1p1 exfat 1.0 SprutHub2 7654-7D77 58.7G 1% /mnt/sdcard
root@wirenboard-A5GP4NZN:/mnt/sdcard#

P.S. Эту SD-карту я достал из работающего Sprut.hub2, где с ней никаких проблем не наблюдалось.

У меня обычный ext2. Проверю с fat.
Напишите пожалуйста - как воспроизвести. У меня не получается. При первом обращении - карта просто монтируется.

Карта да, монтируется сразу, как только к ней обращаешься. Но если перезагрузить ВБ и не обратиться к карте, открыв /mnt, например, то сама она не смонтируется, и в СХ не пишется история и висит ошибка, что нет доступа к карте.

И вот эта ошибка (на скрине) будет висеть, пока вручную не обратишься к карте, — тогда да, она смонтируется и сразу все заработает. Но разве этот процесс не должен происходить «автоматически»?

Вот я ее «смонтировал», зайдя на нее через интерфейс WB cloud, и СХ ее увидел. Вопрос в том, что это, кажется, должно происходить «само-собой», без дополнительных действий со стороны пользователя.


Полностью поддерживаю господина fischev! SD карта должна монтироваться сама и быть доступна к использованию сразу после перезагрузки контроллера.

Я сталкиваюсь с частыми отключениями электричества. После восстановления электроснабжения контроллер WB8.5 сам стартует (что очень ожидаемо), а вот установленная в нем SD карта продолжает ждать обращения к ней (что совсем не совпадает с моими ожиданиями). В описанном выше случае у меня нет доступа к данным на карте из Sprut.hub, где хранятся его архивы и история данных с датчиков. По итогу исчезают все графики из интерфейса, мост “История” висит о ошибке, обращение к SD карте из Sprut.hub не исправляет ситуацию. Приходится заходить на WB по ssh туннелю и стучаться в папаку монтирования флешки - и тогда все снова начинает работать. В промежуток времени между отключением питания и ручным обращением к флешке данные от датчиков ни сохраниются. Питания не было пять минут, флешку перемонтировал через два дня. Потеряно два дня данных. Графики рваные, каждый раз приходится исправляю ситуацию вручную.

Очень неудобно! Разве это так задумывалось?

Расскажите, как вернуть правильную работу флешки в контроллере WB8.5?

ПО SprutHub закрыто. Узнать каким образом оно работает с носителями - нельзя. Однако: любой из доступных мне способов проверки (чтение файла с SD карты, запись на нее же) - вызывает монтирование в случае если карта не смонтирована до этого.

Происходит. При любом обращении к содержимому.

Доступна. После первого же обращения.

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

А как работает это “обращение”? ПО закрыто и исследовать его нет возможности. Документации - тоже нет.

Вы можете поменять параметры монтирования так как будет более правильно. Или монтировать карту после старта системы - у нас открытое ПО и возможности настройки ничем не ограничены. Для примера - просто в используемом ПО написать скрипт, который будет обращаться к файлу на карте - этого достаточно.

Как писал выше - я не смог воспроизвести “неправильную” работу.
Пробовал размещать, например, на карте как контейнеры так и настройки Home Assistant - работает.