Не удаётся проверить корневой раздел WB5

Контроллеры Wiren Board Wiren Board 5
1

Такая же петрушка. После одной из перезагрузок не смог включится WB5.8.
Через дебаг порт:

[FAILED] Failed to start File System Check on Root Device.
See 'systemctl status systemd-fsck-root.service' for details.
         Starting Remount Root and Kernel File Systems...
 EXT4-fs (mmcblk0p3): warning: mounting fs with errors, running e2fsck is recommended
[EXT4-fs (mmcblk0p3): re-mounted. Opts: errors=remount-ro

# systemctl status systemd-fsck-root.service
● systemd-fsck-root.service - File System Check on Root Device
   Loaded: loaded (/lib/systemd/system/systemd-fsck-root.service; static; vendor
   Active: failed (Result: exit-code) since Thu 2016-11-03 20:36:00 MSK; 4 years
Condition: start condition failed at Thu 2016-11-03 20:36:41 MSK; 4 years 0 mont
           └─ ConditionPathIsReadWrite=!/ was not met
     Docs: man:systemd-fsck-root.service(8)
  Process: 89 ExecStart=/lib/systemd/systemd-fsck (code=exited, status=1/FAILURE
 Main PID: 89 (code=exited, status=1/FAILURE)
Nov 03 20:35:59 wirenboard- systemd-fsck[89]: FIXED.
Nov 03 20:35:59 wirenboard- systemd-fsck[89]: rootfs1: Inodes that were
Nov 03 20:35:59 wirenboard- systemd-fsck[89]: rootfs1: UNEXPECTED INCONS
Nov 03 20:35:59 wirenboard- systemd-fsck[89]:         (i.e., without -a
Nov 03 20:35:59 wirenboard-systemd-fsck[89]: fsck failed with error cod
Nov 03 20:35:59 wirenboard- systemd-fsck[89]: Running request emergency.
Nov 03 20:36:00 wirenboard- systemd[1]: systemd-fsck-root.service: Main
Nov 03 20:36:00 wirenboard- systemd[1]: Failed to start File System Chec
Nov 03 20:36:00 wirenboard- systemd[1]: systemd-fsck-root.service: Unit
Nov 03 20:36:00 wirenboard- systemd[1]: systemd-fsck-root.service: Faile

# fsck -f /dev/mmcblk0p3
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
/dev/mmcblk0p3 is mounted.
e2fsck: Cannot continue, aborting.

# mount -o remount,ro /dev/mmcblk0p3
mount: /var/log is busy

#mount
/dev/mmcblk0p3 on / type ext4 (rw,noatime,errors=remount-ro,stripe=1024,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=61348k,nr_inodes=15337,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (rw,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p3 on /var/log type ext4 (rw,noatime,errors=remount-ro,stripe=1024,data=ordered)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=12284k,mode=700)

Как проверить рутовый раздел на ошибки?
Если залить новую прошивку серез USB (20200217 или 20190613 ), то контроллер 2 перезагрузки выдерживает, потом все тоже самое.
Пробовал все команды, описанные в этом топике. Безрезультатно…

2

Добрый день,

т.к. эта проблема имеет мало общего со старой темой (другой вывод, другой контроллер), вынес в отдельную.

как перезагружаете?

Пожалуйста покажите вывод по инструкции из этой статьи: EMMC flash storage wear level — Wiren Board

и вывод команд

cat /sys/class/block/mmcblk0/device/name
cat /sys/class/block/mmcblk0/device/oemid

а также серийный номер контроллера.

а вот так лучше не делать

3

Вот тема:

Отпишитесь по результатам пожалуйста.

4

Перезагружаю через web интерфейс кнопкой “Reboot” в разделе “Devices”->“System”.
root@wirenboard~# mount -t debugfs none /sys/kernel/debug/
mount: none is already mounted or /sys/kernel/debug busy
root@wirenboard:~# cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
y(sys.stdin.read().strip())[0x5e])*10)'int “~%d%% wear” % (ord(binascii.unhexlify
~10% wear
root@wirenboard:~# cat /sys/class/block/mmcblk0/device/name
SEM04G
root@wirenboard:~# cat /sys/class/block/mmcblk0/device/oemid
0x0100
root@wirenboard:~#
S/N AETFWXLJ gwr.

5

Я смотрел этот пост.
После ввода команды echo u > /proc/sysrq-trigger:
user.info kernel: [ 662.363039] EXT4-fs (mmcblk0p3): re-mounted. Opts: (null)
user.warn kernel: [ 662.375935] Emergency Remount complete
и бесконечно начинают ползти записи вида:
WARNING: power_status/Vin: can’t set virtual cell value: write /var/lib/wirenboard/wbrules-vcells.db: read-only file system
, которые невозможно остановить.

6

А вы это вводите после “штатной” загрузки?
Я про то что надо предварительно оттановить все сервисы, начиная с watchdog.

7

Я это вижу в консоли, в которую попадаю через Control+D. Как предварительно остановить все сервисы?

8 
systemctl stop watchdog
systemctl stop wb-homa-w1
systemctl stop wb-mqtt-serial
systemctl stop wb-rules      
systemctl stop wb-homa-gpio
systemctl stop wb-homa-adc
systemctl stop wb-mqtt-adc
9

root@wirenboard:~# echo u > /proc/sysrq-trigger
[ 4475.563221] sysrq: SysRq : Emergency Remount R/O
[ 4475.567992] Emergency Remount complete
Nov 9 19:14:00 wirenboard user.info kernel: [ 4475.563221] sysrq: SysRq : Emergency Remount R/O
Nov 9 19:14:00 wirenboard user.warn kernel: [ 4475.567992] Emergency Remount complete
root@wirenboard:~# Nov 9 19:14:01 wirenboard cron.info CRON[8216]: (CRON) error (create tmpfile)
mount -o remount,ro /dev/mmcblk0p2
[ 4484.322444] EXT4-fs (mmcblk0p3): re-mounted. Opts: errors=remount-ro
Nov 9 19:14:09 wirenboard user.info kernel: [ 4484.322444] EXT4-fs (mmcblk0p3): re-mounted. Opts: errors=remount-ro

root@wirenboard:~# fsck -f /dev/mmcblk0p3
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? yes
Inode 4461 was part of the orphaned inode list. FIXED.
Inode 19490 was part of the orphaned inode list. FIXED.
Inode 19496 was part of the orphaned inode list. FIXED.
Inode 20261 was part of the orphaned inode list. FIXED.
Inode 21112 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -580 -668 -1834 -4461
Fix?
yes
Free inodes count wrong for group #0 (4, counted=8).
Fix? yes
Free inodes count wrong (38558, counted=38562).
Fix? yes

rootfs1: ***** FILE SYSTEM WAS MODIFIED *****
rootfs1: ***** REBOOT SYSTEM *****
rootfs1: 26974/65536 files (0.3% non-contiguous), 184731/262144 blocks
На этом все?

10

Да, если ошибок больше нет.

11

Спасибо.
Нужно ли заново прошивать контроллер? Если да, то через веб или бинарник? Как в дальнейшем избежать такой ситуации?

12

Нет, прошивать не нужно. Как избежать… У вас что подключено в качества UPS?

13

ИБП на 500ВА. Раньше от кратковременных отключений спасал.

14

Тут дело в том что контроллер - если его выключить по событию ИБП или просто так - включится снова через минуту аппаратным таймером. То есть надо реализовывать такой сценарий в nut:
при критическом уровне заряда ИБП ему, ИБП, отправляется команда “отключение через Х секунд”, насттраивается с помощью параметров
ups.delay .shutdown и (или) load.off.delay - это в зависимости от используемого ИБП.
Ну и контроллеру - halt
То есть контроллер к моменту выключения UPS уже выключился, но watchdog еще не успел его включить снова.

15

Понял, попробую реализовать.