Настройка Protect после обновления

Настройка Protect после обновления, UniFi Protect

cchao

Guest

05.02.2020 15:23:00

Кто-нибудь столкнулся с проблемами запуска UniFi Protect? У меня программа обновилась автоматически, и теперь вместо «запустить Protect» пишет «настроить Protect». Потом, когда нажимаю «настроить», открывается пустая страница — Хм… не удаётся открыть эту страницу. 192.168.86.89 отказался подключиться. @UI-Cody — вы уже сталкивались с таким? Я писал об этом в теме бета-тестирования, но никто не ответил.

cchao Guest	#2 22.03.2020 21:34:00 Ты на версии 1.13.2? Сбрасывал настройки cloudkey?

cchao Guest	#3 26.02.2020 23:21:00 Ты хочешь сказать, что они плохие блоки из-за части про «непрерывность»? Я гуглил, и там написано, что это больше связано с тем, насколько сильно диск фрагментирован.

Lycean

Guest

22.03.2020 09:08:00

Нет, всё ещё глючит. Protect у меня уже два раза вылетал. Первый раз всё перестало работать, а после перезагрузки Cloud Key жёсткий диск автоматически отформатировался, и пришлось восстанавливать из резервных копий. Сейчас снова всё сломалось. Я не уверен, в чём проблема — в жёстком диске, железе Cloud Key или какой-то странной ошибке прошивки.

Lycean

Guest

11.03.2020 23:26:00

Хорошо, я заменил жёсткий диск, и уже несколько дней всё работает стабильно. Я просто взял старый 1 ТБ диск, который валялся в ящике, так что ничего особенного. Я попытался полностью отформатировать изначальный подозрительный диск на своём компьютере. В первый раз процесс прервался на полпути, и диск, похоже, просто отключился. Во второй раз форматирование прошло успешно, и плохих секторов не обнаружилось. Думаю, проблема в том, что с диском периодически какие-то глюки.

Lycean Guest	#6 02.03.2020 08:44:00 Хорошо знать, у меня тоже постоянно выключается, так что я, наверное, попробую заменить жесткий диск на другой и посмотрю, исчезнет ли проблема.

cchao

Guest

02.03.2020 07:24:00

Итак, сделал две вещи: обновился до новой бета-версии после кучи сбросов к заводским настройкам. Установил стандартный жёсткий диск.

Unifi Protect теперь в основном работает. Сегодня были небольшие простои, но в целом вроде всё нормально. Ещё запустил диагностику WDC на стороннем диске — и он показал слишком много плохих секторов. Ну что ж... моя ошибка, что не поверил @UI-Cody, когда он говорил, что диск умирает. Спасибо за помощь — всё равно не понимаю, почему версия 1.13 так часто вылетала на моём стандартном HDD, но бета пока ведёт себя нормально.

cchao

Guest

29.02.2020 09:35:00

Придётся попробовать. Я подключил жёсткий диск, который шёл с Cloud Key Gen2+, и даже с самой свежей бета-версией он работал только немного, а потом падал. Другой диск сейчас проходит углублённый тест. Похоже, с версией 1.13.x что-то серьёзно не так.

Lycean

Guest

29.02.2020 08:40:00

Ох, это было мучительно. В итоге я делал fuser -km /dev/sda2; umount -fr /dev/sda2; umount /dev/sda2, чтобы убить все процессы, использующие устройство, отмонтировать его и попытаться смонтировать только для чтения, если не получится, а потом окончательно размонтировать. Я просто повторял этот цикл, пока не получилось, потому что идёт гонка с процессами, которые снова пытаются обратиться к диску. Наверняка есть более правильный способ, но мой грубый метод в итоге сработал. Правда, похоже, это не решило моих проблем — Protect снова упал через какое-то время. Собираюсь ещё раз попробовать и посмотреть, что из этого выйдет.

cchao Guest	#10 28.02.2020 14:52:00 Ага, понял тебя. Как ты размонтировал диск? Я как раз пытался это сделать.

Lycean

Guest

#11

28.02.2020 10:56:00

Нет, я имел в виду строку «55424e5400.var: Updating bad block inode.» Поскольку я не знаком с Linux, предполагаю, что её обновили из-за обнаружения плохого блока... хотя могу и ошибаться. Но раз вы это упомянули, я сделал ext4defrag /dev/sda2, и уровень фрагментации снизился примерно до 9%, так что стоит сделать это хотя бы ради этого.

Lycean

Guest

#12

25.02.2020 23:04:00

@UI-Cody У меня тоже такая же проблема с CKG2+. Он работает какое-то случайное время после перезагрузки CK, а потом просто умирает, как и говорил @cchao. У меня есть логи, если хочешь посмотреть, может там что полезное найдётся.

Добавлю, что есть ошибки с диском:

root@CloudKey:/# fsck -nf
fsck from util-linux 2.29.2
e2fsck 1.44.5 (15-Dec-2018)
Warning! /dev/sda4 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
55424e5400.data: 2235/57647104 files (14.5% non-contiguous), 222512905/230559153 blocks
e2fsck 1.44.5 (15-Dec-2018)
Warning! /dev/sda3 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
55424e5400.db: 1409/2097152 files (8.9% non-contiguous), 1133225/8388608 blocks
e2fsck 1.44.5 (15-Dec-2018)
Warning! /dev/sda2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (3868048, counted=3865751).
Fix? no

Free inodes count wrong (1048370, counted=1048368).
Fix? no

55424e5400.var: 206/1048576 files (24.8% non-contiguous), 326256/4194304 blocks
e2fsck 1.44.5 (15-Dec-2018)
Warning! /dev/mmcblk0p47 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
appdata: 11/1253376 files (0.0% non-contiguous), 122724/5012475 blocks

Сейчас попробую сначала восстановить диск, иначе буду пробовать его форматировать.

Редакт 2: После долгой борьбы с отмонтированием диска мне всё же удалось запустить fsck, и, кажется, найден хотя бы один битый блок:

root@CloudKey:/# fsck /dev/sda2 -c
fsck from util-linux 2.29.2
e2fsck 1.44.5 (15-Dec-2018)
Checking for bad blocks (read-only test): done
55424e5400.var: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

55424e5400.var: ***** FILE SYSTEM WAS MODIFIED *****
55424e5400.var: 218/1048576 files (27.5% non-contiguous), 346992/4194304 blocks

Перезагружу CK и посмотрю, что будет дальше.

cchao

Guest

#13

21.02.2020 04:02:00

Да. Изначальный дамп делался на WD Red (SATA в eSATA). Я снова вставил оригинальный 1 ТБ диск, и ситуация повторилась. Могу тоже выложить это, если хотите. Просто заметка: я какое-то время пользовался предыдущей версией. Обновился до бета, и unifi protect перестал работать. Понизил версию до 1.12.x — снова заработало. А потом, когда 1.13 стала стабильной, unifi protect, к сожалению, обновился, и вот мы здесь.

UI-Team Guest	#14 20.02.2020 23:07:00 Привет, @cchao! Напоминаю, есть ли у тебя другой заведомо исправный HDD, который можно попробовать в твоём CKG2+? Контроллер, по-видимому, не фиксирует сбой, из-за чего у меня складывается впечатление, что проблема может быть в жёстком диске. Если проблема повторится с другим диском, можешь, пожалуйста, отправить новый файл поддержки с логами через эту форму? https://forms.monday.com/forms/140d6878f3367ba000fe8ced0ad82fe0

Читают тему (гостей: 1)