S.k
May 15, 2026, 10:18am
1
При попытке скачать резервную копию (c rootfs или полную[конфигурации скачиваются без проблем]) при переходе объема файла за ~200Мб загрузка сбрасывается и начинается заново. Такой цикл происходит несколько раз и потом браузер выдает ошибку загрузки.
При формировании архива вижу повышение температуры ЦП (что логично) и повышение значения “dev_root_used_space” (если скачивать полный архив, то загрузка слетает сразу при заполнении доступной памяти ~ 1920 Мб [независимо оттого сколько успело скачаться на ПК], значение падает до ~ 1200 Мб и снова постепенно растет, пока заново формируется архив; однако, при загрузке rootfs, максимальное значение там в районе 1530 Мб, но загрузка все равно слетает). Где-то читал, что для создания архива должно быть свободное пространство в mnt/data, но там значения занятого места не меняются.
Такая ситуация сразу на двух контроллерах
приложен диагностический архив, доступен только сотрудникам поддержки
(337,2 КБ)
Добрый день.
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.0G 1.2G 675M 64% /
/dev/mmcblk0p6 13G 4.9G 6.5G 43% /mnt/data
Попробую воспроизвести.
Исходно:
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.0G 1.4G 490M 74% /
В процессе
место на корневом не менялось практически:
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.0G 1.4G 487M 74% /
Что видно и по графику.
S.k:
и повышение значения “dev_root_used_space” (если скачивать полный архив, то загрузка слетает сразу при заполнении доступной памяти ~ 1920 Мб [независимо оттого сколько успело скачаться на ПК], значение падает до ~ 1200 Мб и снова постепенно растет, пока заново формируется архив;
Скрипт архивирует не используя пространство разделов - сразу отправляет в сеть.
S.k
May 15, 2026, 12:02pm
5
Прилагаю график dev_root_used_space и архив со второго контроллера, на нем уже установлен 2602. На графике показаны 3 попытки прислать архив (формирование, сброс загрузки, освобождение памяти), при этом я нажал на загрузку только один раз, он сам видел сбой и отправлял заново
приложен диагностический архив, доступен только сотрудникам поддержки
(520,2 КБ)
Смотрю.
for ((i=0; i<=20; i++)); do date; du -h -d 1 /; sleep 10; done
И сразу после запуска - скачивание архива.
S.k
May 15, 2026, 1:49pm
8
С этой командой не получилось - данные вообще не менялись во время загрузки (загрузка точно шла):
do date du -h -d 1.txt (15,4 КБ)
Поэтому я попробовал еще раз, но отслеживал по разделам:
do date df -h.txt (11,6 КБ)
Здесь уже видно, что вся запись идет на root. Может есть способ хотя бы перенести архивирование в mnt/data? Там места побольше
S.k:
С этой командой не получилось - данные вообще не менялись во время загрузки (загрузка точно шла):
do date du -h -d 1.txt (15,4 КБ)
Значит ничего и не меняется в каталогах.
S.k:
Поэтому я попробовал еще раз, но отслеживал по разделам:
do date df -h.txt (11,6 КБ)
Это не дает источника увеличения.
какой-то файл был удалён (rm) пока процесс его держит открытым
du файл не видит — он же удалён из директорииdf пространство всё ещё считает занятым — ядро не освобождает блоки пока открыт хотя бы один файловый дескриптор
Покажите пожалуйста (lsof нет, поставьте)
lsof +L1 | sort -rn | head -20
То есть я предполагаю что дело не в скрипте архивации. Диск не используется совсем.
S.k
May 15, 2026, 2:43pm
10
С параметром +L1 ничего не выводит(lsof -nP +L1 тоже пустой), без него показывает:
root@wirenboard-хххххххх:~# lsof +L1
root@wirenboard-хххххххх:~# lsof | sort -rn | head -20
wpa_suppl 362 root txt REG 179,2 2827400 10592 /usr/sbin/wpa_supplicant
wpa_suppl 362 root rtd DIR 179,2 4096 2 /
wpa_suppl 362 root mem REG 179,2 785432 3669 /usr/lib/aarch64-linux-gnu/libgcrypt.so.20.2.8
wpa_suppl 362 root mem REG 179,2 767856 4009 /usr/lib/aarch64-linux-gnu/libzstd.so.1.4.8
wpa_suppl 362 root mem REG 179,2 742816 6063 /usr/lib/aarch64-linux-gnu/libsystemd.so.0.30.0
wpa_suppl 362 root mem REG 179,2 633000 3775 /usr/lib/aarch64-linux-gnu/libm-2.31.so
wpa_suppl 362 root mem REG 179,2 577176 4747 /usr/lib/aarch64-linux-gnu/libssl.so.1.1
wpa_suppl 362 root mem REG 179,2 489992 3833 /usr/lib/aarch64-linux-gnu/libnl-route-3.so.200.26.0
wpa_suppl 362 root mem REG 179,2 47000 3884 /usr/lib/aarch64-linux-gnu/libpcsclite.so.1.0.0
wpa_suppl 362 root mem REG 179,2 350280 3602 /usr/lib/aarch64-linux-gnu/libdbus-1.so.3.19.17
wpa_suppl 362 root mem REG 179,2 31576 3914 /usr/lib/aarch64-linux-gnu/librt-2.31.so
wpa_suppl 362 root mem REG 179,2 27864 3831 /usr/lib/aarch64-linux-gnu/libnl-genl-3.so.200.26.0
wpa_suppl 362 root mem REG 179,2 2752240 4745 /usr/lib/aarch64-linux-gnu/libcrypto.so.1.1
wpa_suppl 362 root mem REG 179,2 160200 3901 /usr/lib/aarch64-linux-gnu/libpthread-2.31.so
wpa_suppl 362 root mem REG 179,2 154232 3774 /usr/lib/aarch64-linux-gnu/liblzma.so.5.2.5
wpa_suppl 362 root mem REG 179,2 14560 3608 /usr/lib/aarch64-linux-gnu/libdl-2.31.so
wpa_suppl 362 root mem REG 179,2 145328 3524 /usr/lib/aarch64-linux-gnu/ld-2.31.so
wpa_suppl 362 root mem REG 179,2 1450976 3571 /usr/lib/aarch64-linux-gnu/libc-2.31.so
wpa_suppl 362 root mem REG 179,2 141296 3695 /usr/lib/aarch64-linux-gnu/libgpg-error.so.0.29.0
wpa_suppl 362 root mem REG 179,2 139040 3829 /usr/lib/aarch64-linux-gnu/libnl-3.so.200.26.0
Выполните скачивание с компьютера, без браузера, используя wget, для проверки.
Для того чтобы точно понять не менялись ли скрипты покажите вывод cat /usr/lib/cgi-bin/download_*
Ну и если есть облако - то дайте в него доступ.
Пригласите, пожалуйста, пользователя support@wirenboard.com в организацию на облачном сервисе.
Поставьте временный пароль от SSH пришлите личным сообщением (потом замените).
Для этого в настройках организации нажмите кнопку “Пригласить”
И укажите почтовый адрес:
После этого поддержка получит доступ к вашему контроллеру для диагностики.
