diff --git a/family/how-to/home-automation.md b/family/how-to/home-automation.md index a767b610..7fb10b82 100644 --- a/family/how-to/home-automation.md +++ b/family/how-to/home-automation.md @@ -332,37 +332,50 @@ Z2M **остановлен** с 2026-09-15 (стик отдан ZHA), данны > ⚠️ На t610 **BusyBox**, не GNU coreutils: нет `ping`/`arp`/`netstat`/`ifconfig` в PATH Mac-стороны (на Mac звать `/sbin/ping`, `/usr/sbin/arp`); **на t610** нет `dmesg -T`, `top -b -n1` есть, `fuser -v` НЕТ (`fuser -m` только), `ps -eo` работает, `cat /proc/interrupts` может быть пуст (не поломка). `lsusb -t` — есть. **`docker` на хосте НЕТ** — контейнеры поднимает `hassio-supervisor`, всё через `ha` CLI / Supervisor API. -### 3.9. 💾 Память: 4 ГБ в BIOS → 3.31 ГБ usable (проверено 2026-09-15) +### 3.9. 💾 Память: 4 ГБ в BIOS → 3.31 ГБ usable (замер 2026-09-15) — ⚠️ РАСХОДИТСЯ С ЖИВЫМ > 🔴🔴 **ОБНОВЛЕНО 2026-09-17 — ЦИФРЫ НЕ СХОДЯТСЯ. Живой хост отдаёт `MemTotal: 1 475 788 kB` = 1.44 ГБ.** > Это **НЕ** 3.31 ГБ из таблицы ниже и **не** объясняется округлением. -> Не подтверждено: деградация/отсутствие планки, конфигурация UMA, либо таблица ниже снята с другого состояния. -> Проверка не запущена: `dmesg | grep -iE "e820|BIOS-provided"`, `dmidecode -t memory`. -> ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` при каждом разборе инцидента**, не доверять записанному. -> Детали и развилка — [[family/tech/t610-hang-investigation]] §3.1. +> **`e820` 2026-09-17 обрывается на `0x5e7fffff` ≈ 1.48 ГБ — выше памяти физически нет.** +> ⛔ Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» **снята фактом** — вырезать нечего. +> Разбор, версии и способ проверки (BIOS F10, планки по одной, контакты, memtest86+ с USB): +> **[[family/tech/t610-hang-investigation]] §3.1, §3.1.1, §3.1.2, §5.1.** +> ⚠️ **ПЕРЕМЕРЯТЬ `head -3 /proc/meminfo` + `dmesg | grep e820` при КАЖДОМ разборе инцидента**, +> не доверять записанному. `dmidecode` на t610 **НЕТ** — число планок только из BIOS setup. ``` -MemTotal: 3 470 792 kB = 3.31 ГиБ ← столько видит ядро +MemTotal: 3 470 792 kB = 3.31 ГиБ ← столько видит ядро (замер 2026-09-15) MemAvailable: 2 575 164 kB = 2.46 ГиБ ← реально свободно Cached: 2 414 348 kB = 2.30 ГиБ ← файловый кэш (НЕ занятая память!) SwapTotal: 1 145 356 kB = 1.09 ГиБ HA core: ~700 МБ (лимит 3.55 ГБ) ``` -**Куда ушли 800 МБ от 4096:** по карте `BIOS-e820` — `ACPI NVS`, `ACPI data`, `reserved`-диапазоны + iGPU/чипсет. Норма для t610, потери памяти нет. +**Куда ушли 800 МБ от 4096 (для конфигурации 3.31 ГБ):** по карте `BIOS-e820` — `ACPI NVS`, +`ACPI data`, `reserved`-диапазоны + iGPU/чипсет. Норма, потери памяти нет. ``` -0x00000000 – 0x9f028fff usable (~2.55 ГБ) +0x00000000 – 0x9f028fff usable (~2.55 ГБ) ← состояние 2026-09-15 0x100001000 – 0x13efffff usable (~1.0 ГБ) между ними — ACPI NVS / ACPI data / reserved (~30 МБ + MMIO-окна) ``` -> 🔴 **ПИТФОЛЛ: НЕ читать `MemFree` как «сколько памяти всего» или «сколько занято».** `MemFree` падает при заполнении файлового кэша (у нас Cached = 2.3 ГБ) и в I/O-шторме (наблюдали `MemFree 16 МБ`). Верные метрики — **`MemTotal`** (сколько всего) и **`MemAvailable`** (сколько реально доступно). +> 🔴 **ПИТФОЛЛ: НЕ читать `MemFree` как «сколько памяти всего» или «сколько занято».** `MemFree` падает при заполнении файлового кэша (Cached 2.3 ГБ) и в I/O-шторме (наблюдали `MemFree 16 МБ`). Верные метрики — **`MemTotal`** (сколько всего) и **`MemAvailable`** (сколько реально доступно). > 🔴 **Версия «система видит 1.44 ГБ вместо 4» — ОШИБОЧНА.** Такая цифра получалась из неверного чтения (`MemFree` в шторме / лимит контейнера), а не из реального объёма. Проверять: `head -3 /proc/meminfo`. +> 🔴 **НО (2026-09-17): живой `MemTotal` = 1.44 ГБ — это УЖЕ другой разговор, не округление.** +> `MemFree` остаётся верной метрикой «занято», но `MemTotal` надо перемерять — см. врезку выше. > 📌 Полный e820-маппинг: `dmesg | grep -iE "e820|BIOS-provided"`. ### 3.4. 🔴 Носитель sda — HDD, и как НЕ измерить его нагрузку +> 🎯 **2026-09-17: носитель стал ГЛАВНЫМ КАНДИДАТОМ на причину зависаний.** +> Симптом-матч на идентичном стеке (HA OS 18.2 / Core 2026.9.2) с `sqlite3.OperationalError: +> disk I/O error` в Recorder — разбор и порядок проверки: **[[family/tech/t610-hang-investigation]] §5**. +> Проверка: **`smartctl -a /dev/sda`** (ненулевые `Reallocated_Sector_Ct`, +> `Current_Pending_Sector`, `Offline_Uncorrectable`, `UDMA_CRC_Error_Count`) + +> `dmesg | grep -iE "ata|I/O error|failed command|medium error|UNC"`. +> ⚠️ SMART мерить **на чистом фоне** — питфолл 21 ниже. + **Железо:** `WDC WD2500BEVT-0` · 250 ГБ · **5400 rpm** · `/sys/block/sda/queue/rotational = 1` · раздел данных `sda8` (243 ГБ, `hassos-data`, монтируется в `/mnt/data`, `/config`, `/share`, `/backup`, `/addons`). > 🔴 **ПИТФОЛЛ ИЗМЕРЕНИЯ (моя ошибка 2026-09-15):** прогон `find /mnt/data -size +10M` + `du -sh /mnt/data/*` **сам создаёт I/O-шторм** на 5400-rpm HDD. Последовавший замер дал `io_ms_delta = 10007 ms за 10 с` (диск «занят 100%») — и это было **ложное** доказательство деградации носителя. Через минуту после снятия нагрузки: `io_ms_delta = 2609` (26%), `load 1.72`, `pressure 16%`. @@ -785,6 +798,11 @@ Hz:PWM 0:0 1:0 2:0 3:0 4:48 5:55 6:63 7:70 8:78 9:85 10:92 11:97 12:102 13:107 1 | 53 | 🔴🔴 **При разборе ЗАВИСАНИЯ: логи прошлого запуска недоступны** — подтверждено 2026-09-17 на 5 источниках: `ha core logs` (12 строк текущего контейнера), `/config/home-assistant.log.fault` (0 байт), `home-assistant.log` (нет), `journalctl -b -1` (пусто), `ha supervisor logs` (только текущая загрузка) | Диагноз **до** ребута. **Логбук** в `home-assistant_v2.db` **переживает** ребут — реконструировать профиль нагрузки по нему. Подробно: [[family/tech/t610-hang-investigation]] §2 | | 54 | ⚠️ **`http://192.168.2.176:8123` из LAN → `curl` exit 7**, при живом хосте | Единственный путь к API — `https://mallexxx.duckdns.org`. Дубль питфолла 1 | | 55 | ⚠️ **После холодного старта ZHA догружается**: первый снимок дал 75 сущностей, полный — 310; часть висит `unavailable` минуты | Перемерить через 2–3 мин, не делать вывод «устройства отвалились» | +| 56 | 🔴 **`dmidecode` на t610 НЕТ** (и `/sys/firmware/dmi/entries/17-*/raw` пуст) — число планок RAM этим путём не получить | Планки — только **BIOS setup (F10)**. Объём — `head -3 /proc/meminfo` + `dmesg \| grep e820`. См. §3.9 | +| 57 | 🔴 **`dmesg` на t610 ВРЁТ без `\| tail`** (питфолл 5, подтверждён) | Всегда `dmesg \| grep … \| tail` | +| 58 | 🎯 **Симптом-матч с форума ≠ доказанная причина** — тред HA `1025213` (та же версия стека, `sqlite3.OperationalError: disk I/O error`) | Это **сильнейший кандидат**, но закрывать только фактом: `smartctl` + `dmesg`. [[family/tech/t610-hang-investigation]] §5 | +| 59 | 🔴 **Порядок разбора инцидента: ФАКТЫ → версия, НЕ версия → проверка** | Сессия 2026-09-17: три «версии» подряд (template-сенсоры → swap/cache → UMA → бэкап) сняты Alex'ом одной репликой каждая. Сначала e820/BIOS/SMART/метрики — потом формулировать | +| 60 | 🔴 **«Система дропнула память в процессе работы» — физически невозможно** | Объём виден ядру **один раз** при загрузке через BIOS, не пересчитывается. «Дропнула память» = **зависла**. Режим отказа — **нестабильная планка**: иногда не детектится, иногда ребут, иногда зависон под нагрузкой | --- @@ -858,7 +876,8 @@ ssh root@192.168.2.176 'ha apps logs local_modbus-bridge | grep -E "Raw RTU|→ ## 8. Текущее состояние -> 🕐 Обновлено **2026-09-17**. +> 🕐 Обновлено **2026-09-17**. ⚠️ **Хост t610 зависает — расследование открыто:** +> **[[family/tech/t610-hang-investigation]]** (главный кандидат — деградация носителя, проверка не запущена). > 🔴 **2026-09-17 ~09:38: t610 перезапущен ВРУЧНУЮ (сброс питанием) после очередного зависания.** > Причина **не установлена**, логи прошлого запуска недоступны. Аптайм до ребута ≈ 26 ч, БД закрыта не чисто. diff --git a/family/tech/t610-hang-investigation.md b/family/tech/t610-hang-investigation.md index 1dfb747a..6b7c3741 100644 --- a/family/tech/t610-hang-investigation.md +++ b/family/tech/t610-hang-investigation.md @@ -7,9 +7,12 @@ updated: 2026-09-17 # 🔴 t610 — зависания: состояние расследования -> **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА.** Сессия 2026-09-17. Ниже — что проверено фактом, -> что опровергнуто, и какой единственный вопрос остался невыясненным. +> **Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА. Главный кандидат — деградация носителя (§5).** +> Сессия 2026-09-17. Ниже — что проверено фактом, что опровергнуто, и что осталось. > Родительская дока: [[family/how-to/home-automation]] · §3.1 (RCU stall, закрыто), §3.5 (ограничения аддона), §3.9 (память). +> +> ⚡ **Читать в этом порядке:** §1 факты момента смерти → §2 логи недоступны → §4 что опровергнуто +> (**не повторять**) → §5 главный кандидат + как проверить → §7 предложение (ждёт апрува). --- @@ -70,17 +73,62 @@ SwapTotal: 1024 МБ, used 0 > `MemTotal: 3 470 792 kB = 3.31 ГиБ` (проверено 2026-09-15). > > **Расхождение: 3.31 ГБ → 1.44 ГБ. Это НЕ объясняется округлением.** + +#### 3.1.1. ✅ РАЗРЕШЕНО фактом: e820 обрывается на 1.48 ГБ — памяти физически нет выше + +Снято 2026-09-17 с живого хоста: + +``` +BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +BIOS-e820: [mem 0x0000000000100000-0x000000005e028fff] usable ← верх e820 +... ACPI NVS / ACPI data / reserved (много мелких окон) ... +BIOS-e820: [mem 0x000000005e7f4000-0x000000005e7fffff] usable ← ПОСЛЕДНИЙ usable +``` + +> **Верхняя граница памяти = `0x5e7fffff` ≈ 1.48 ГБ. Выше — ничего.** > -> Гипотезы, которые осталось проверить (ни одна не подтверждена): -> 1. **Планка памяти деградировала/вынута/не детектится** со времени проверки 2026-09-15 -> 2. Сменилась конфигурация UMA-фреймбуфера в BIOS -> 3. В §3.9 зафиксирована цифра **другого** аппарата/состояния +> **Что это доказывает:** если бы стояла планка 2 ГБ и её часть забирал iGPU/UMA, +> e820 уходил бы за `0x80000000` (2 ГБ). Он обрывается ровно на 1.48 ГБ → +> **сейчас видна одна планка ~1.44 ГБ**, и никакой «вырезанной области» нет. > -> **Проверка (только чтение, не запущена):** -> ```bash -> ssh root@192.168.2.176 'dmesg | grep -iE "e820|BIOS-provided|Memory:"' -> ssh root@192.168.2.176 'dmidecode -t memory 2>/dev/null | grep -E "Size|Locator"' -> ``` +> ⛔ **Версия «iGPU/UMA вырезал ~607 МБ из 2 ГБ» — ОКОНЧАТЕЛЬНО СНЯТА** (см. §4). +> Резерв ACPI NVS/data + reserved ≈ 30–40 МБ — это **норма**, не потеря. +> +> 🔑 **Следствие:** в BIOS на старте отдаётся 1.44 ГБ. Если после очередного +> холодного сброса `MemTotal` изменится — это прямое доказательство нестабильности планки/слота. + +```bash +# Воспроизведение (только чтение) +ssh root@192.168.2.176 'head -3 /proc/meminfo' +ssh root@192.168.2.176 'dmesg | grep -iE "BIOS-provided|e820.*usable"' +``` + +> ⚠️ **`dmidecode` на t610 НЕТ** (и `/sys/firmware/dmi/entries/17-*/raw` пуст) — +> число планок этим путём не получить. Смотреть в **BIOS setup** (см. §5.1). + +### 3.1.2. 🧩 ЖЕЛЕЗО: HP t610 — 2 слота SO-DIMM, max 4 ГБ (сервис-мануал HP) + +Из официального Troubleshooting Guide HP t610 (PDF `c03394393`, изд. 2, июнь 2012): + +| Параметр | Значение | +|---|---| +| Слотов | **2 × SO-DIMM**, максимум **4 ГБ** | +| Тип | 204-pin, **DDR3-1600 PC3-12800**, **1.5 В**, non-ECC, CAS 9 | +| ⚠️ Не поддерживается | **x4 SDRAM** (только x8/x16) | +| Порядок заполнения | **SODIMM1, затем SODIMM2** | +| ⚠️ Thermal pad | **Обязателен** на SO-DIMM в **HP t610** (в PLUS-модели — нет) | +| Доступ | **Правая боковая панель** | +| Загрузка с USB | **F10** при старте → boot menu | + +> 🔴 HP прямо предупреждает: при апгрейде ставить модули **с золочёными контактами** — +> иначе коррозия/окисление на стыке разных металлов. **Плохой контакт в слоте — +> штатный режим отказа этого железа**, а не экзотика. +> +> ⚠️ **Питание на модули подаётся ВСЕГДА, пока воткнут шнур.** Перед работами — +> отключить кабель и подождать ~30 с (требование HP). +> +> 📌 **Два слота = ступенчатое падение объёма.** Если один слот/планка отваливается, +> `MemTotal` падает ступенькой (2 ГБ → 1 ГБ), и e820 обрезается — ровно то, что видно. > ⚠️ **НЕ читать `MemFree` как «сколько всего памяти»** (питфоллы 44–45 в родительской доке). > Alex видел «1 ГБ» на экране — вероятнее всего это `MemFree` в состоянии с большим файловым кэшем, @@ -144,54 +192,140 @@ kids_summary / dining_summary / dining_air_summary / bedroom_summary | Версия | Почему неверна | |---|---| | «Template-сенсоры без `trigger` вешают HA» | Alex: это штатная работа HA. Пересчёт — норма, не причина | -| «iGPU/UMA вырезал ~607 МБ из 2 ГБ» | Строилось на `MemTotal 1.44 ГБ` как «2 ГБ минус фреймбуфер». При **физически 1 ГБ** вырезать нечего | +| «iGPU/UMA вырезал ~607 МБ из 2 ГБ» | ⛔ **Снято фактом:** e820 обрывается на `0x5e7fffff` (§3.1.1). Выше 1.48 ГБ памяти нет — вырезать нечего | | «`MemFree` 1 ГБ = кончилась память» | Питфоллы 44–45: `MemFree` падает из-за файлового кэша. Верные метрики — `MemTotal` + `MemAvailable` | | «Логи есть, надо просто посмотреть внимательнее» | Их **нет** физически (§2). Проверено 5 источников | +| 🔴 «Бэкап-джоб (tar `home-assistant_v2.db`) вешает хост» | Alex: «такая операция по факту ничего не может убить». `tar czf` 77 МБ = секунды чтения + секунды gzip. Докин RCU stall (§3.6 родительской доки) был **непрерывным ffmpeg-ретранскодом**, а не разовой архивацией. **Разница принципиальная** | +| ⚠️ Уточнение по бэкапу | `tar` собирается **НА t610** (`tar czf -` по ssh, stdout → `> OUT` уже на TrueNAS). Значит нагрузка — чтение + gzip **на слабом хосте**. Это уточнение, **не** причина | + +> 📌 **Урок метода (для будущих сессий):** я трижды подряд выдал «версию», построенную +> на одной цифре без проверки смежных фактов (template-сенсоры → swap/cache → UMA → +> бэкап-джоб). Каждый раз Alex снимал её одной репликой. **Порядок обратный: сначала +> снять все факты (e820, BIOS, SMART, ретенция метрик), потом формулировать.** --- -## 5. ❓ ЕДИНСТВЕННЫЙ НЕЗАКРЫТЫЙ ВОПРОС +## 5. 🎯 ГЛАВНЫЙ КАНДИДАТ: деградация носителя → SQLite disk I/O error -Развилка, которая разводит два совершенно разных направления: +**Найден симптом-матч** (форум HA, тред `1025213`, 15 сентября 2026) — **та же версия стека:** +HA OS `18.2` · Core `2026.9.2` · Supervisor `2026.09`. + +**Симптомы у пострадавшего (RPi 5):** +- Фронтенд **недоступен часами** (и локально, и из интернета), при этом **IP пингуется** +- **Несколько перезагрузок не помогали** +- После ребута всё поднималось, через несколько часов — **снова умирало** +- Устройства становились `unavailable` + +**Ключевые строки лога:** +``` +ERROR (Recorder) [recorder.core] Error in database connectivity during commit: + Error executing query: (sqlite3.OperationalError) disk I/O error +SQLAlchemyError error processing task CommitTask() +sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state +``` + +> 🔴 **`sqlite3.OperationalError: disk I/O error` = проблема НОСИТЕЛЯ**, а не софта. + +**Как это бьётся с фактами t610:** + +| Факт t610 | Объяснение через носитель | +|---|---| +| Обрыв записи БД на `07:29`, shm/wal `07:31` | SQLite упёрся в I/O и перестал писать | +| `could not validate that the sqlite3 database was shutdown cleanly` | БД не закрыта — процесс умер в середине транзакции | +| `Ended unfinished session (id=36)` | Сессия оборвалась на середине | +| Хост не отвечает, сброс только питанием | Классика деградации носителя, **не** OOM и **не** RCU | +| Ошибок в логе нет | Журнал HAOS в RAM — для disk I/O error нужно, чтобы он дожил | + +> ⚠️ **Симптом-матч ≠ доказанная причина.** Это **сильнейший из имеющихся кандидатов**, +> потому что объясняет весь набор фактов сразу (§1) и подтверждён на идентичном стеке. +> Проверяется **фактом** — SMART + `dmesg` (§5.2), не рассуждением. + +### 5.1. Как проверить память (BIOS + планки) + +1. **BIOS setup: `F10` при старте** → `System Information` / `Memory` — **точный объём и число планок**. + Это ответ на «сколько ставит BIOS». Разводит «планка отваливается» от «дока устарела». +2. **`MemTotal` после холодного сброса** — если меняется между загрузками → планка/слот нестабильны (§3.1.1). +3. **Планки по одной** — вынуть вторую, стартовать с первой, затем наоборот. +4. **Контакты** — вынуть, протереть ластиком (HP: золочение обязательно; окисление — штатный отказ). +5. **memtest86+** (`memtest.org`) — грузится с USB, понимает legacy BIOS **и** UEFI. + ⚠️ **MemTest86 v11.7 (memtest86.com) — только UEFI**, на t610 **не загрузится**; + для legacy брать **v4**. Гонять **часами**, потом **каждую планку отдельно**. + Показывает и объём **как его видит BIOS**, и ошибки по адресам. +6. 🔑 **Физически «дропнуть 3 ГБ в процессе работы» невозможно** — объём виден ядру + один раз при загрузке через BIOS и не пересчитывается. «Дропнула память» на практике + означает **зависла**, а не потеряла. Режим отказа — **нестабильная планка**: иногда + не определяется с первого раза, иногда ребут, иногда зависон под нагрузкой. + +### 5.2. Как проверить носитель (первый приоритет) + +```bash +# ① SMART — ГЛАВНЫЙ тест. Ищем НЕНУЛЕВЫЕ: +# Reallocated_Sector_Ct, Current_Pending_Sector, +# Offline_Uncorrectable, UDMA_CRC_Error_Count +ssh root@192.168.2.176 'smartctl -a /dev/sda' + +# ② Ошибки I/O в dmesg: ata, I/O error, failed command, medium error, UNC +ssh root@192.168.2.176 'dmesg | grep -iE "ata|I/O error|failed command|medium error|UNC|sense key"' + +# ③ Долгий тест (часы) +ssh root@192.168.2.176 'smartctl -t long /dev/sda' # затем -l selftest +# либо badblocks -nsv /dev/sda8 +``` + +> 🔴 **ПИТФОЛЛ 21 родительской доки (§3.4):** свой `find`/`du` по `/mnt/data` +> **сам создаёт I/O-шторм** и даёт **ложный** вывод «диск деградировал». +> **SMART мерить на ЧИСТОМ фоне** — до любых сканирований, либо через ≥60 с. +> +> ⚠️ **`smartctl` в аддоне `core_ssh` может отсутствовать**, а `docker` там нет +> (§3.5 родительской доки). Если не выйдет из аддона — снимать с другого хоста. + +--- + +## 6. ❓ ОТКРЫТЫЕ ВОПРОСЫ + +Развилка по времени до зависания (ответ **не получен**): | Если… | То диагноз | Куда копать | |---|---|---| -| Вешается **через примерно одинаковый аптайм** (~N часов) | Софт накапливает: утечка в процессе, рост БД, исчерпание ресурса | `recorder` + `exclude`, профилирование памяти по контейнерам во времени | -| Вешается **хаотично** | Железо: питание (блок/USB 500 мА), температура, HDD 5400 rpm, деградация планки RAM | `k10temp`, `pressure/io`, `dmesg \| grep -i usb`, `dmidecode` | +| Вешается через **примерно одинаковый аптайм** | Софт накапливает: утечка, рост БД, исчерпание ресурса | `recorder` + `exclude`, профилирование памяти по контейнерам во времени | +| Вешается **хаотично** | Железо: питание, температура, **HDD 5400 rpm**, **деградация планки RAM** | SMART, `k10temp`, `pressure/io`, `dmesg \| grep -i usb`, BIOS | -**Ответ Alex на этот вопрос — НЕ ПОЛУЧЕН.** Это следующее, что нужно выяснить. - -Дополнительные вопросы, ответы на которые нужны: +Также не выяснено: +- Это **какой по счёту** раз? Есть ли даты/периодичность предыдущих зависаний? - В момент зависания хост **отвечал вообще** (веб открывался, но тупил) или пропал полностью? -- Это какой по счёту раз? Есть ли даты предыдущих зависаний? --- -## 6. 📋 Предложение (НЕ одобрено, НЕ внедрено) +## 7. 📋 Предложение (НЕ одобрено, НЕ внедрено) > ⛔ **Ничего из этого не применено.** План-first: ждёт апрува Alex. > Правки `configuration.yaml` — только через патч + показ диффа → апрув → заливка → проверка Alex'ом. -1. **Сбор метрик, переживающий перезагрузку** — раз в минуту писать в файл на `/mnt/data`: +1. 🔴 **SMART + `dmesg` по носителю** — **первый приоритет** (§5.2). Сильнейший кандидат §5. +2. **Сбор метрик, переживающий перезагрузку** — раз в минуту писать в файл на `/mnt/data`: `MemTotal`/`MemAvailable`/`MemFree`, load, `pressure/io`+`pressure/memory`, `k10temp`, размер БД+WAL, аптайм. **Это то, что даст версию к следующему зависанию** — сейчас каждый - инцидент стирает свои следы. -2. **`recorder:` с `exclude`** — исключить `sensor.*_summary`, `at2_*_summary`, `update.*`, + инцидент стирает свои следы (§2). +3. **`recorder:` с `exclude`** — исключить `sensor.*_summary`, `at2_*_summary`, `update.*`, `button.*_identify`, `event.*`. Снижает нагрузку на БД. **Не «фикс зависания»** — отдельное улучшение. -3. **Включить watchdog `local_ustreamer`** — единственный аддон без watchdog (§3.7 родительской доки). -4. **Обновить `core_ssh`** 10.4.0 → 10.5.0. +4. **Включить watchdog `local_ustreamer`** — единственный аддон без watchdog (§3.7 родительской доки). +5. **Обновить `core_ssh`** 10.4.0 → 10.5.0. -> 📌 Версия **«что именно вешает»** появится **только после п.1**. Без ретенции расследование -> упирается в §2 и превращается в перебор гипотез. +> 📌 Версия **«что именно вешает»** появится **только после п.1+п.2**. Без ретенции расследование +> упирается в §2 и превращается в перебор гипотез — что и произошло в сессии 2026-09-17. --- -## 7. Питфоллы сессии (дополнение к родительской доке) +## 8. Питфоллы сессии (дополнение к родительской доке) | # | Питфолл | Обход | |---|---|---| -| 53 | 🔴 **Журнал прошлого запуска недоступен ПОСЛЕ жёсткого зависания** — подтверждено повторно, 5 источников пусты | Ставить диагноз ДО ребута, либо ретенция (§6.1). Логбук в `home-assistant_v2.db` **переживает** ребут — использовать его | +| 53 | 🔴 **Журнал прошлого запуска недоступен ПОСЛЕ жёсткого зависания** — подтверждено повторно, 5 источников пусты | Ставить диагноз ДО ребута, либо ретенция (§7.2). Логбук в `home-assistant_v2.db` **переживает** ребут — использовать его | | 54 | ⚠️ **`ha core logs` показывает только текущий контейнер** (12 строк s6-rc), не историю | Не искать «старые строки» — их нет | -| 55 | ⚠️ **`MemTotal` может расходиться с докой** — живой факт `1.44 ГБ` против зафиксированных `3.31 ГБ` (§3.9 родительской доки) | Всегда перемерять `head -3 /proc/meminfo` при разборе инцидента, не полагаться на записанное | +| 55 | ⚠️ **`MemTotal` может расходиться с докой** — живой факт `1.44 ГБ` против зафиксированных `3.31 ГБ` (§3.9 родительской доки) | Всегда перемерять `head -3 /proc/meminfo` + e820 при разборе инцидента, не полагаться на записанное | | 56 | 🔴 **`http://192.168.2.176:8123` из LAN → `curl` exit 7, хоть хост жив** | Единственный путь к API — `https://mallexxx.duckdns.org`. Совпадает с питфоллом 1 | | 57 | ⚠️ **После холодного старта ZHA догружается**: часть сущностей минуты висит `unavailable` | Не спешить с выводом «устройства отвалились» — перемерить через 2–3 мин. Первый снимок дал 75 сущностей, полный — 310 | +| 58 | 🔴 **`dmidecode` на t610 НЕТ**, `/sys/firmware/dmi/entries/17-*/raw` пуст | Число/объём планок — только **BIOS setup** (F10). `MemTotal` + e820 дают объём, но не число планок | +| 59 | 🔴 **`dmesg` на t610 требует `\| tail`** — без хвоста врёт (питфолл 5 родительской доки, подтверждён) | Всегда `dmesg \| grep … \| tail` | +| 60 | 🔴 **Порядок расследования: ФАКТЫ → версия, а не версия → проверка** | Три подряд опровергнутые «версии» (§4) съели сессию. Сначала e820/BIOS/SMART/метрики, потом формулировка | +| 61 | ⚠️ **Симптом-матч с форума ≠ доказательство** | Тред `1025213` совпал по версии стека и симптомам, но это **кандидат**, не причина. Закрывать только фактом по §5.2 |