Новый WB7 (7.3.1 c/3 ) sn AHU5ML6
БП HDR-30-24 Приобретен вместе с контроллером.
Взят в первую очередь для подтверждения, что работает в нашей среде так же как и WB6.
В течении дня всё было почти нормально - несколько раз почему то зависали сессии SSH.
Ближе к вечеру пролетела ошибка “Segmentation fault” - это уже насторожило, поскольку стороннего софта на контроллере еще не было. Но и замечено было только один раз.
Потом начались “Bus error” и уже стабильно.
Перегрузился и …“Can’t set block device”
Скачиваю последний образ. С флешек ( нескольких ) ничего не получается - не видит.
Ok. Добываю microSD и закачиваю wb_update_FACTORYRESET.fit на нее.
Ура - дело пошло. Казалось бы.
После второй перезагрузки всё остановилось
"You are in emergency mode. After logging in, type “journalctl -xGive root password for maintenance
(or press Control-D to continue):”
Вхожу смотрю лог.
Там присутствуют ошибки ( лог прилагается )
Среди них
Oct 12 07:37:05 wirenboard systemd-fsck[218]: fsck failed with error code 8.
Oct 12 07:38:57 wirenboard systemd[1]: Failed to mount /mnt/data.
Вопросы
Как восстановить работоспособность WB ?
Что предположительно послужило причиной и как избежать в будущем ?
Почему с заведомо рабочих флешек не захотела восстанавливаться ?
На одном из имеющихся на стенде WB6 восстановление с той же флешки прошло успешно ( с другим образом естественно )
Образ не испорчен - проверено повторным скачиваением, сравнением и MD5. Кроме того с этого же образа , но с карточки восстановление хоть как то но пошло.
Последний вопрос скорее относится к сотрудникам “в полях”.
Сейчас они бегают именно с флешками. Получается, что надо иметь с собой для WB6 microSD ? Reset.log (125.8 КБ)
Гипотеза , почему не загрузилось обновление с флешки.
В описании “Debug network” написано, что при подключении отключается USB1.
Возможно , что USB1 отключается и при подключении “Debug console”
А кроме консоли отладки ничем и не подключиться.
То есть получается, что если WB не загружается, то единственный способ “прошиться” - использовать microSD.
Всегда, когда я делаю фактори ресет на WB6 с флешки, у меня подключена консоль для визуального контроля. Вот перебирать кучу флешек- это да, но если она рабочая, то процесс проходит нормально.
А если пишет вот так ?
switch to partitions #0, OK
mmc1(part 0) is current device
eMMC found on device 1
Press FW button to enter firmware update mode
Entering firmware update mode.
Checking if ubootenv part is present
Loading FIT header to 0x42000000 …
Extracting kernel
Loading FIT header to 0x42000000 …
Extracting DTB
Loading FIT header to 0x43000000 …
zimage: Bad magic!
ERROR: Failed to enter update mode! ERROR: /mnt/data/.wb-restore/factoryreset.fit missing or corrupt
Checking if there is a microSD card with update file
MMC: no card present
Couldn’t find partition mmc 0:1
Can’t set block device
MMC: no card present
Couldn’t find partition mmc 0:1
Can’t set block device
No update detected on microSD card, continuing boot
Can’t set block device
Running default loadzimage …
Can’t set block device
Как я понимаю ( может не правильно) , если флешка и карта не найдена он и пытается восстановить по прошитому образу ?
Возможно проблема с образом, разделом или действительно с картой памяти.
Попробуйте, пожалуйста, еще раз обновить контроллер с помощью USB-флешки, а если не получится с карты памяти. При этом подключитесь к отладочному порту и сохраните все логи (как в первом сообщении), логи пришлите.
[ OK ] Reached target System Time Synchronized.
You are in emergency mode. After logging in, type "journalctl -xGive root password for maintenance
(or press Control-D to continue): [ 12.643233] RTL871X: nolinked power save enter
[ 15.331247] dwmac-sun8i 1c50000.ethernet eth1: PHY [stmmac-0:00] driver [ICPlus IP101A/G] (irq=POLL)
[ 15.342415] dwmac-sun8i 1c50000.ethernet eth1: No Safety Features support found
[ 15.349734] dwmac-sun8i 1c50000.ethernet eth1: No MAC Management Counters available
[ 15.357457] dwmac-sun8i 1c50000.ethernet eth1: PTP not supported by HW
[ 15.364940] dwmac-sun8i 1c50000.ethernet eth1: configuring for phy/mii link mode
Login incorrect
Give root password for maintenance
(or press Control-D to continue):
“Login incorrect” - не отловил момент мог и неправильно ввести стандартный пароль, но может и само выскакивало.
по “Ctrl+D” просто повторяется то же самое
…
You are in emergency mode. After logging in, type "journalctl -xGive root password for maintenance
(or press Control-D to continue):
You are in emergency mode. After logging in, type "journalctl -xGive root password for maintenance
(or press Control-D to continue):
You are in emergency mode. After logging in, type "journalctl -xGive root password for maintenance
(or press Control-D to continue):
You are in emergency mode. After logging in, type "journalctl -xGive root password for maintenance
(or press Control-D to continue):
You are in emergency mode. After logging in, type "journalctl -xGive root password for maintenance
(or press Control-D to continue):
К несчастью, продолжаем.
С высокой долей вероятности проблема не в контроллере, а в нашем софте.
Каким то , пока не понятно каким образом, разрушается /dev/mmcblk0p6, как я понял там пользовательские данные, которые в /mnt/data/
Мне надо понять, как воссоздать /dev/mmcblk0p6 ( где то видел , что он создается автоматом при первой загрузке , но потерял ссылку )
И потом уже искать , что не так с софтом, который нормально работал на WB6 и приводит к краху на WB7. Вопрос. Как восстановить /dev/mmcblk0p6 ? Пользовательские данные ценности не несут.
Сам себе и отвечу.
Может кому то пригодится.
mkfs.ext4 /dev/mmcblk0p6
Это сгенерит по новой файловую систему и WB загрузится нормально.
О причинах, почему .Net приложение рушит ext4 на WB7 и нормально живет на WB6 пока ничего неизвестно.
Да, на момент первого появления “Segmentation fault” стороннего ничего еще не должно было быть.
Правда на текущий момент при текущих симптомах уже 100% уверенности нет.
С другой стороны сейчас валится c “Bus error”
Надеюсь итог.
Итак как разрушается диск ? Всё просто.
В нашем софте в первую очередь отключается V_OUT для MODBUS ( включается потом, когда станет известно, что устройства на MODBUS есть и придет их конфигурация из “центра” )
V_OUT - это в Wirenboard 6 - GPIO 73.
Но в Wirenboard 7 73-й GPIO - это как раз “SoM eMMC D1” то есть как раз диск.
Как именно поданный в него ноль приводит к “разрушению” даже не интересно.
Главное другое, что с т.з. низкоуровнего доступа к “железу” WB7 по сути совсем иной контроллер
Можно было бы и сообразить, что смена платформы должна к этому привести.
