Обновление до 3.2, Center старой линейки: справочник
Неисправности, коды скрипта обновления Center, почему шаги такие, образы, ограничения, что проверено и откат. «Шаг N» — шаг на странице «Шаги».
1. Неисправности
| Симптом | Причина | Что делать |
|---|---|---|
Linux-ВМ после перезапуска: на консоли dracut:/# | диск NVMe, в initramfs гостя нет nvme (ВМ без правки шаг 5) | восстановление: vapi.sh vms-stop; [mgmt] su -m postgres -c "psql -d vstack -c 'UPDATE vm.machine SET nvme=false WHERE id=<id>'", записать в журнал; vms-start с node_id владельца — гость грузится на virtio-blk. С согласия владельца добавить драйвер (шаг 5), затем vms-stop, nvme=true, vms-start. Временно, не как итоговое состояние |
Эдж не загрузился: Mounting from ufs:/dev/gpt/root failed with error 19, на консоли приглашение mountroot> | эдж на образе v7, в его ядре нет NVMe | edge-reimage.sh с его номером (шаг 45); скрипт сам остановит эдж |
ВМ работает на двух узлах сразу: два процесса bhyve: <id>, dupcheck.sh показывает дубль | после подъёма пула или возврата узла Center ищет «потерянные» ВМ и может запустить уже работающую | убить более позднюю копию: на обоих узлах ps -o lstart= -p <pid>, на узле поздней — kill -9 <pid>. Сообщить владельцу ВМ: две копии писали в один диск |
Узел загрузился на kernel.GENERIC_PROD_prev, в /var/log/messages — NODE IS RUNNING THE FALLBACK KERNEL | новое ядро при первой загрузке не поднялось | узел в работу не возвращать. С консолью BMC: nextboot -k kernel.GENERIC_PROD; shutdown -r now и смотреть, где встаёт загрузка. Загрузилось — vstack_boot_marker сам снимет запасное ядро. Нет — сброс (вернётся прежнее ядро), снимок экрана — в поддержку |
Узел не загрузился: !!!! X64 Exception до первой строки ядра | не снята строка раннего микрокода (раздел 3) | шаг 26 |
Suspend: Remote snapshot mounting: Error bind socket! | сокет инициатора NVMe-oF на узле ВМ мёртв | если активных сессий нет (команда 1 ниже печатает 0) — service vstack_nvmf_initiator restart, повторить suspend |
Suspend: vm_checkpoint() failed. errno = 2 | snapshot.bvmss меньше памяти ВМ | переносить холодно: остановить и запустить с выбором узла (шаг 19) |
Перенос пула: cannot export 'zNN': pool is busy | таргет на владельце держит диски уже остановленных ВМ | пока пул запущен: команда 2 ниже показывает тома пула, которые держит таргет; для каждой ВМ из списка vstack-vm vm unshare --id=<id>, затем снова остановить пул |
ccrd_cli … --command stop вернул ZMQ socket error, start — service is already running on node <N>; статус STOPPED at node: 1024 | ccrd ответил раньше, чем закончил остановку | ждать STOPPED в ccrd_cli --service --command status, затем start на целевом узле. Пул уже экспортирован — ВМ пула простаивают, не тянуть |
Запуск ВМ: VM does not exist / -5, хотя каталог ВМ в пуле есть | нет ссылки состояния | убедиться, что ВМ нигде не работает; ln -s /pools/<zNN>/.vm_V4/<9 цифр id>/vm.json /pools/<zNN>/.vm_V4_state/<id>.state, запустить |
Массовый запуск после переноса пула: часть ВМ -452 Remote … attach error | гонка при одновременной раздаче | партиями по 3–5; упавшие — по одной, лучше на узле-владельце |
/var/log/vstack_nvmf_initiator.log растёт десятками МБ в секунду (IOCTL error / Unknown gctl_cmd: 0), suspend на узле висят | поток инициатора зациклился после оборванной сессии | сразу : > /var/log/vstack_nvmf_initiator.log (место на /). Перезапуск инициатора при висящих suspend может уронить таргет на владельце пула и все удалённые ВМ пула — сначала перевести удалённые ВМ пула локально. В поддержку |
-460 (vms-start), -15152 (resume) | nvme = false (Windows, не переведённая на NVMe — страница «Windows на NVMe»), запуск не на узле пула | так задумано |
-459 | Windows с nvme = true, первичная настройка не завершена, запуск на чужом узле | запустить на узле пула |
-461 | ВМ уже работает на другом узле | dupcheck.sh, второй раз не запускать |
-440 Cluster RAM has been depleted | учётный бюджет RAM Center (раздел 3) | шаг 8 |
| Windows после старта на узле 3.2 висит на загрузке или без сети | сбой первого старта | один stop+start |
Windows не выключается ни штатно, ни с hard_timeout: 600; на консоли окно «Install Windows: The computer restarted unexpectedly… Windows installation cannot proceed» | ВМ убили посреди первичной установки Windows, установка сломана | ВМ пересоздать. Windows в первичной установке не выключать (шаг 19) |
Нога пула FAULTED после перезагрузки соседа | владелец пула ещё на 3.0 (раздел 3) | zpool online на владельце, шаг 28 |
| После Center 3.2 узлы не в брокере | брокер слушает только кластерный адрес (раздел 3) | шаги 39–43 |
rabbitmqctl от root: unable to perform an operation on node, в rabbit.log Invalid challenge reply | у root другая erlang cookie | env HOME=/var/db/rabbitmq rabbitmqctl … |
| Метрики узла пропали после обновления узла | старый telegraf.conf несовместим с новым telegraf | ожидаемо до роли nodes (шаг 40); path в [[inputs.smart]] — шаг 6 |
Нет метрик ВМ, bhyve_cpu только от части узлов | сборщик включён, но не запущен | шаг 41 |
Метрики ВМ раз в 2–3,5 мин, Feed took … overrun | bhyvectl --get-all на каждую ВМ, до 3 с | известное ограничение |
influxd убит ядром (was killed: failed to reclaim memory) | тяжёлые запросы к influx | service influxd start; для проверок — только last() по одному измерению за минуты |
В cluster.log на всех узлах zfs_metrics ### error post data: HTTP 400 … field "alloc" … integer, already exists as type float | шард influx создан старым сборщиком | проходит само при смене недельного шарда, игнорировать |
| После Soft Transfer портал показывает у ВМ прежний узел | vms-resume-pool не обновляет узел ВМ в Center | на работу не влияет; обновится при следующем запуске или переносе ВМ |
| Новая ВМ из образа раздела 4 не грузится | образ не скрыт во внешней системе или ВМ создана в обход неё | первая строка таблицы; шаг 16 |
ВМ из внешней системы не создаётся, в Center -253 Bad param os_profile value | привязка образа — старый номер профиля | шаг 38 |
Windows после смены nvme: синий экран INACCESSIBLE_BOOT_DEVICE | флаг без win-nvme-switch.py patch | «Windows на NVMe» |
Скрипт на узле печатает свою справку (usage), в /root появился пустой файл с именем вроде 3.2.0 | команда передана однострочником, и csh на узле разобрал > и пробелы в аргументах по-своему | только ssh root@<узел> 'sh -s -- <аргументы>' < скрипт или 'sh -s' <<'EOF'; лишний файл удалить |
Illegal variable name, Ambiguous output redirect | однострочник с $(…) или 2> ушёл в csh | то же |
Эдж после перевода загрузился (на консоли ci-info с адресами), но к Center не подключается; на консоли таймаут pkg к https://mgmtvm.…/packages/… | эдж не достаёт до mgmtVM по сети эджей (0.9.0.0/16): с mgmtVM ping <адрес эджа в 0.9.x> не отвечает | проверить сеть эджей между узлом эджа и узлом mgmtVM (VXLAN этой сети). На тестовом кластере эдж на узле mgmtVM подключился за 40 секунд |
edge-reimage.sh пропустил эдж: target snapshot … not found | в пуле нет образа v8 | шаг 13 |
edge-create или создание шлюза в портале падает, эдж не создаётся | Edges_profile_id указывает на несуществующий профиль | шаг 35 (добавить профиль эджа v8) |
Команды к строкам таблицы — [узел], в sh:
# 1. Активные сессии инициатора NVMe-oF (Suspend: Error bind socket!)
procstat -t $(pgrep -f vstack-nvmf-initiator) | grep -c adm-
# 2. Какие тома пула zNN держит таргет (pool is busy); номер ВМ — 9 цифр в пути .vm_V4/<id>/
fstat -p $(pgrep -f '^/usr/local/bin/(spdk|nvmf)_tgt' | head -1) | grep zvol/zNN
Фоновый шум, не ошибка: [IPMI] ipmitool sdr timed out раз в минуту на каждом узле, node-software: can't match pkg version в логе диспетчера, favicon.ico в логе angie.
2. Коды выхода mgmtvm-update.sh
Причина — в последней строке ERROR лога /var/log/mgmtvm-update.log.
| Код | Значит | Действие |
|---|---|---|
| 2 | предусловие или источник: нет раздачи, нет settings.yml, мало места, идёт другой pkg, смена мажора без --allow-major-upgrade | ничего не изменено: устранить причину, повторить |
| 3 | pkg или ядро | если в сообщении do NOT reboot — не перезагружать, откат снимками; иначе устранить причину и повторить ту же команду |
| 4 | не удалась копия /etc | ничего не изменено: освободить место на /var, повторить |
| 5 | после фазы app не все сервисы поднялись | лог сервиса (/var/log/<сервис>), затем та же команда — фаза app повторяема |
| 6, 7 | оболочка root, /boot | не перезагружать, откат снимками |
| 8 | приложение: дамп или восстановление БД, провижн | /var/log/vstack_center.log; устранить причину и повторить. Восстановление БД, если уже прошло, не повторяется |
| 10 | нужно действие человека: проверить черновики, перезагрузить, загрузилось прежнее ядро | по тексту сообщения |
Скрипт перед сменой ОС копирует /etc, /usr/local/etc, конфиги /boot и список пакетов в /var/backups/mgmtvm-update/world-<время>/; прежнее ядро сохраняется как <каталог>_prev, первая загрузка нового — разовая. Чего не делать: жёстко перезагружать mgmtVM, запускать pkg руками между фазами, перезагружать после do NOT reboot, включать сервисы Center руками между перезагрузкой и повторным запуском. Полный список ключей — sh /root/mgmtvm-update.sh --help.
3. Почему шаги такие
- NVMe. Миграция Center 3.2 (
v1_0_57_000001_vm_nvme.sql) ставитvm.machine.nvme = trueвсем ВМ, кроме Windows: при первом же перезапуске диск отдаётся гостю как NVMe вместо virtio-blk. Гость без драйвераnvmeв initramfs падает вdracut. Отсюда шаги 5 и 37.vms-createставитnvme = trueлюбой новой ВМ, включая Windows. - Эджи v7 собраны без драйвера NVMe и на диске NVMe не загружаются (
mountroot, error 19). Новые эджи Center 3.2 создаёт из профиля 105 (v8), а на кластере со старым Center образа v8 обычно нет — шаги 13, 35, 45. - Ранний микрокод. Строка
cpu_microcode_load="YES"осталась от образов 2.2 и 3.0. Блоб микрокода 3.2 — 17 МБ; вместе с ядром и модулями предзагрузка выходит за ~56 МиБ, и часть прошивок падает сX64 Exceptionдо первой строки ядра. В 3.2 микрокод применяет службаmicrocode_updateиз пакетаcpu-microcode-rc, аupdate.sh --baseэтот пакет не ставит — шаги 7 и 24. - Что
update.shне делает: не ставит пакеты фабрики,cpu-microcodeи новые сборщики метрик; обновляет загрузчик только на диске, с которого узел загрузился; не пишетcontigmem— шаги 23–25. - Фабрика. Адреса пулов в конфиге ccrd и
contigmemвступают в силу только при перезагрузке узла, поэтому готовятся до окна A (шаги 14, 25) и применяются его перезагрузками. Включение в окне B перезагрузок не требует. - Фабрика на
vlan40. Так её настраивает инсталлятор 3.2: адреса NVMf пулов —.(200+NN)в подсети VXLAN наvlan40, где уже есть адреса узлов.(100+N). Отдельный VLAN и работы на коммутаторах не нужны. NVMe/TCP работает и при MTU 1500; при MTU 9000 наlaggи коммутаторе — быстрее. - Узлы и новый Center. RabbitMQ и influx Center 3.2 слушают только кластерный адрес
172.17.127.250, а у узлов прописан внешний адрес mgmtVM. До роли nodes (шаги 39–40) команды Center до узлов не доходят.service vstack_center onestart nodes --checkпроверочным не является — прогон станет боевым. - Профили ОС стали UUID.
vms-createс числовымos_profileотвечает-253— шаги 16 и 38. - Ноги пулов. Пока владелец пула на 3.0, диск перезагруженного соседа остаётся
FAULTEDи возвращается толькоzpool online— шаг 28. - Бюджет RAM Center. Center пускает ВМ на узел только в пределах
node.node.ram(около половины физической памяти), иначе-440. Для планирования: пул не больше примерно четверти бюджета узла — шаг 8. - Порт 7000 (управление SPDK) работает без пароля и слушает все интерфейсы. Привязать его к одному адресу нельзя: узел, где запускается ВМ, обращается к SPDK владельца по адресу пула, а этот адрес переезжает вместе с пулом. Поэтому порт закрывает фильтр pf (шаги 15, 47). Правила в нём — с
no state: правило сkeep stateпропускает только новые соединения и оборвало бы уже открытые сессии между узлами. - Windows остаются на virtio-blk и запускаются только на узле своего пула (
-460): у них в реестре запрет драйвера NVMe, просто сменить флаг нельзя — «Windows на NVMe».vms-stopWindows почти всегда не выключает, а снимает через ~30 секунд: Windows в первичной установке после этого не ставится. - Фабрика в том же окне, что Center. С
feature.nvmf = 1Center сразу начинает ставить ВМ клиентов на чужие узлы; откат требует вернуть их все — проще, пока клиентам не объявлено об окончании работ.
4. Образы, не грузящиеся на NVMe (кроме эджа и Windows)
Отказ подтверждён на тестовом кластере на каждом образе, локально и на чужом узле: аварийный шелл dracut, в initramfs нет nvme.
| Образ | zvol (.vm_images/…) | Номер профиля |
|---|---|---|
| Oracle Linux 8.6 v2 | OracleLinux-8.6-x86_64-v2 | 3009 |
| Oracle Linux 8.6 | OracleLinux-8.6-x86_64-v0 | 1039 |
| Oracle Linux 8.5 | vStack-OracleLinux-8.5-x86_64-v0 | 1035 |
| Oracle Linux 8.3 | vStack-OracleLinux-8.3-x86_64-v0 | 1028 |
| Oracle Linux 9.1 | OracleLinux-9.1-x86_64-v0 | 3021 |
| Oracle Linux 9.0 | OracleLinux-9.0-x86_64-v0 | 3008 |
| CentOS 7.9 v1 | vStack-CentOS-7.9-x86_64-v1 | 1025 |
| CentOS 8.3 v0 | vStack-CentOS-8.3-x86_64-v0 | 1022 |
| AlmaLinux 8.7 v0 | vStack-almalinux-8.7-v0 | 3032 |
| AlmaLinux 10.1 v0 | AlmaLinux-10.1-amd64-v0 | 5006 |
| RED OS 7.3.2 | vStack-RedOS-7.3-x86_64-v2 | 3051 |
| CentOS 7.7 (NoCloud) | vStack-CentOS-7-x86_64-cloud.raw | 4 |
| cloud-CentOS-7 (NoCloud) | vStack-CentOS-packer-x86_64.raw | 4 |
| CentOS 8.2 (NoCloud) | vStack-CentOS-8.2-x86_64-v0.raw | 7 |
| cloud-CentOS-8.1 (NoCloud) | vStack-CentOS-8.1-x86_64-v1.raw | 6 |
Номер — vm.os_profile.id до обновления (в Center 3.2 — deprecated_id). Номера 4, 6, 7 на разных кластерах означают разные образы: сверять по zvol. Считаются ВМ, развёрнутые из образа: гость с пересобранным initramfs может загрузиться. Драйвер в initramfs — шаг 5; проверено на Oracle Linux 8.6 v2: после правки гость грузится на NVMe локально и на чужом узле.
5. Эджи
Эдж на образе vStack-edge-13.0-v7 (профиль 102) на NVMe не загружается: Mounting from ufs:/dev/gpt/root failed with error 19, дисков нет. Новые эджи Center 3.2 создаёт из профиля 105 (vStack-edge-13.0-v8). Существующие переводятся на v8 скриптом edge-reimage.sh (шаг 45): штатного пути обновления эджа без пересоздания в Center нет.
Образ v8: https://repo.vstack.com/images/edge-13.0/edge-13.0-v1.zfs, sha256 fd27164755d8bfa44a1acf5c252d8de32ae5f07dc670921c62896151b93f93a9, внутри — vStack-edge-13.0-v8@.clone.source_1750000000.
6. Известные ограничения
- NoCloud. ВМ с настройкой NoCloud (
guest_customization = 1) на чужом узле не получают диск настроек и остаются без сети. Механизм выведен из поддержки. - Флаг
nvmeменяется только SQL-запросом к базе Center, метода API нет. На нём стоят восстановление Linux-ВМ (раздел 1) и перевод Windows. - Эджи. Миграция Center 3.2 ставит
nvme = trueэджам на старом образе;edge-reimage.sh— обход. - ACL дисков. Диски ВМ раздаются с
allow_any_host. Ограничение по Host NQN есть (NVMfAllowAnyHostвvstack-vm.config), но порядок его включения на работающем кластере не описан — не включать. - Метрики ВМ приходят раз в 2–3,5 минуты; сборщик после роли nodes надо запустить руками (шаг 41).
7. Новые ВМ после Center 3.2
vms-create ставит любой новой ВМ, включая Windows, nvme = true и сразу запускает её на NVMe. Проверены Windows Server 2022 и Ubuntu 26.04 из каталога. Новые ВМ из старых Windows-образов на NVMe не проверялись. Новая ВМ из образа раздела 4 или эджа v7 не загрузится — поэтому такие образы скрываются (шаг 16).
8. Что проверено, а что нет
Переход проверен на тестовом кластере (фабрика — на отдельных портах, а не на vlan40): 4 узла, 528 ВМ на 128 образах, исходное состояние — узлы 3.0 без фабрики и Center vStack-control-pane 0.33.
| Проверено | Не проверялось |
|---|---|
обновление узлов update.sh с подписью, перезагрузка, возврат ног пулов, ранний микрокод и служба microcode_update | Soft Transfer между узлами разных версий (пулы переносились холодно) |
mgmtvm-update.sh: Center старой линейки → Center 3.2.0 и его приёмка | роль nodes при нестандартных хуках пулов и конфигах узлов |
| роль nodes, seed-nodes, перевод узлов на брокер 3.2 | vstackos.config-backup.sh на узле 3.0 (проверялся на узлах 3.2) |
esp-sync.sh, dupcheck.sh, vapi.sh; vstackos.config-backup.sh с выносом архива и --verify | фабрика на vlan40 (схема инсталлятора 3.2): на тестовом кластере фабрика проверялась на отдельных портах lagg20; команды те же, меняются интерфейс и подсеть. На первом кластере — шаг 50 обязателен до объявления об окончании работ |
фабрика: роль, ручной старт spdk_tgt, feature.nvmf, запуск 468 ВМ на чужом узле и возврат | перевод сотен эджей за окно (проверен один) |
драйвер nvme в initramfs гостя: загрузка на NVMe локально и на чужом узле | эджи с клиентскими правилами NAT и межсетевого экрана |
эджи: образ v8 во всех пулах, профиль 105, эдж v7 после обновления Center → edge-reimage.sh → эдж v8 на NVMe подключился к Center; пароль edge_ctrl сохранился | фильтр pf после перезагрузки узла (включается штатным pf_enable) |
| фильтр pf на всех узлах: снаружи 7000 закрыт, запуск ВМ на чужом узле в обе стороны, работающие удалённые ВМ не пострадали | новые ВМ из старых Windows-образов; resume ВМ, приостановленной до обновления Center |
| перевод Windows на NVMe: 59 ВМ Server 2016–2025, каждая — с запуском на чужом узле | Server 2012 R2, десктопные Windows, ВМ с несколькими дисками, BitLocker |
9. Оценка времени
| Этап | Время |
|---|---|
| Узел: разгрузка, обновление, перезагрузка, возврат, проверка | 1–1,5 ч |
Center: mgmtvm-update.sh до phase: done | 30–60 мин, зависит от размера БД (19 ГБ — около 35 мин; маленькая БД — около 8 мин) |
| Роль nodes: проверка и боевой прогон | 10–15 мин |
| Эджи | около минуты на эдж; подключение к Center — около 40 секунд после старта |
| Включение фабрики | около 10 мин |
| Windows на NVMe: пачка из 3 ВМ с проверкой на чужом узле | 5–6 мин; пул из 15 ВМ — около 50 мин |
10. Откат
| Где сломалось | Что делать |
|---|---|
| узел до перезагрузки (шаги 21–25) | не перезагружать, enable не делать, разбор с поддержкой |
| узел после перезагрузки | на прежнем ядре в работу не возвращать; пакетного отката на 3.0 нет — восстановление с поддержкой по копии шага 11 |
| Center до шага 34 | Center не менялся. Ключ Center убрать с узлов: cp -p /root/.ssh/authorized_keys.pre-center32 /root/.ssh/authorized_keys; снимки шага 31 удалить |
| Center в шагах 34–40 | откат снимками, ниже. Если внешние системы уже переведены на UUID (шаг 38) — вернуть им прежние номера |
| после шага 40 | узлы уже настроены на новый Center: вернуть их конфиги можно только с поддержкой, по копии шага 11. По умолчанию — исправлять вперёд |
| эдж (шаг 45) | ниже, «Эдж» |
| фабрика (шаги 46–50) | ниже, «Фабрика» |
Center снимками. Если mgmtVM отвечает — сначала скопировать с неё /var/log/mgmtvm-update.log и /var/log/vstack_center.log. [раб]:
ssh root@<OWN> 'sh -s' <<'EOF'
vstack-vm vm stop --id=0
while pgrep -qf '^bhyve: 0$'; do sleep 5; done; echo stopped
V=$(zfs list -H -o name -t filesystem,volume | grep '/.vm_V4/000000000$')
test -s /root/mgmtvm-volumes.txt || { echo "нет списка томов — СТОП"; exit 1; }
for t in $(cat /root/mgmtvm-volumes.txt); do zfs list -H -t snapshot -o name $t@pre-center32 >/dev/null || { echo "нет снимка $t"; exit 1; }; done
for t in $(cat /root/mgmtvm-volumes.txt); do zfs rollback $t@pre-center32 || { echo "FAIL $t"; exit 1; }; done; echo rollback-OK
vstack-vm vm start --id=0
EOF
Нет rollback-OK — ВМ 0 не запускать, в поддержку. После запуска открывается старый портал; затем убрать ключ Center с узлов (строка «Center до шага 34»).
Эдж (на узле его пула, эдж остановлен): zfs destroy <пул>/.vm_V4/<9 цифр>/disk_000000000, zfs rename <тот же путь>.pre-<время> <пул>/.vm_V4/<9 цифр>/disk_000000000; старый образ грузится только на virtio-blk — [mgmt] cd /tmp; su -m postgres -c "psql -X -d vstack -c 'UPDATE vm.machine SET nvme = false WHERE id = <vm_id>'", затем запуск через Center.
Фабрика.
- Все ВМ — на узлы своих пулов: у кого в
vapi.sh vm-listrstart: 1—vms-stop, затемvms-startс узлом-владельцем. - [mgmt] — адреса пулов и флаг, как было до шага 49:
cd /tmp
{ cat <<'SQL'
\set ON_ERROR_STOP 1
BEGIN;
CREATE TEMP TABLE was(name text PRIMARY KEY, inet inet);
COPY was FROM STDIN;
SQL
cat /root/pool-nvmf-pre.tsv; echo '\.'
cat <<'SQL'
UPDATE storage.pool p SET nvmf_inet = w.inet FROM was w WHERE w.name = p.name;
UPDATE management.cluster_options SET value = '0' WHERE an_option = 'feature.nvmf';
COMMIT;
SQL
} > /root/nvmf-rollback.sql
rc=0; su -m postgres -c "psql -X -v ON_ERROR_STOP=1 -d vstack" < /root/nvmf-rollback.sql || rc=$?
echo rc=$rc
[ $rc = 0 ] && service vstack_center_dispatcher restart
- [mgmt]
cp -p /root/settings.yml.pre-nvmf /usr/local/etc/vstack/settings.yml; роль после этого не запускать. - На узлах:
sysrc -f /etc/rc.conf.local spdk_tgt_enable=NO vstack_nvmf_initiator_enable=NO,service spdk_tgt stop,service vstack_nvmf_initiator stop. Фильтр pf можно оставить; снять —pfctl -d; sysrc pf_enable=NO.