From 1790c060ffe475a411af7819fe7fa582cd1d8828 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 12:49:30 +0600 Subject: [PATCH 01/81] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 32 ++++++++++++------- 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 26efe5ca..11499514 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,6 +1,15 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-01 +> Обновлено: 2026-08-17 + +## ✅ РЕШЕНО: HGST 12TB завёлся — проблема была в 3.3V PWDIS, НЕ в карте + +**2026-08-17.** HGST **линуется и полностью работает** теперь. Ключевое изменение — **отключена/обезврежена 3.3V линия (PWDIS-контакт №3 на SATA-разъёме питания)**. Диск: +- определяется как `/dev/sde`, `HGST HUH721212ALE600`, серийник `8CKD08RE`, **10.9T**, секторов `23437770752` (штатная ёмкость 12TB по SFF-8447) +- **подключён на карте ASMedia (ata7 = 0000:02:00.0, host7)** — той самой, где раньше НЕ линковался! +- **разметка сохранена без переразметки**: `sde1`=200M, `sde2`=10.9TB (та GPT, что была и через USB) + +**Вывод:** причина молчания была **100% в 3.3V Power Disable (PWDIS)** — enterprise-диск с поддержкой PWDIS не раскручивается, когда обычный БП подаёт 3.3V на пин №3 SATA-питания. Снятие 3.3V-контакта устранило проблему. **Карта ASM1166 и порт материнки при этом работали и раньше.** Переразметка для решения НЕ требуется. ## Материнская плата @@ -17,6 +26,8 @@ | ata4 (SATA3G_2) | SATA 2 | 3 Gb/s | синий | **sde** — Kingston 120GB SSD (boot) | 50026B77844E881C | | ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | *свободен* | — | | ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sdd** — Seagate 4TB (ST4000DM004) | WFN66CM2 | +| **ata7** (карта ASM1166 02:00.0) | — | — | — | **sde — HGST Ultrastar 12TB (HUH721212ALE600)** ✅ | 8CKD08RE / wwn-0x5000cca26fefbc05 | +| **ata9** (карта ASM1166 02:00.0) | — | — | — | **sdf** — WD 2TB (WD20EFAX, второй) | WD-WXJ2A31CUNNT | > ⚠️ В отличие от изначального плана, **IronWolf 12TB сейчас на ata2 (SATA6G_2)**, а не на ata5. Это нормально — ZFS не привязана к порту (см. ниже). @@ -46,19 +57,16 @@ **➡️ Уточнённый диагноз:** проблема **именно в паре HGST SATA-интерфейс ↔ SATA-карта ASMedia**, а не в самом диске. Диск работоспособен. Две вероятные причины не-линка по SATA в карте: (1) питание с SATA-разъёма БП до диска в карте не доходит (в USB-боксе питание даёт мост/свой блок, потому и работает), либо (2) enterprise-диск (4Kn/особый PHY) не поднимает линк на ASM1166. USB-мост — рабочий способ диагностики, но ненадёжен как постоянное решение для ZFS. -## Следующие шаги (HGST 12TB — статус: диск рабочий через USB, но по SATA-карте не линкуется) +## ✅ Решение HGST 12TB (2026-08-17) — корень найден, диск работает -Цель — завести HGST в пул TrueNAS. USB-мост подтвердил исправность диска; теперь вопрос только в SATA-линке. +Проблема не-линка HGST по SATA **решена: это 3.3V PWDIS на SATA-питании.** Диск уже работает на карте ASMedia (ata7, см. таблицу выше). Разметка не трогалась — sde1=200M, sde2=10.9TB остались как были. Осталось: добавить диск в пул TrueNAS по by-id/GUID (ZFS к порту не привязана). После добавления — удалить этот блок. -1. **Вариант А (рекомендуется):** вешать HGST на **свободный SATA-порт материнки ata5 (SATA3G_3, синий)** вместо карты. Intel H77 AHCI к enterprise-дискам надёжнее, чем ASM1166. После подключения проверить `lsscsi -g` — диск должен появиться на хосте материнки (host 0/1/2/3/5). Если заведётся — добавить в пул по by-id/GUID (ZFS не привязана к порту). -2. **Вариант Б (проверочный):** вернуть HGST в тот же порт/кабель карты, где определялся рабочий WD 2TB (host9). Если с заведомо рабочим кабелем/портом HGST всё равно не даёт `target*` → подтверждается мизер питания до диска в карте или несовместимость PHY HGST↔ASM1166. -3. **Особое внимание питанию:** у карты нет отдельного питания, диск в карте питается SATA-разъёмом напрямую. Проверить, что кабель питания доходит и даёт 12V — подозрение, что в USB-боксе питание подаёт мост, а в SATA-схеме до HGST оно не доходит. -4. Проверить появился ли диск на материнке после переноски: -```bash -lsscsi -g # смотреть новые /dev/sd* на хостах материнки (0,1,2,3,5) -lsblk -o NAME,SIZE,MODEL,TRAN -``` -5. Если HGST заведётся и добавится в пул — обновить таблицу портов и удалить этот блок. +**Что было/что стало:** +- Было: HGST не давал `target*` ни на одном порту карты ASM1166 (USB-мост работал, потому что питание подавал мост, не затрагивая PWDIS). +- Стало: после отключения 3.3V-контакта HGST линкуется на той же карте (ata7/02:00.0) — карта и материнка исправны, дело было в питании. +- **Переразметка для решения не нужна** — проблема на уровне PHY/питания, а не данных. + +> ⚠️ Если такой же enterprise-диск (HGST/WD Ultrastar/Seagate Exos c PWDIS) снова «молчит» по SATA — первым делом проверить 3.3V-пин №3 питания: Molex→SATA адаптер (без 3.3V) или изоляция пина №3 решают. > ⚠️ NB: буквы дисков (`sda`/`sdb`/...) **shift-аются при перетыкивании** — сейчас на материнке: [0]=WD2TB, [2]=WD4TB, [3]=Kingston boot, [5]=Seagate4TB, IronWolf на [1]. Не полагаться на буквы, проверять по `by-id`/модели. From a2c72793deb5adcd36af5c0ebfded2817a7dc23d Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 13:15:17 +0600 Subject: [PATCH 02/81] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 44 ++++++++++++++----- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 11499514..9881b059 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -16,20 +16,24 @@ **ASUS P8H77-V LE**, чипсет Intel H77. 6 SATA портов на Intel контроллере (порт от ASMedia отсутствует). -### Распределение портов (текущее состояние) +### Распределение портов (текущее состояние — после перетыкания 2026-08-17) | Порт (ata) | Тип | Скорость | Цвет | Диск | by-id | |------------|-----|----------|------|------|-------| | ata1 (SATA6G_1) | SATA 3 | 6 Gb/s | серый | **sda** — WD 2TB (WD20EFAX) | WD-WXH2A31D5HDJ | -| ata2 (SATA6G_2) | SATA 3 | 6 Gb/s | серый | **sdc** — Seagate IronWolf 12TB (ST12000NT001) | WV700FQ5 | -| ata3 (SATA3G_1) | SATA 2 | 3 Gb/s | синий | **sdb** — WD 4TB (WD40EZAZ) | WD-WX22D51JJFZ7 | -| ata4 (SATA3G_2) | SATA 2 | 3 Gb/s | синий | **sde** — Kingston 120GB SSD (boot) | 50026B77844E881C | -| ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | *свободен* | — | -| ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sdd** — Seagate 4TB (ST4000DM004) | WFN66CM2 | -| **ata7** (карта ASM1166 02:00.0) | — | — | — | **sde — HGST Ultrastar 12TB (HUH721212ALE600)** ✅ | 8CKD08RE / wwn-0x5000cca26fefbc05 | -| **ata9** (карта ASM1166 02:00.0) | — | — | — | **sdf** — WD 2TB (WD20EFAX, второй) | WD-WXJ2A31CUNNT | +| ata2 (SATA6G_2) | SATA 3 | 6 Gb/s | серый | **sdb** — WD 2TB (WD20EFAX, второй, был на карте ata9) | WD-WXJ2A31CUNNT | +| ata3 (SATA3G_1) | SATA 2 | 3 Gb/s | синий | **sdc** — WD 4TB (WD40EZAZ) | WD-WX22D51JJFZ7 | +| ata4 (SATA3G_2) | SATA 2 | 3 Gb/s | синий | **sdd** — Kingston 120GB SSD (boot) | 50026B77844E881C | +| ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | *занято диском* | — | +| ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sde** — Seagate 4TB (ST4000DM004) | WFN66CM2 | +| *(карта ASM1166)* | — | — | — | **НЕ В СЛОТЕ** (lspci не видит) | — | -> ⚠️ В отличие от изначального плана, **IronWolf 12TB сейчас на ata2 (SATA6G_2)**, а не на ata5. Это нормально — ZFS не привязана к порту (см. ниже). +**⚠️ Состояние на 2026-08-17 после перетыкания:** +- **Карта ASMedia ASM1166 физически вытащена из слота** (нет в `lspci`); `/sys/class/ata_port/` содержит только ata1–ata6 (материнка Intel H77). WD 2TB #2 перенесён с карты (ata9) на материнку ata2. +- **HGST 12TB и IronWolf 12TB сейчас НЕ подключены/НЕ линкуются** — их нет ни в `lsscsi`, ни в `/dev/disk/by-id`. Не были бы они и на карте (карты нет). HGST мы заводили на карте, значит при её извлечении он отключился. +- Несмотря на перетыкание пулы **здоровы** (см. раздел про пулы ниже) — подтверждено, что ZFS не зависит от порта. + +> ⚠️ В отличие от изначального плана, диски сейчас не по плану — проверять актуальное распределение по `by-id`/модели, а не по буквам. Типичные буквы при стабильном подключении: sda=WD2TB#1, sdb=WD2TB#2, sdc=WD4TB, sdd=Kingston, sde=Seagate4TB. ## Плата расширения SATA в PCIe (установлена ~2026-07-30) @@ -59,7 +63,9 @@ ## ✅ Решение HGST 12TB (2026-08-17) — корень найден, диск работает -Проблема не-линка HGST по SATA **решена: это 3.3V PWDIS на SATA-питании.** Диск уже работает на карте ASMedia (ata7, см. таблицу выше). Разметка не трогалась — sde1=200M, sde2=10.9TB остались как были. Осталось: добавить диск в пул TrueNAS по by-id/GUID (ZFS к порту не привязана). После добавления — удалить этот блок. +> ⚠️ **Актуальный статус на 2026-08-17 вечер:** хоть HGST и завёлся (см. ниже КАК), в финальном перетыкании **карта ASM1166 вытащена из слота, HGST и IronWolf сейчас НЕ подключены** (подробнее в таблице портов выше). Этот блок фиксирует **как была решена причина не-линка** — пригодится, когда диск вернётся в систему. + +Проблема не-линка HGST по SATA **решена: это 3.3V PWDIS на SATA-питании.** Разметка не трогалась — sde1=200M, sde2=10.9TB остались как были. Когда диск снова будет подключён — добавить в пул TrueNAS по by-id/GUID (ZFS к порту не привязана). После добавления — удалить этот блок. **Что было/что стало:** - Было: HGST не давал `target*` ни на одном порту карты ASM1166 (USB-мост работал, потому что питание подавал мост, не затрагивая PWDIS). @@ -93,11 +99,25 @@ lspci -k | grep -i sata - **Kingston SSD (boot)** — оставить в синем порту SATA3G_2 (ata4). Вся активность только при загрузке, система работает из RAM. - **WD 2TB** — серый SATA6G_1 (ata1), занят. -## Важно про ZFS и перетыкивание +## Важно про ZFS и перетыкание - ZFS не привязана к букве диска или SATA порту. TrueNAS распознаёт пул по GUID на дисках. -- Можно перетыкать диски в любые порты — TrueNAS поднимет пул автоматически. +- Можно перетыкать диски в любые порты — TrueNAS поднимет пул автоматически (подтверждено 2026-08-17). - Если пул не поднялся автоматически: WebUI → Storage → Import Pool. +- Проверка пула после перетыкания: `/sbin/zpool status ` — убедиться что все члены `ONLINE`, ошибки `0 0 0`. + +## Пулы TrueNAS (проверено 2026-08-17) + +Имена пулов, топология и члены — проверять статус через `/sbin/zpool` (см. ниже про PATH). + +| Пул | Размер | Члены (по /dev со стабильным подключением) | Топология | Монтирование | +|-----|--------|-----------|-----------|--------------| +| **RED_2TB** | 5.44T (4.60T занято) | mirror: `sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB) | 1 диск (sda2) + mirror-1 (2 диска) | `/mnt` | +| **boot-pool** | 111G (7.65G занято) | `sdd3` (Kingston 120GB boot SSD) | 1 диск | — | + +- RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. +- Идёт регулярный scrub (запускается ночью воскресенья). +- **`zpool` не в PATH для zsh truenas_admin** — вызывать через абсолютный путь `/sbin/zpool` или `/usr/sbin/zpool` (иначе `command not found`). ## Запрещено From fad9d476c09f5456ee224bcbfba7447bd032e143 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 13:51:49 +0600 Subject: [PATCH 03/81] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 45 +++++++++++++------ 1 file changed, 32 insertions(+), 13 deletions(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 9881b059..3280a53a 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -16,24 +16,27 @@ **ASUS P8H77-V LE**, чипсет Intel H77. 6 SATA портов на Intel контроллере (порт от ASMedia отсутствует). -### Распределение портов (текущее состояние — после перетыкания 2026-08-17) +### Распределение портов (актуально на конец 2026-08-17, после финального перетыкания) | Порт (ata) | Тип | Скорость | Цвет | Диск | by-id | |------------|-----|----------|------|------|-------| | ata1 (SATA6G_1) | SATA 3 | 6 Gb/s | серый | **sda** — WD 2TB (WD20EFAX) | WD-WXH2A31D5HDJ | -| ata2 (SATA6G_2) | SATA 3 | 6 Gb/s | серый | **sdb** — WD 2TB (WD20EFAX, второй, был на карте ata9) | WD-WXJ2A31CUNNT | -| ata3 (SATA3G_1) | SATA 2 | 3 Gb/s | синий | **sdc** — WD 4TB (WD40EZAZ) | WD-WX22D51JJFZ7 | +| ata2 (SATA6G_2) | SATA 3 | 6 Gb/s | серый | **sdb** — WD 4TB (WD40EZAZ) | WD-WX22D51JJFZ7 | +| ata3 (SATA3G_1) | SATA 2 | 3 Gb/s | синий | **sdc** — ⭐ **IronWolf 12TB (ST12000NT001)** | WV700FQ5 | | ata4 (SATA3G_2) | SATA 2 | 3 Gb/s | синий | **sdd** — Kingston 120GB SSD (boot) | 50026B77844E881C | -| ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | *занято диском* | — | +| ata5 (SATA3G_3) | SATA 2 | 3 Gb/s | синий | *(свободен/не иден-тиф.)* | — | | ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sde** — Seagate 4TB (ST4000DM004) | WFN66CM2 | -| *(карта ASM1166)* | — | — | — | **НЕ В СЛОТЕ** (lspci не видит) | — | +| *(карта ASM1166)* | — | — | — | **НЕ В СЛОТЕ** (вытащена) | — | -**⚠️ Состояние на 2026-08-17 после перетыкания:** -- **Карта ASMedia ASM1166 физически вытащена из слота** (нет в `lspci`); `/sys/class/ata_port/` содержит только ata1–ata6 (материнка Intel H77). WD 2TB #2 перенесён с карты (ata9) на материнку ata2. -- **HGST 12TB и IronWolf 12TB сейчас НЕ подключены/НЕ линкуются** — их нет ни в `lsscsi`, ни в `/dev/disk/by-id`. Не были бы они и на карте (карты нет). HGST мы заводили на карте, значит при её извлечении он отключился. -- Несмотря на перетыкание пулы **здоровы** (см. раздел про пулы ниже) — подтверждено, что ZFS не зависит от порта. +**⚠️ Фактическое положение на конец сессии (2026-08-17):** +- **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`) и не относящийся к делу PCIe-to-PCI bridge ASM1083. WD 2TB#2 перенесён с карты на материнку. +- **⭐ IronWolf 12TB теперь ПОДКЛЮЧЁН и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он не в пуле (новый диск). +- **WD 2TB #2 (`WD-WXJ2A31CUNNT`) исчез из системы** — раньше был `sdb` (перенесён с карты), после финального перетыкания не виден. Уточнить где он. +- **HGST 12TB (`HUH721212ALE600`) по-прежнему НЕ виден** — ни в `lsscsi`, ни в by-id. Питание: если он подключён обычным SATA-кабелем — молчит из-за **PWDIS (3.3V на пине 3)**, для него нужен Molex→SATA или снятый пин 3 (см. блок решения выше). -> ⚠️ В отличие от изначального плана, диски сейчас не по плану — проверять актуальное распределение по `by-id`/модели, а не по буквам. Типичные буквы при стабильном подключении: sda=WD2TB#1, sdb=WD2TB#2, sdc=WD4TB, sdd=Kingston, sde=Seagate4TB. +> ⚠️ Буквы (`sda`/`sdb`) **shift-аются при перетыкании** и сейчас разъехались: `sdb` = WD4TB (не WD2TB#2!), `sdc` = IronWolf. **Всегда сверять по by-id/модели, не полагаться на буквы.** + +> ⚠️ ⚡ **СРОЧНО:** пул `RED_2TB` после этого перетыкания НЕ заимпортирован (см. блок «КРИТИЧНО» в разделе пулов). Все члены на месте — нужен Import Pool. ## Плата расширения SATA в PCIe (установлена ~2026-07-30) @@ -102,8 +105,7 @@ lspci -k | grep -i sata ## Важно про ZFS и перетыкание - ZFS не привязана к букве диска или SATA порту. TrueNAS распознаёт пул по GUID на дисках. -- Можно перетыкать диски в любые порты — TrueNAS поднимет пул автоматически (подтверждено 2026-08-17). -- Если пул не поднялся автоматически: WebUI → Storage → Import Pool. +- **Перетыкание НЕ всегда поднимает пул автоматически** (2026-08-17: RED_2TB не заимпортировался сам после перетыкания, см. «КРИТИЧНО» ниже). Если пул не виден в `zpool list` — нужен ручной Import (WebUI Storage → Import Pool или `zpool import ` под root). Данные при этом целы, пока все члены `ONLINE`. - Проверка пула после перетыкания: `/sbin/zpool status ` — убедиться что все члены `ONLINE`, ошибки `0 0 0`. ## Пулы TrueNAS (проверено 2026-08-17) @@ -112,10 +114,27 @@ lspci -k | grep -i sata | Пул | Размер | Члены (по /dev со стабильным подключением) | Топология | Монтирование | |-----|--------|-----------|-----------|--------------| -| **RED_2TB** | 5.44T (4.60T занято) | mirror: `sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB) | 1 диск (sda2) + mirror-1 (2 диска) | `/mnt` | +| **RED_2TB** | 5.44T (4.60T занято) | mirror: `sdb2`/`sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB) | 1 диск (sda2) + mirror-1 (2 диска) | `/mnt` — **⚠️ ПОТРЕБУЕТСЯ IMPORT, см. ниже** | | **boot-pool** | 111G (7.65G занято) | `sdd3` (Kingston 120GB boot SSD) | 1 диск | — | - RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. + +### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB НЕ заимпортирован + +После перетыкания дисков на материнке пул **RED_2TB НЕ поднялся автоматически**: `/sbin/zpool list` показывает только `boot-pool`, а `/sbin/zpool status RED_2TB` → `cannot open 'RED_2TB': no such pool`. + +**Это НЕ потеря данных.** Все члены пула физически на месте и видны системе (проверено 2026-08-17): +- `sda2` = WD2TB#1 (ata1) +- `sdb2` = WD4TB (ata2) — буква сменилась с `sdc` на `sdb` +- `sde2` = Seagate4TB (ata6) + +Пул просто не заимпортировался, вероятно из-за смены букв устройств. **Что нужно сделать (порядок):** +1. TrueNAS WebUI → **Storage → Import Pool** → выбрать `RED_2TB`, импортировать. + - Альтернатива под root: `/sbin/zpool import RED_2TB` (truenas_admin НЕ может — `sudo` требует пароль; `zpool import` даёт `cannot discover pools: permission denied` без root). +2. После импорта проверить: `/sbin/zpool status RED_2TB` → все члены `ONLINE`, `READ WRITE CKSUM` = `0 0 0`. + +> ⚠️ Урок: перетыкание дисков НЕ всегда триггерит авто-импорт, даже когда все члены на месте и ZFS работает по GUID. Буквы могут смениться (`sdc`→`sdb`), и пул ждёт ручного Import. Не паниковать — данные целы, пока все члены `ONLINE` в `lsblk`/by-id. + - Идёт регулярный scrub (запускается ночью воскресенья). - **`zpool` не в PATH для zsh truenas_admin** — вызывать через абсолютный путь `/sbin/zpool` или `/usr/sbin/zpool` (иначе `command not found`). From d4dac6701c32651050bf355c65a0cc2d655f5c2b Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 14:17:18 +0600 Subject: [PATCH 04/81] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 26 +++++++++++++++---- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 3280a53a..1d31831a 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,8 +1,24 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 +> Обновлено: 2026-08-17 (финал: HGST упал, см. блок ниже) -## ✅ РЕШЕНО: HGST 12TB завёлся — проблема была в 3.3V PWDIS, НЕ в карте +## ⚠️⚠️ КРИТИЧНО: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения + +**2026-08-17 вечер.** HGST (HUH721212ALE600, сер. 8CKD08RE) **уронили на пол, будучи подключённым**. Развитие сценария (как происходило): + +1. **После удара — сектор 0 стал нечитаем** (по USB-мосту): ядро давало `critical medium error, dev sdf, sector 0` → `Add. Sense: Unrecovered read error` → `unable to read partition table` / `unable to read RDB block 0`. Разметка (`sdf1`/`sdf2`) пропала. Это НЕ ошибка моста/кабеля — `hostbyte=DID_OK driverbyte=DRIVER_OK`, ошибку вернул сам диск. +2. **smartctl мог прочитать INFO-секцию** (`Model: HGST HUH721212ALE600`, `8CKD08RE`, FW `LEBDT3P2`, 512e, SATA 6.0 Gb/s, SMART enabled) — контроллер жив, линк поднят. +3. **На MacBook через USB-мост диск «щёлкает» и не шуршит головкой при старте** — признак механических проблем после удара (головки/мотор). КЛИК-ОФ-ДЕФ возможен, но также нельзя исключать нехватку питания через USB-мост на 12TB-диске. + +**Состояние:** не подтверждён полный отказ, но высокая вероятность аппаратного повреждения от падения. Сектор 0 (начало диска /GPT) повреждён точно. Масштаб (1 сектор или сотни) НЕ определён — длинный SMART-тест не удалось прогнать, т.к. диск щёлкает. + +**Что НЕ делать:** не махать диском, не запускать запись/ремонт сектора 0 до понимания масштаба, не использовать как свежий пул — доверие к диску утрачено. Если диск ещё вращается — прогонять длинный SMART-тест по SATA (с Molex-питанием) чтобы оценить `Current_Pending_Sector`. + +> 🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон — теперь состояние под вопросом. + +--- + +## ✅ РЕШЕНО (исторически): HGST 12TB заводился — проблема была в 3.3V PWDIS, НЕ в карте **2026-08-17.** HGST **линуется и полностью работает** теперь. Ключевое изменение — **отключена/обезврежена 3.3V линия (PWDIS-контакт №3 на SATA-разъёме питания)**. Диск: - определяется как `/dev/sde`, `HGST HUH721212ALE600`, серийник `8CKD08RE`, **10.9T**, секторов `23437770752` (штатная ёмкость 12TB по SFF-8447) @@ -31,8 +47,8 @@ **⚠️ Фактическое положение на конец сессии (2026-08-17):** - **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`) и не относящийся к делу PCIe-to-PCI bridge ASM1083. WD 2TB#2 перенесён с карты на материнку. - **⭐ IronWolf 12TB теперь ПОДКЛЮЧЁН и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он не в пуле (новый диск). -- **WD 2TB #2 (`WD-WXJ2A31CUNNT`) исчез из системы** — раньше был `sdb` (перенесён с карты), после финального перетыкания не виден. Уточнить где он. -- **HGST 12TB (`HUH721212ALE600`) по-прежнему НЕ виден** — ни в `lsscsi`, ни в by-id. Питание: если он подключён обычным SATA-кабелем — молчит из-за **PWDIS (3.3V на пине 3)**, для него нужен Molex→SATA или снятый пин 3 (см. блок решения выше). +- **WD 2TB #2 (`WD-WXJ2A31CUNNT`) НАМЕРЕННО отключён** пользователем (2026-08-17). Раньше был `sdb` (перенесён с карты), затем Alex его отключил «это норм». Сейчас отсутствует по замыслу, а не по ошибке. +- **HGST 12TB (`HUH721212ALE600`)** — был подключён по USB (виден как `sdf`, model HGST, WWN `0x5000cca26fefbc05`) и после удара о пол НЕ работает надёжно (см. блок КРИТИЧНО в самом верху). На текущий момент считаем его вышедшим из строя. > ⚠️ Буквы (`sda`/`sdb`) **shift-аются при перетыкании** и сейчас разъехались: `sdb` = WD4TB (не WD2TB#2!), `sdc` = IronWolf. **Всегда сверять по by-id/модели, не полагаться на буквы.** @@ -66,7 +82,7 @@ ## ✅ Решение HGST 12TB (2026-08-17) — корень найден, диск работает -> ⚠️ **Актуальный статус на 2026-08-17 вечер:** хоть HGST и завёлся (см. ниже КАК), в финальном перетыкании **карта ASM1166 вытащена из слота, HGST и IronWolf сейчас НЕ подключены** (подробнее в таблице портов выше). Этот блок фиксирует **как была решена причина не-линка** — пригодится, когда диск вернётся в систему. +> ⚠️ **Актуальный статус на 2026-08-17 ночь:** HGST **УРОНЕН НА ПОЛ и сломан** (см. блок КРИТИЧНО в самом верху). Карта ASM1166 вытащена из слота, IronWolf подключён на материнку. Этот блок фиксирует **как изначально решалась причина не-линка** (PWDIS) — полезно для понимания, но теперь диск вышел из строя механически. Проблема не-линка HGST по SATA **решена: это 3.3V PWDIS на SATA-питании.** Разметка не трогалась — sde1=200M, sde2=10.9TB остались как были. Когда диск снова будет подключён — добавить в пул TrueNAS по by-id/GUID (ZFS к порту не привязана). После добавления — удалить этот блок. From d01c84c2bc85acf720a1d37ad5d0f4706c9cef0f Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 14:49:16 +0600 Subject: [PATCH 05/81] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 54 +++++++++++++++---- 1 file changed, 44 insertions(+), 10 deletions(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 1d31831a..c67f9783 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,8 +1,12 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 (финал: HGST упал, см. блок ниже) +> Обновлено: 2026-08-17 ночь (два КРИТИЧНО: HGST упал и сломан; RED_2TB вызывает kernel panic — см. раздел пулов) -## ⚠️⚠️ КРИТИЧНО: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB вызывает KERNEL PANIC (важнее HGST) + +См. раздел «Пулы TrueNAS» → блок «RED_2TB не импортируется — вызывает KERNEL PANIC». Это приоритет №1 — данные реально есть. Система в panic loop; рецепт: тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем import. + +## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения **2026-08-17 вечер.** HGST (HUH721212ALE600, сер. 8CKD08RE) **уронили на пол, будучи подключённым**. Развитие сценария (как происходило): @@ -135,21 +139,51 @@ lspci -k | grep -i sata - RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. -### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB НЕ заимпортирован +### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB не импортируется — вызывает KERNEL PANIC -После перетыкания дисков на материнке пул **RED_2TB НЕ поднялся автоматически**: `/sbin/zpool list` показывает только `boot-pool`, а `/sbin/zpool status RED_2TB` → `cannot open 'RED_2TB': no such pool`. +После перетыкания дисков на материнке пул **RED_2TB не поднялся автоматически**, и при попытке `zpool import -F` система упала в **kernel panic bootloop**: -**Это НЕ потеря данных.** Все члены пула физически на месте и видны системе (проверено 2026-08-17): +``` +panic - not syncing: zfs: adding existent segment to range tree + ZFS: space_map_load / metaslab_activate / zio_dva_allocate → zfs_panic_recover +``` + +**Что это:** повреждение space map (метаданных ZFS) пула — один и тот же блок учтён дважды / неконсистентное отображение. При обычном импорте ZFS званивает panic по-умолчанию. **Это не обязательно полная потеря данных**, но структура пула повреждена. + +**Триггер (вероятный):** диски-члены отвалились во время работы/перезагрузки при перетыкании, или один из членов имеет скрытую проблему в области метаданных. Члены пула при этом физически на месте: - `sda2` = WD2TB#1 (ata1) - `sdb2` = WD4TB (ata2) — буква сменилась с `sdc` на `sdb` - `sde2` = Seagate4TB (ata6) -Пул просто не заимпортировался, вероятно из-за смены букв устройств. **Что нужно сделать (порядок):** -1. TrueNAS WebUI → **Storage → Import Pool** → выбрать `RED_2TB`, импортировать. - - Альтернатива под root: `/sbin/zpool import RED_2TB` (truenas_admin НЕ может — `sudo` требует пароль; `zpool import` даёт `cannot discover pools: permission denied` без root). -2. После импорта проверить: `/sbin/zpool status RED_2TB` → все члены `ONLINE`, `READ WRITE CKSUM` = `0 0 0`. +**Сейчас система грузится В panic loop каждый раз** (автоимпорт RED_2TB валит ядро на старте). + +#### ✅ РЕЦЕПТ ВОССТАНОВЛЕНИЯ (подтверждён web-источниками, openzfs #15030 + треды TrueNAS) + +**Панику в ZFS можно превратить в warning тремя тюнабелями** (передача как параметров ядра в GRUB): + +1. **В загрузочном меню GRUB** (при старте держать Shift/ESC) выбрать ядро TrueNAS, нажать `e`, в строке с `linux`/`vmlinuz` добавить в конец: + ``` + zfs.zfs_recover=1 zfs.zil_replay_disable=1 + ``` + `Ctrl+X` загрузиться. Это даёт системе дойти до консоли/WebUI без паники (Panic→warning). + +2. **Под root импортировать пул аккуратно** (не форс-катастрофически с наскоку): + ```bash + /sbin/zpool import # какие пулы видит, без монтирования + /sbin/zpool import -n RED_2TB # dry-run — нужен ли -F и не падает ли + /sbin/zpool import -F RED_2TB # только если dry-run показал, что требуется -F + ``` + > В треде TrueNAS подтверждено: `zpool import -f -F -X` «не срабатывало», а с тюнабелями в GRUB + импортом — срабатывает. Сначала тюнабели, потом import. + +3. **После импорта:** `/sbin/zpool status RED_2TB` → оценить члена с ошибками. Снять важные данные с пула на другие диски при первой возможности (импорт `-F` + recover может ценой части изменений). Честно проверить RAM/ECC — в треде #31410 это был реальный фактор повреждения. + +> ⚠️ Пока пул не восстановлен, **НЕ запускать повторный автоимпорт/`-F` сипломи** — каждый заход углубляет риск. Сначала тюнабели в GRUB. + +> ⚠️ Альтернативный обход для диагностики без паники: импорт **readonly** (`zpool import -o readonly=on RED_2TB`) может не паниковать, но данные могут быть недоступны из-за permission errors. + +**Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. + -> ⚠️ Урок: перетыкание дисков НЕ всегда триггерит авто-импорт, даже когда все члены на месте и ZFS работает по GUID. Буквы могут смениться (`sdc`→`sdb`), и пул ждёт ручного Import. Не паниковать — данные целы, пока все члены `ONLINE` в `lsblk`/by-id. - Идёт регулярный scrub (запускается ночью воскресенья). - **`zpool` не в PATH для zsh truenas_admin** — вызывать через абсолютный путь `/sbin/zpool` или `/usr/sbin/zpool` (иначе `command not found`). From 7243b6be8d8f82e8b3215046bbc34c525f1b8a24 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 14:54:45 +0600 Subject: [PATCH 06/81] [2026-08-17] eagle: family/how-to/truenas-infrastructure.md --- family/how-to/truenas-infrastructure.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index e05d5a98..7bc5fbf0 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -1,6 +1,10 @@ # TrueNAS — инфраструктура -> Обновлено: 2026-07-06 +> Обновлено: 2026-08-17 + +> ## ⚠️⚠️ КРИТИЧНО (2026-08-17): пул RED_2TB вызывает KERNEL PANIC — все данные/контейнеры/в vault на этом пуле недоступны +> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Этот пул сейчас в дауне — система в kernel panic bootloop из-за повреждённой space map (ошибка `adding existent segment to range tree` при `import -F`). +> **Рецепт восстановления и полная картина — в `family/how-to/truenas-sata-ports-and-zfs-pools.md`** (раздел «Пулы»): тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем аккуратный `zpool import`. ПОКА НЕ РЕШЕНО — инфраструктура, завязанная на `/mnt/RED_2TB`, не работает. ## Доступ From 6c7b9fbb9ee57e5e3af493a0dff3bc748a0e4b4c Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 16:24:53 +0600 Subject: [PATCH 07/81] [2026-08-17] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md personal/tech/truenas-zfs-panic-recovery.md --- .../truenas-sata-ports-and-zfs-pools.md | 76 +++++++++---------- personal/tech/truenas-zfs-panic-recovery.md | 66 ++++++++++++++++ 2 files changed, 102 insertions(+), 40 deletions(-) create mode 100644 personal/tech/truenas-zfs-panic-recovery.md diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index c67f9783..c32b9394 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,10 +1,10 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 ночь (два КРИТИЧНО: HGST упал и сломан; RED_2TB вызывает kernel panic — см. раздел пулов) +> Обновлено: 2026-08-17 глубокая ночь (РО: HGST упал и сломан; RED_2TB импортирован READONLY — смонтировать datasets и выгрузить — см. раздел пулов) -## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB вызывает KERNEL PANIC (важнее HGST) +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы (данные ещё НЕ выгружены) -См. раздел «Пулы TrueNAS» → блок «RED_2TB не импортируется — вызывает KERNEL PANIC». Это приоритет №1 — данные реально есть. Система в panic loop; рецепт: тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем import. +См. раздел «Пулы TrueNAS» → блок «RED_2TB readonly-импорт». **Прогресс:** пан-loop преодолён (см. рецепт ниже), RD_2TB импортирован readonly успешно. **Осталось смонтировать datasets вручную и выгрузить данные** — точка монтирования не создалась из-за read-only корневой ФС. Это приоритет №1 — данные есть. ## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения @@ -14,11 +14,11 @@ 2. **smartctl мог прочитать INFO-секцию** (`Model: HGST HUH721212ALE600`, `8CKD08RE`, FW `LEBDT3P2`, 512e, SATA 6.0 Gb/s, SMART enabled) — контроллер жив, линк поднят. 3. **На MacBook через USB-мост диск «щёлкает» и не шуршит головкой при старте** — признак механических проблем после удара (головки/мотор). КЛИК-ОФ-ДЕФ возможен, но также нельзя исключать нехватку питания через USB-мост на 12TB-диске. -**Состояние:** не подтверждён полный отказ, но высокая вероятность аппаратного повреждения от падения. Сектор 0 (начало диска /GPT) повреждён точно. Масштаб (1 сектор или сотни) НЕ определён — длинный SMART-тест не удалось прогнать, т.к. диск щёлкает. +**Состояние (на 2026-08-17):** **подтверждён аппаратный отказ — диск не ремонтопригоден.** Симптом: ритмичный «click-click, click-click» при работающем моторе = головки не могут выйти на дорожку/парковку (классический click of death после удара). Это механическое повреждение, НЕ лечится программно (SMART/прошивка), чинить может только профи-recovery и это дороже нового диска. **Данных на нём НЕТ** (не был добавлен в пул, только новая разметка sdf1/sdf2) — поэтому списан без recovery. Закрыто. -**Что НЕ делать:** не махать диском, не запускать запись/ремонт сектора 0 до понимания масштаба, не использовать как свежий пул — доверие к диску утрачено. Если диск ещё вращается — прогонять длинный SMART-тест по SATA (с Molex-питанием) чтобы оценить `Current_Pending_Sector`. +> ⚠️ Урок для будущего: enterprise-диск, уроненный на пол работающим — почти всегда аппаратная смерть (мотор/головки). Если на диске критичные данные — только профи-recovery, и шанс не 100%. -> 🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон — теперь состояние под вопросом. +> 🔁 ИСТОРИЯ ВОПРОСА: до падения диск был ПОЛНОСТЬЮ рабочим. Причина исходного «молчания» по SATA — PWDIS (см. ниже). После снятия 3.3V завёлся и линковался. Затем урон на пол — аппаратный отказ (click of death). --- @@ -139,47 +139,43 @@ lspci -k | grep -i sata - RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. -### ⚠️ КРИТИЧНО (2026-08-17, после финального перетыкания): RED_2TB не импортируется — вызывает KERNEL PANIC +### ✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена -После перетыкания дисков на материнке пул **RED_2TB не поднялся автоматически**, и при попытке `zpool import -F` система упала в **kernel panic bootloop**: +**Рабочий рецепт получения доступа к данным подтверждён на практике.** Члены пула физически на месте: `sda2`=WD2TB#1 (ata1), `sdb2`=WD4TB (ata2, буква сменилась), `sde2`=Seagate4TB (ata6). -``` -panic - not syncing: zfs: adding existent segment to range tree - ZFS: space_map_load / metaslab_activate / zio_dva_allocate → zfs_panic_recover -``` - -**Что это:** повреждение space map (метаданных ZFS) пула — один и тот же блок учтён дважды / неконсистентное отображение. При обычном импорте ZFS званивает panic по-умолчанию. **Это не обязательно полная потеря данных**, но структура пула повреждена. - -**Триггер (вероятный):** диски-члены отвалились во время работы/перезагрузки при перетыкании, или один из членов имеет скрытую проблему в области метаданных. Члены пула при этом физически на месте: -- `sda2` = WD2TB#1 (ata1) -- `sdb2` = WD4TB (ata2) — буква сменилась с `sdc` на `sdb` -- `sde2` = Seagate4TB (ata6) - -**Сейчас система грузится В panic loop каждый раз** (автоимпорт RED_2TB валит ядро на старте). - -#### ✅ РЕЦЕПТ ВОССТАНОВЛЕНИЯ (подтверждён web-источниками, openzfs #15030 + треды TrueNAS) - -**Панику в ZFS можно превратить в warning тремя тюнабелями** (передача как параметров ядра в GRUB): - -1. **В загрузочном меню GRUB** (при старте держать Shift/ESC) выбрать ядро TrueNAS, нажать `e`, в строке с `linux`/`vmlinuz` добавить в конец: - ``` - zfs.zfs_recover=1 zfs.zil_replay_disable=1 - ``` - `Ctrl+X` загрузиться. Это даёт системе дойти до консоли/WebUI без паники (Panic→warning). - -2. **Под root импортировать пул аккуратно** (не форс-катастрофически с наскоку): +**Что сработало (пошагово):** +1. Тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB → **НЕ помогли** (всё равно паника). `rd.break=pre-mount` и `rd.break` → тоже НЕ помогли. +2. **ЕДИНСТВЕННЫЙ рабочий способ загрузиться без паники:** физически ОТКЛЮЧИТЬ все диски проблемного пула (чтобы дойти до рабочего shell/WebUI), затем вставить обратно. + - Включить с отключёнными дисками RED_2TB (WD2TB#, WD4TB, Seagate4TB) → boot-pool поднимается, паники нет. + - Вставить диски обратно (горячо) в те же порты. +3. **READONLY-импорт не паникует** (по mav из iXsystems: «read-only import doesn't even read space maps»): ```bash - /sbin/zpool import # какие пулы видит, без монтирования - /sbin/zpool import -n RED_2TB # dry-run — нужен ли -F и не падает ли - /sbin/zpool import -F RED_2TB # только если dry-run показал, что требуется -F + zpool import -o readonly=on RED_2TB ``` - > В треде TrueNAS подтверждено: `zpool import -f -F -X` «не срабатывало», а с тюнабелями в GRUB + импортом — срабатывает. Сначала тюнабели, потом import. + → **`Import was successful`** — паники нет, метаданные прочитаны! (попытка `zpool import -nRED_2TB` без `-F` невозможна; `-n` требует `-F` синтаксиса.) +4. **⚠️ Текущий блок:** после readonly-импорта выдаются ошибки монтирования: + ``` + cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system + Import was successful, but unable to mount some datasets + ``` + Причина: корневая ФС readonly (после обхода паники). **Точки монтирования не создаются.** -3. **После импорта:** `/sbin/zpool status RED_2TB` → оценить члена с ошибками. Снять важные данные с пула на другие диски при первой возможности (импорт `-F` + recover может ценой части изменений). Честно проверить RAM/ECC — в треде #31410 это был реальный фактор повреждения. +**СЛЕДУЮЩИЙ ШАГ (не завершён):** смонтировать datasets вручную в существующую/записываемую точку (корневая / readonly). Порядок: +```bash +zfs list -r RED_2TB # какие datasets есть (zfs list работает без mount) +# смонтировать в существующую пустую папку, не создавая новую (или через tmpfs/rw-точку) +# например: +# mkdir -p /mnt/rec 2>/dev/null; (если /mnt rw — иначе выбрать rw-точку) +# zfs set mountpoint=/mnt/rec RED_2TB (или mount -o) +# затем выгружать данные на запасные диски rsync +``` -> ⚠️ Пока пул не восстановлен, **НЕ запускать повторный автоимпорт/`-F` сипломи** — каждый заход углубляет риск. Сначала тюнабели в GRUB. +**Критичные ограничения (выяснены по ходу):** +- `zpool import` требует **root** (`some devices require root privileges`) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root. +- Раньше при readonly-импорте в тредах было: datasets показываются но пути «not found», и полностью нечитаемы (permission denied) если данные повреждены. Здесь readonly-импорт прошёл чисто (no panic) — но монтирование ещё не доведено до конца. +- **Данные на пуле важно выгрузить на другие диски** (пул восстановится только пересозданием — аппаратная метаданная ошибка). Это главный незавершённый шаг. -> ⚠️ Альтернативный обход для диагностики без паники: импорт **readonly** (`zpool import -o readonly=on RED_2TB`) может не паниковать, но данные могут быть недоступны из-за permission errors. +> ⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок. **Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. diff --git a/personal/tech/truenas-zfs-panic-recovery.md b/personal/tech/truenas-zfs-panic-recovery.md new file mode 100644 index 00000000..c9d5b479 --- /dev/null +++ b/personal/tech/truenas-zfs-panic-recovery.md @@ -0,0 +1,66 @@ +# TrueNAS — Восстановление ZFS пула при kernel panic (space map corruption) + +> Создано 2026-08-17. Зеркало скила `truenas-zfs-panic-recovery`. + +## Когда это нужно + +Пул TrueNAS не импортируется и вызывает **kernel panic / boot loop**: +``` +panic - not syncing: zfs: adding existent segment to range tree + ZFS: space_map_load / metaslab_activate / zio_dva_allocate → zfs_panic_recover +``` +Это **повреждение space map (метаданных ZFS)**. НЕ обязательно потеря данных, но структура пула повреждена. Read-write импорт паникует, т.к. читает битые space maps. + +## Ключевая идея + +**Read-only import НЕ читает space maps и НЕ паникует** (mav/iXsystems: "read-only imports don't even read space maps"). Стратегия: обойти панику → readonly-импорт → выгрузить данные → пересоздать пул. + +**Пул НЕ «чинится»** — только выгрузка данных и пересоздание. + +## Проверенные шаги (2026-08-17, TrueNAS SCALE 24.10) + +### 1. Загрузка без паники — единственный рабочий способ: + +**Физически отключить все диски проблемного пула** → boot-pool поднимается, паники нет → дошли до shell/WebUI → **воткнуть диски обратно (горячо)** в те же порты. + +**Что НЕ работает (проверено):** +- Тюнабели в GRUB `zfs.zfs_recover=1 zfs.zil_replay_disable=1` — не помогли +- `rd.break=pre-mount` и `rd.break` — не помогли +- `zfsforce=1` — не помогает + +### 2. Readonly-импорт (под root): + +```bash +/usr/sbin/zpool import -o readonly=on RED_2TB +``` +→ `Import was successful, but unable to mount some datasets` — это нормально/ожидаемо. + +### 3. Монтирование datasets вручную (root ФС readonly): + +Ошибка `cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system` — из-за READONLY корневой ФС. Монтируй вручную в записываемую точку: +```bash +zfs list -r RED_2TB # список datasets (работает без mount) +zfs set mountpoint=/mnt/rec RED_2TB # или mount -o +``` + +### 4. Выгрузка: + +```bash +rsync -av --ignore-existing --ignore-errors // <резервный-диск>/ +``` +Лучше в tmux. Затем `zpool destroy` + пересоздать пул. + +## Подводные камни + +- `zpool` не в PATH для zsh-юзеров (`command not found`) — использовать `/sbin/zpool` или `/usr/sbin/zpool`. +- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль. +- `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`). +- **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly. +- `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum). +- Данные могут показать `Permission denied` если сами данные повреждены (в тяжёлых случаях — частичное восстановление). +- **Проверить RAM** — на non-ECC (P8H77-V) повреждение space map часто от плохой памяти. memtest. +- Буквы дисков shift-аются — сверять по by-id/модели, не по буквам. + +## Root cause + +`adding existent segment to range tree` = openzfs #15030 / #13483. Триггер: члены пула отвалились при перетыкании/перезагрузке, либо RAM corruption (non-ECC). From 399ebb9ad4aae0ad2788230059afd36220988215 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 17 Aug 2026 17:24:58 +0600 Subject: [PATCH 08/81] [2026-08-17] eagle: family/how-to/truenas-infrastructure.md family/how-to/truenas-sata-ports-and-zfs-pools.md personal/tech/truenas-zfs-panic-recovery.md --- family/how-to/truenas-infrastructure.md | 8 ++-- .../truenas-sata-ports-and-zfs-pools.md | 40 +++++++++++++------ personal/tech/truenas-zfs-panic-recovery.md | 15 ++++++- 3 files changed, 45 insertions(+), 18 deletions(-) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 7bc5fbf0..4ddf7ae1 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -1,10 +1,10 @@ # TrueNAS — инфраструктура -> Обновлено: 2026-08-17 +> Обновлено: 2026-08-17 (конец сессии) -> ## ⚠️⚠️ КРИТИЧНО (2026-08-17): пул RED_2TB вызывает KERNEL PANIC — все данные/контейнеры/в vault на этом пуле недоступны -> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Этот пул сейчас в дауне — система в kernel panic bootloop из-за повреждённой space map (ошибка `adding existent segment to range tree` при `import -F`). -> **Рецепт восстановления и полная картина — в `family/how-to/truenas-sata-ports-and-zfs-pools.md`** (раздел «Пулы»): тюнабели `zfs.zfs_recover=1 zfs.zil_replay_disable=1` в GRUB, затем аккуратный `zpool import`. ПОКА НЕ РЕШЕНО — инфраструктура, завязанная на `/mnt/RED_2TB`, не работает. +> ## ⚠️⚠️ КРИТИЧНО (2026-08-17): пул RED_2TB — kernel panic, данные НЕ выгружены, нужен root-доступ +> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Пул в kernel panic при rw-импорте (повреждение space map, `adding existent segment to range tree`). **ПОКА НЕ РЕШЕНО.** +> **Статус на конец 2026-08-17:** пан-loop преодолён (загрузка с физически отключёнными дисками пула → readonly-импорт `zpool import -o readonly=on RED_2TB` успешен, паники нет). **НО datasets не смонтированы и данные НЕ выгружены.** Блокер — **нужен root** (truenas_admin не root; sudo просит пароль). Целевой диск для выгрузки: **IronWolf 12TB** подключён (`sdc`). Полный рецепт и картина — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пулы») и `personal/tech/truenas-zfs-panic-recovery.md`. ВАЖНО: тюнабели GRUB (`zfs.zfs_recover` и др.) и `rd.break` НЕ помогли — рабочий способ только «диски отключены при загрузке + readonly-импорт». Инфраструктура на `/mnt/RED_2TB` не работает. ## Доступ diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index c32b9394..f611abd3 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,10 +1,16 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 глубокая ночь (РО: HGST упал и сломан; RED_2TB импортирован READONLY — смонтировать datasets и выгрузить — см. раздел пулов) +> Обновлено: 2026-08-17 (через время после readonly-импорта). СТАТУС: данные RED_2TB ещё НЕ выгружены. IronWolf 12TB подключён как целевой диск для спасения. Блокер: для `zpool import`/`mount` нужен root, а `truenas_admin` не root. HGST сломан (см. ниже). -## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы (данные ещё НЕ выгружены) +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы, данные НЕ выгружены -См. раздел «Пулы TrueNAS» → блок «RED_2TB readonly-импорт». **Прогресс:** пан-loop преодолён (см. рецепт ниже), RD_2TB импортирован readonly успешно. **Осталось смонтировать datasets вручную и выгрузить данные** — точка монтирования не создалась из-за read-only корневой ФС. Это приоритет №1 — данные есть. +Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **Осталось:** смонтировать datasets вручную и выгрузить данные на IronWolf. Это приоритет №1 — данные есть, но пул восстановится только пересозданием, so спасаем. + +**ТЕКУЩИЙ БЛОКЕР (конец сессии):** +- `zpool import`/`mount` требуют **root** (`some devices require root privileges`). `truenas_admin` НЕ root (sudo просит пароль). Все операции с пулом — только под root. +- **Нужно добыть root:** SSH → включить root login (`PermitRootLogin`), или выполнять команды через WebUI-админ/консоль. +- **IronWolf 12TB подключён к материнке** (sdc) как целевой диск для спасения данных. На нём ещё не создан пул-приёмник. +- **WD 2TB#1 (sda2, simplex-член RED_2TB) СЕЙЧАС ОТКЛЮЧЁН** — чтобы загрузиться без паники его отсоединяли; на конец сессии он не в системе. RED_2TB без него может импортироваться, но его данные частично будут недоступны. ## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения @@ -48,11 +54,11 @@ | ata6 (SATA3G_4) | SATA 2 | 3 Gb/s | синий | **sde** — Seagate 4TB (ST4000DM004) | WFN66CM2 | | *(карта ASM1166)* | — | — | — | **НЕ В СЛОТЕ** (вытащена) | — | -**⚠️ Фактическое положение на конец сессии (2026-08-17):** -- **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`) и не относящийся к делу PCIe-to-PCI bridge ASM1083. WD 2TB#2 перенесён с карты на материнку. -- **⭐ IronWolf 12TB теперь ПОДКЛЮЧЁН и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он не в пуле (новый диск). -- **WD 2TB #2 (`WD-WXJ2A31CUNNT`) НАМЕРЕННО отключён** пользователем (2026-08-17). Раньше был `sdb` (перенесён с карты), затем Alex его отключил «это норм». Сейчас отсутствует по замыслу, а не по ошибке. -- **HGST 12TB (`HUH721212ALE600`)** — был подключён по USB (виден как `sdf`, model HGST, WWN `0x5000cca26fefbc05`) и после удара о пол НЕ работает надёжно (см. блок КРИТИЧНО в самом верху). На текущий момент считаем его вышедшим из строя. +**⚠️ Фактическое положение на конец сессии (2026-08-17, после подключения IronWolf для спасения):** +- **Буквы разъехались ещё раз.** Финальный `lsscsi`: **sda=WD4TB**, **sdb=Kingston boot**, **sdc=⭐ IronWolf 12TB (целевой для спасения)**, **sdd=Seagate4TB**. **WD 2TB#1 (`WD-WXH2A31D5HDJ`) СЕЙЧАС ОТКЛЮЧЁН / НЕ в системе** (отсоединяли, чтобы загрузиться без паники). +- **⭐ IronWolf 12TB подключён к материнке и ЛИНКУЕТСЯ** — `sdc` = `ST12000NT001-3LX101`, 10.9T, by-id `WV700FQ5`. Он свободен (не в пуле) и определён как **целевой диск для спасения данных с RED_2TB**. На нём ещё НЕ создан пул-приёмник. +- **Карта ASMedia ASM1166 вытащена** — `lspci` показывает только Intel H77 (`00:1f.2`). WD 2TB#2 перенесён с карты, затем был намеренно отключён пользователем. +- **HGST 12TB (`HUH721212ALE600`)** — УРОНЕН НА ПОЛ, аппаратный отказ (см. блок КРИТИЧНО), считается вышедшим из строя. > ⚠️ Буквы (`sda`/`sdb`) **shift-аются при перетыкании** и сейчас разъехались: `sdb` = WD4TB (не WD2TB#2!), `sdc` = IronWolf. **Всегда сверять по by-id/модели, не полагаться на буквы.** @@ -132,12 +138,12 @@ lspci -k | grep -i sata Имена пулов, топология и члены — проверять статус через `/sbin/zpool` (см. ниже про PATH). -| Пул | Размер | Члены (по /dev со стабильным подключением) | Топология | Монтирование | +| Пул | Размер | Члены (по `/sbin/zpool status` от 2026-08-17) | Топология | Монтирование | |-----|--------|-----------|-----------|--------------| -| **RED_2TB** | 5.44T (4.60T занято) | mirror: `sdb2`/`sdc2` (WD4TB) + `sde2` (Seagate4TB); отдельно `sda2` (WD2TB) | 1 диск (sda2) + mirror-1 (2 диска) | `/mnt` — **⚠️ ПОТРЕБУЕТСЯ IMPORT, см. ниже** | -| **boot-pool** | 111G (7.65G занято) | `sdd3` (Kingston 120GB boot SSD) | 1 диск | — | +| **RED_2TB** | 5.44T (4.60T занято) | **state ONLINE, 0 0 0 ошибок, "No known data errors"**: `sdd2` (WD2TB#1) + mirror-1 `{sdc2 WD4TB, sdb2 Seagate4TB}` — буквы по последнему status, сверять by-id (буквы shift-аются) | 1 диsk (`WD2TB#1`) + mirror-1 (WD4TB+Seagate) | `/mnt` — **readonly-импорт, datasets не смонтированы, данные НЕ выгружены** | +| **boot-pool** | 111G (7.65G занято) | `sdb3` (Kingston 120GB boot SSD) | 1 диск | — | -- RED_2TB: HEALTH **ONLINE**, нераспределённый свободный диск (данные не реплицируются на sda2 — он отдельный, а не парный). Если redun-dancy важна — учесть, что sda2 без зеркала. +- RED_2TB: HEALTH **ONLINE** по `zpool status` (readonly-импорт не паникует), scrub «завис» на ~72% (при readonly не доходит — но это НЕ фикс, см. ниже). Все ошибки 0 0 0 — **данные целы**. Один vdev (`WD2TB#1`) simplex — без зеркала; WD2TB#1 сейчас физически отключён. ### ✅ ПРОГРЕСС (2026-08-17 глубокая ночь): READONLY-импорт УСПЕШЕН, паника преодолена @@ -171,10 +177,18 @@ zfs list -r RED_2TB # какие datasets есть (zfs list работает ``` **Критичные ограничения (выяснены по ходу):** -- `zpool import` требует **root** (`some devices require root privileges`) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root. +- `zpool import` требует **root** (`some devices require root privileges`) — truenas_admin НЕ root (sudo просит пароль). Все операции import/mount — под root. **На конец сессии это главный блокер** — без root не смонтировать/выгрузить. - Раньше при readonly-импорте в тредах было: datasets показываются но пути «not found», и полностью нечитаемы (permission denied) если данные повреждены. Здесь readonly-импорт прошёл чисто (no panic) — но монтирование ещё не доведено до конца. - **Данные на пуле важно выгрузить на другие диски** (пул восстановится только пересозданием — аппаратная метаданная ошибка). Это главный незавершённый шаг. +**🧪 ИТОГ ПО «ПОЧИНИТЬ ПУЛ» (2026-08-17, важно для будущих сессий):** +- **In-place «починки» НЕТ.** По mav (лидер OS-команды iXsystems) в тредах: *"I don't know a way to recover from this situation without data offload and pool recreation"*. Паника на space map не лечится флагами. +- **Опции это НЕ решают:** `zfs.zfs_recover=1`, `zfs.zil_replay_disable=1` (в GRUB), `rd.break=pre-mount`, `rd.break` — все НЕ помогли (паника осталась). Readonly-импорт («doesn't even read space maps») — единственное, что не паникует и даёт доступ к данным. +- **`-F` (восстановление) уже показал панику** в этой сессии (`adding existent segment to range tree`). Повторный `-F` на повреждённом пуле рискован — может углубить повреждение. Не жать вслепую. +- **`zpool attach RED_2TB ` (идея зеркала на 2 WD2TB) НЕ выполнима в текущем состоянии**: attach — это write, он пишет в space maps (обновляет метаданные) → паника. Readonly-импорт не даст attach; переимпорт в rw вернёт панику. Также 2TB не влезет под 4.6T данных целиком. Идея зеркала валидна только ПОСЛЕ пересоздания пула из спасённых данных. +- **Правильная дорога (единственная надёжная):** readonly-импорт → смонтировать datasets вручную → выгрузить данные на целевой пул (IronWolf 12TB) → пересоздать RED_2TB → вернуть данные. Попытки «починить rw» возможны, но только ПОСЛЕ спасения данных и на свой риск. +- **Для «100% восстановления с правами»:** `rsync -aHAX` (права, владельцы, ACL, xattr, хардлинки) или `zfs send | zfs recv` (идеально байт-в-байт со снимками, но требует пула-приёмника и снимка). + > ⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок. **Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. diff --git a/personal/tech/truenas-zfs-panic-recovery.md b/personal/tech/truenas-zfs-panic-recovery.md index c9d5b479..fc042d5f 100644 --- a/personal/tech/truenas-zfs-panic-recovery.md +++ b/personal/tech/truenas-zfs-panic-recovery.md @@ -50,10 +50,23 @@ rsync -av --ignore-existing --ignore-errors // <резервный-дис ``` Лучше в tmux. Затем `zpool destroy` + пересоздать пул. +**Целевой диск для выгрузки (2026-08-17):** **IronWolf 12TB** подключён к материнке (`sdc`, by-id `WV700FQ5`, 10.9T, свободен/не в пуле) — создай на нём пул-приёмник и копируй туда. Места достаточно (10.9T > 4.6T данных). + +**Что на RED_2TB спасать (структура datasets от 2026-08-17):** +- Критично (пользовательские данные): `storage` (3.24T), `backup` (287G), `Photos` (146G), `Edu` (214G), `TimeMachine` (+`guest`, 277G), `old-bu` (65.5G), `openbsd` (10.2G). +- Конфиги (если нужно): `docker` (2.98G), `iocage/*` jails (plex, emby, homeassistant, transmission, worker), `ix-apps` (24G). +- Служебное не критично: `RED_2TB/.system/*`. +- Итого ~4.6T. Для «100% восстановления с правами»: `rsync -aHAX` или `zfs send | zfs recv`. + +### 5. Пул НЕ чинится in-place — только пересоздание + +`zpool attach` (идея зеркала на 2 WD2TB) НЕ выполним в текущем состоянии — attach это write → паника. Всегда: спасти → destroy → recreate. + ## Подводные камни - `zpool` не в PATH для zsh-юзеров (`command not found`) — использовать `/sbin/zpool` или `/usr/sbin/zpool`. -- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль. +- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль. **На конец 2026-08-17 это главный блокер** — для импорта/монтирования/выгрузки нужен root (через WebUI-админ, консоль, или включив `PermitRootLogin` в SSH). +- **WD 2TB#1 (`sdd2` simplex-член RED_2TB) сейчас отключён** — чтобы загрузиться без паники его отсоединяли. RED_2TB импортируется без него (mirror-1 жив), но его данные частично недоступны. Учесть при восстановлении. - `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`). - **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly. - `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum). From 6eecf719145a10e95dfcc0963026ce44d9ec3046 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 18 Aug 2026 11:19:58 +0600 Subject: [PATCH 09/81] [2026-08-18] eagle: family/how-to/truenas-infrastructure.md family/how-to/truenas-sata-ports-and-zfs-pools.md personal/tech/truenas-zfs-panic-recovery.md --- family/how-to/truenas-infrastructure.md | 8 ++--- .../truenas-sata-ports-and-zfs-pools.md | 36 ++++++++++++++++--- personal/tech/truenas-zfs-panic-recovery.md | 17 ++++++--- 3 files changed, 48 insertions(+), 13 deletions(-) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 4ddf7ae1..9d4b0eca 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -1,10 +1,10 @@ # TrueNAS — инфраструктура -> Обновлено: 2026-08-17 (конец сессии) +> Обновлено: 2026-08-18 (datasets смонтированы, выгрузка rsync идёт) -> ## ⚠️⚠️ КРИТИЧНО (2026-08-17): пул RED_2TB — kernel panic, данные НЕ выгружены, нужен root-доступ -> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Пул в kernel panic при rw-импорте (повреждение space map, `adding existent segment to range tree`). **ПОКА НЕ РЕШЕНО.** -> **Статус на конец 2026-08-17:** пан-loop преодолён (загрузка с физически отключёнными дисками пула → readonly-импорт `zpool import -o readonly=on RED_2TB` успешен, паники нет). **НО datasets не смонтированы и данные НЕ выгружены.** Блокер — **нужен root** (truenas_admin не root; sudo просит пароль). Целевой диск для выгрузки: **IronWolf 12TB** подключён (`sdc`). Полный рецепт и картина — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пулы») и `personal/tech/truenas-zfs-panic-recovery.md`. ВАЖНО: тюнабели GRUB (`zfs.zfs_recover` и др.) и `rd.break` НЕ помогли — рабочий способ только «диски отключены при загрузке + readonly-импорт». Инфраструктура на `/mnt/RED_2TB` не работает. +> ## ⚠️⚠️ АКТИВНО (2026-08-18): пул RED_2TB — kernel panic, datasets смонтированы, выгрузка данных rsync на IronWolf +> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Пул в kernel panic при rw-импорте (повреждение space map, `adding existent segment to range tree`). **ПОКА НЕ ВОССТАНОВЛЕНО** — данные в процессе спасения. +> **Статус на 2026-08-18:** пан-loop преодолён (загрузка с физически отключёнными дисками → readonly-импорт `zpool import -o readonly=on RED_2TB` успешен, паники нет). **ПРОГРЕСС: дочерние datasets смонтированы под root** (`zfs mount -a` после `mount -o remount,rw /`) — затем rsync на целевой пул **DEST** (IronWolf 12TB, `/mnt/IRONWOLF`, rw, 10.6T свободно). ⚠️ Первая попытка rsync дала только 355G из-за НЕ смонтированных дочерних datasets — после монтирования перезапущен. **`zfs send|recv` НЕ работает** на этом пуле (signal received / Bad file descriptor). Полный рецепт — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пулы», блок 2026-08-18) и `personal/tech/truenas-zfs-panic-recovery.md`. Инфраструктура на `/mnt/RED_2TB` пока не работает (только спасение данных). ## Доступ diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index f611abd3..1f33d908 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,15 +1,15 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-17 (через время после readonly-импорта). СТАТУС: данные RED_2TB ещё НЕ выгружены. IronWolf 12TB подключён как целевой диск для спасения. Блокер: для `zpool import`/`mount` нужен root, а `truenas_admin` не root. HGST сломан (см. ниже). +> Обновлено: 2026-08-18 (datasets смонтированы под root, rsync перезапущен). СТАТУС: данные RED_2TB на этапе выгрузки на IronWolf — смонтированные дочерние datasets готовы к rsync. IronWolf 12TB = целевой пул `DEST` (rw, 10.6T свободно). HGST сломан (см. ниже). -## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, но datasets не смонтированы, данные НЕ выгружены +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, datasets смонтированы, данные выгружаются rsync -Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **Осталось:** смонтировать datasets вручную и выгрузить данные на IronWolf. Это приоритет №1 — данные есть, но пул восстановится только пересозданием, so спасаем. +Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **ПРОГРЕСС 2026-08-18:** дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) **успешно смонтированы под root** (`zfs mount -a` + при необходимости `mount -o remount,rw /`). Данные видны. Выгрузка на IronWolf идёт **rsync** (см. блок ниже). **ТЕКУЩИЙ БЛОКЕР (конец сессии):** - `zpool import`/`mount` требуют **root** (`some devices require root privileges`). `truenas_admin` НЕ root (sudo просит пароль). Все операции с пулом — только под root. - **Нужно добыть root:** SSH → включить root login (`PermitRootLogin`), или выполнять команды через WebUI-админ/консоль. -- **IronWolf 12TB подключён к материнке** (sdc) как целевой диск для спасения данных. На нём ещё не создан пул-приёмник. +- **IronWolf 12TB подключён к материнке** (sdc) как целевой диск для спасения данных. На нём **создан пул-приёмник `DEST`** (rw, ONLINE, ~10.6T свободно), монтируется на `/mnt/IRONWOLF`. Первая попытка rsync скопировала только 355G (см. блок 2026-08-18 ниже). - **WD 2TB#1 (sda2, simplex-член RED_2TB) СЕЙЧАС ОТКЛЮЧЁН** — чтобы загрузиться без паники его отсоединяли; на конец сессии он не в системе. RED_2TB без него может импортироваться, но его данные частично будут недоступны. ## ⚠️⚠️ ПРОБЛЕМА №2: HGST 12TB УРОНЕН НА ПОЛ — вероятный слом после падения @@ -191,6 +191,34 @@ zfs list -r RED_2TB # какие datasets есть (zfs list работает > ⚠️ После успешного монтирования и выгрузки — обновить таблицу членов пула и закрыть этот блок. +### 🆕 ПРОГРЕСС (2026-08-18): datasets смонтированы под root, выгрузка идёт rsync — НЕ send|recv + +**Смонтирование дочерних datasets — РАБОТАЕТ под root.** Это снимает блокер «datasets не смонтированы» из прошлой сессии: +```bash +mount -o remount,rw / # если корневая ФС readonly мешает создавать mountpoint-ы +zfs mount -a # смонтировать все datasets +# проверить: +df -h /RED_2TB # должно показать ~4.6T, а НЕ 1.1T/362G родительского +ls /RED_2TB/storage | head # должно быть не пусто (Cartoons, Downloads, Movies...) +``` +После `zfs mount -a` в `mount` видны все дочерние datasets на `/RED_2TB/*` (все `ro` — readonly, для чтения rsync это норм). + +**⚠️ СМОНТИРОВАТЬ datasets под `truenas_admin` НЕЛЬЗЯ** — `zfs mount -a` даёт `Insufficient privileges`. Монтирование и выгрузка — только **под root**. + +**🐛 Причина «только 355G» на первой выгрузке rsync (разгадана):** первая попытка `rsync /RED_2TB/ /mnt/IRONWOLF/` запускалась, когда **дочерние datasets НЕ были смонтированы**, поэтому `/RED_2TB/storage` (3.24T), `/RED_2TB/backup` (287G) и т.д. были **пустыми mountpoint-дирами**. rsync скопировал только ~355G, лежащих прямо в родительском dataset `RED_2TB` (REFER 362G: `.DS_Store`, `dedupe_rm.sh`, `files.txt.xz`, `docker.bak`, `system`, `immich-photos-upload`). **rsync не сломался — ему просто нечего было копировать из не смонтированных дочерних datasets.** После монтирования данных стало ~4.6T — rsync перезапущен. + +**❌ `zfs send | zfs recv` НЕ работает на повреждённом пуле — использовать rsync:** при `zfs send RED_2TB/storage | zfs recv DEST/storage` (под root) recv падает с `signal received` / `Bad file descriptor` / `IOT instruction (core dumped)`, exit 1. ZFS не может прочитать данные/метаданные из пула с повреждённой space map на лету при stream-чтении. **rsync — правильный и единственный надёжный способ** (переживает ошибки чтения отдельных файлов, exit 23, копирует остальное). + +**⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send:** под `truenas_admin` `zfs send -n RED_2TB/docker` возвращал **exit 0 без ошибок** — это ОБМАНЧИВО. Реальный `zfs send` (без `-n`) даёт `warning: cannot send 'RED_2TB/docker': permission denied`. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send. + +**Команды выгрузки (под root):** +```bash +rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 & +# прогресс: +while true; do clear; date +%H:%M:%S; du -sh /mnt/IRONWOLF/; tail -3 /tmp/rsync2.log; pgrep -a rsync >/dev/null && echo RUNNING || echo DONE; sleep 15; done +``` +**Итог выгрузки:** после монтирования datasets и перезапуска rsync должны лечь все ~4.6T (storage, backup, Edu, Photos, TimeMachine/guest, old-bu, docker...). После завершения — сверка `du -sh /mnt/IRONWOLF/` vs `zfs list RED_2TB` и обновить таблицу членов пула. + **Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. diff --git a/personal/tech/truenas-zfs-panic-recovery.md b/personal/tech/truenas-zfs-panic-recovery.md index fc042d5f..9ec6f3c5 100644 --- a/personal/tech/truenas-zfs-panic-recovery.md +++ b/personal/tech/truenas-zfs-panic-recovery.md @@ -35,21 +35,27 @@ panic - not syncing: zfs: adding existent segment to range tree ``` → `Import was successful, but unable to mount some datasets` — это нормально/ожидаемо. -### 3. Монтирование datasets вручную (root ФС readonly): +### 3. Монтирование datasets (2026-08-18: подтверждено под root) -Ошибка `cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system` — из-за READONLY корневой ФС. Монтируй вручную в записываемую точку: +Если корневая ФС readonly мешает создавать mountpoint-ы (`cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system`) — сначала сделать root ФС rw, затем смонтировать всё: ```bash -zfs list -r RED_2TB # список datasets (работает без mount) -zfs set mountpoint=/mnt/rec RED_2TB # или mount -o +mount -o remount,rw / +zfs mount -a ``` +После этого дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) видны на `/RED_2TB/*` (все `ro` — readonly; для чтения rsync это ок). Проверка: `df -h /RED_2TB` покажет ~4.6T (НЕ 1.1T родительского), `ls /RED_2TB/storage` не пуст. +> ⚠️ Монтирование — **только под root**. Под `truenas_admin` `zfs mount -a` даёт `Insufficient privileges`. ### 4. Выгрузка: ```bash -rsync -av --ignore-existing --ignore-errors // <резервный-диск>/ +rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 & ``` Лучше в tmux. Затем `zpool destroy` + пересоздать пул. +**⚠️ ВАЖНО (2026-08-18): использовать именно `rsync`, НЕ `zfs send | zfs recv`.** `zfs send` на пуле с повреждённой space map падает (`signal received` / `Bad file descriptor` / `IOT (core dumped)`, exit 1) — ZFS не может прочитать данные на лету при stream-чтении. rsync переживает ошибки чтения отдельных файлов (exit 23) и копирует остальное. + +**⚠️ Почему первая попытка rsync дала только 355G (разгадано 2026-08-18):** дочерние datasets НЕ были смонтированы, поэтому `/RED_2TB/storage` и др. были пустыми mountpoint-дирами; rsync скопировал только ~355G из родительского dataset. **Сначала смонтировать datasets (`zfs mount -a`), потом rsync** — иначе скопируется лишь несколько сотен ГБ. + **Целевой диск для выгрузки (2026-08-17):** **IronWolf 12TB** подключён к материнке (`sdc`, by-id `WV700FQ5`, 10.9T, свободен/не в пуле) — создай на нём пул-приёмник и копируй туда. Места достаточно (10.9T > 4.6T данных). **Что на RED_2TB спасать (структура datasets от 2026-08-17):** @@ -70,6 +76,7 @@ rsync -av --ignore-existing --ignore-errors // <резервный-дис - `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`). - **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly. - `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum). +- **⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send:** под `truenas_admin` `zfs send -n` возвращал exit 0 без ошибок — обманчиво. Реальный `zfs send` даёт `permission denied`. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send. - Данные могут показать `Permission denied` если сами данные повреждены (в тяжёлых случаях — частичное восстановление). - **Проверить RAM** — на non-ECC (P8H77-V) повреждение space map часто от плохой памяти. memtest. - Буквы дисков shift-аются — сверять по by-id/модели, не по буквам. From 1d621faa59bcf48395ccac4b95dac82e3dafe7b3 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Thu, 20 Aug 2026 10:58:17 +0600 Subject: [PATCH 10/81] [2026-08-20] eagle: family/how-to/red2tb-dataset-map.md --- family/how-to/red2tb-dataset-map.md | 70 +++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 family/how-to/red2tb-dataset-map.md diff --git a/family/how-to/red2tb-dataset-map.md b/family/how-to/red2tb-dataset-map.md new file mode 100644 index 00000000..dcf5e871 --- /dev/null +++ b/family/how-to/red2tb-dataset-map.md @@ -0,0 +1,70 @@ +# RED_2TB — карта датасетов и назначений (для решения о пересоздании пула) + +> Собрано: 2026-08-20 (Ель — Кит). Источник: live-данные `zfs list` + `ls` с TrueNAS (readonly-импорт). +> НАЗНАЧЕНИЕ: решить, воссоздавать ли карту датасетов как есть, или что-то поменять/добавить/убрать перед пересозданием пула RED_2TB. +> Ничего не изменялось — только сбор информации. + +## Статус спасения на 2026-08-20 + +- **DEST (IronWolf 12TB, /mnt/IRONWOLF)**: 4.56T из 10.9T занято — данные уже выгружены rsync. +- **RED_2TB**: 4.61T занято, readonly-импорт. Все datasets видны и смонтированы. +- Идёт **проверочный rsync** (`ir-chk` на ~1.8 млн файлов) — сверка, а не первая передача. +- После проверки и сверки `du` — ПЕРЕСОЗДАНИЕ пула и возврат данных. + +## Общая сводка + +- Пул: RED_2TB, 5.44T (4.61T занято), компрессия lz4, рекордсайз 128K, acltype nfsv4, atime=on, exec=on. +- Квот/резерваций НЕТ ни на одном датасете (все `none`). +- Монтинг: датасеты в `/RED_2TB/*`, служебные `.system`/`ix-apps` в `legacy`/`/.ix-apps`. + +## ✅ Датасеты (воссоздавать как ZFS datasets) + +| Датасет | USED | REFER | Назначение | Примечание | +|---------|------|-------|-----------|------------| +| **storage** | 3.24T | 3.24T | Общее хранилище мультимедиа и файлов | Подкаталоги: Cartoons, Downloads, Edu, Movies, Music, ada3s1, art, books, cartoons-series, documentaries(-series), git, nas(пусто), obsidian, obsidian-syncthing, photo_dedup_test, radarr, seafile, series, shared, singularity, sonarr, work. `git/` = hermes-taiga.git, obsidian-vault.git | +| **backup** | 287G | 287G | Резервные копии (личные доки, коды, VM, пароли, браузеры) | Много семейных документов (договоры, справки), Google Keep/Play, VPN, Virtual Machines, accessKeys.csv, lastpass_export.zip, коды восстановления. | +| **TimeMachine/guest** | 277G | 267G | Бэкапы macOS (Time Machine) | Родитель TimeMachine 277G/96K; дочерний `guest` несёт данные. Много снимков `aapltm-*`. | +| **Edu** | 214G | 214G | Учебные материалы | | +| **Photos** | 146G | 146G | Фотографии | | +| **old-bu** | 65.5G | 65.5G | Старый семейный архив фото/видео | Фото 2009–2010+, свадьбы, семейные события (папки вида `09-01-01 Новый 2009 год!`). | +| **ix-apps** | 24.0G | - | Системный — TrueNAS Apps (docker 23.6G, truenas_catalog 385M) | Воссоздаётся самой TrueNAS, не вручную. | +| **iocage** | 15.4G | 9.19M | Jail-ы TrueNAS | Jails: backuppc, emby, homeassistant, plex, transmission, worker + releases 11.2/12.2/12.3, images, download, templates. | +| **openbsd** | 10.2G | 4.43M | ?? неясно — refer всего 4.43M при used 10.2G | Вероятно remnants после снимка/пробного пула. Решить: нужен ли вообще. | +| **docker** | 2.98G | 2.98G | Живой docker-конфиг (текущие контейнеры) | | +| **apps** | 192K | 96K | Точка для app-конфигов | Дочерний `apps/homeassistant-config` (96K). | +| **.system/** | 568M | - | Служебное TrueNAS (configs, netdata, rrd, samba4, syslog...) | Воссоздаётся самой системой, не создавать руками. | + +## ⚠️ Данные ВНЕ датасетов — лежат прямо в корне `RED_2TB` (REFER 362G) + +Эти пути НЕ являются ZFS-datasets (их нет в `zfs list`) — при пересоздании пула их надо решать отдельно, иначе потеряются (или перепутаются с содержимым корневого датасета): + +| Путь | Содержимое | Важность | +|------|-----------|----------| +| `/RED_2TB/system/` | SSH-туннель: `tunnel.sh`, `tunnel_key` (приватный!), `tunnel_key.pub`, `99-tty-alias.rules`. Владелец root, режим 600/644. | ⚠️ **КРИТИЧНО** — рабочий туннель TrueNAS. root-only. | +| `/RED_2TB/docker.bak/` | Бэкап конфигов docker: caddy, cups, filebrowser, ha, hermes, homeassistant, immich, inpx-web, inpxer, mbusd, modbus-bridge, mosquitto, nodered, portainer, python, rclone, ser2net | Архив/бэкап контейнеров. `hermes/` = бэкап Hermes-агента. | +| `/RED_2TB/immich-photos-upload/` | Конфиг Immich: backups, encoded-video, library, profile, thumbs, upload | Рабочий Immich (он же в docker). | +| Корневые файлы | `.DS_Store`, `._.DS_Store` (мусор mac), `dedupe_rm.sh`, `files.txt.xz` (содержимое old-bu/somo?) | dedupe_rm.sh — скрипт дедупликации, файловый список. | + +## 🤔 Метки для решения + +Вопросы, которые надо решить ПЕРЕД пересозданием: + +1. **openbsd (10.2G/4.43M)** — судя по refer почти пуст. Что это? Удалить из map? +2. **Внутри storage/ есть `Edu`** — это ДУБЛЬ датасета `Edu`? Проверить: возможно медиа-папка Edu в storage vs отдельный датасет Edu для учебных. +3. **`nas` внутри storage пуст**. +4. **`TimeMachine`** (277G) — вернуть ли отдельным датасетом как было, с дочерним `guest`? +5. **`docker` vs `docker.bak`** — оба сохранить? `docker` = живой, `docker.bak` = архив. +6. **`immich-photos-upload`** — оставить в корне пула (вне датасета) или завести отдельный датасет? +7. **Внедатасетные каталоги** (`system`, `docker.bak`, `immich-photos-upload`) — после пересоздания они окажутся в корневом dataset RED_2TB (REFER 362G). Решить, оставить их там или разнести по датасетам. + +## Ключевые решения по подходу к пересозданию (из truenas-sata-ports-and-zfs-pools.md) + +- In-place починки НЕТ (битая space map, паника на rw). +- Рабочий путь: readonly-импорт → выгрузка rsync → `zpool destroy`+`create` → возврат данных rsync. +- НЕ использовать `zfs send|recv` (падает на повреждённом пуле). Только rsync. +- После пересоздания можно добавить WD2TB#2 зеркалом к WD2TB#1 (сейчас simplex, без защиты). +- `zpool import`/`mount`/destroy/create — ТОЛЬКО под root (truenas_admin не root). + +## Ссылки + +- Связанные: [[truenas-sata-ports-and-zfs-pools]] (план спасения/пересоздания), [[truenas-access]] (общие данные доступа). From 5c67fc2139b473e1559a2f27d4397853d80c623d Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Fri, 21 Aug 2026 12:07:04 +0600 Subject: [PATCH 11/81] [2026-08-21] eagle: family/how-to/red2tb-dataset-map.md family/how-to/truenas-infrastructure.md family/how-to/truenas-sata-ports-and-zfs-pools.md --- family/how-to/red2tb-dataset-map.md | 14 ++-- family/how-to/truenas-infrastructure.md | 9 +-- .../truenas-sata-ports-and-zfs-pools.md | 72 ++++++++++++++++++- 3 files changed, 83 insertions(+), 12 deletions(-) diff --git a/family/how-to/red2tb-dataset-map.md b/family/how-to/red2tb-dataset-map.md index dcf5e871..8d597fcd 100644 --- a/family/how-to/red2tb-dataset-map.md +++ b/family/how-to/red2tb-dataset-map.md @@ -4,12 +4,13 @@ > НАЗНАЧЕНИЕ: решить, воссоздавать ли карту датасетов как есть, или что-то поменять/добавить/убрать перед пересозданием пула RED_2TB. > Ничего не изменялось — только сбор информации. -## Статус спасения на 2026-08-20 +## Статус спасения на 2026-08-21 -- **DEST (IronWolf 12TB, /mnt/IRONWOLF)**: 4.56T из 10.9T занято — данные уже выгружены rsync. -- **RED_2TB**: 4.61T занято, readonly-импорт. Все datasets видны и смонтированы. -- Идёт **проверочный rsync** (`ir-chk` на ~1.8 млн файлов) — сверка, а не первая передача. -- После проверки и сверки `du` — ПЕРЕСОЗДАНИЕ пула и возврат данных. +- **Выгрузка ЗАВЕРШЕНА УСПЕШНО** (подтверждено Alex). Данные RED_2TB (4.56T) на IronWolf — `DEST`, `/mnt/IRONWOLF`. +- **RED_2TB пул — OFFLINE** в БД TrueNAS (id=1), НЕ импортирован. `zpool export` → `no such pool`. +- Проверочный rsync прогон завершён (rsync не запущен). +- **РЕШЕНИЕ:** пересоздаём пул с новой топологией — ВКЛЮЧАЕМ WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc). Итог: `mirror {sdc,sdf}` + `mirror {sde,sdd}`. +- Следующий шаг: `zpool labelclear` по разделам `*2` + `zpool create` (подробно в [[truenas-sata-ports-and-zfs-pools]] → «Пересоздание пула 2026-08-21»). ## Общая сводка @@ -62,8 +63,9 @@ - In-place починки НЕТ (битая space map, паника на rw). - Рабочий путь: readonly-импорт → выгрузка rsync → `zpool destroy`+`create` → возврат данных rsync. - НЕ использовать `zfs send|recv` (падает на повреждённом пуле). Только rsync. -- После пересоздания можно добавить WD2TB#2 зеркалом к WD2TB#1 (сейчас simplex, без защиты). +- **РЕШЕНО (2026-08-21):** включить WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc) при пересоздании. Топология `mirror {sdc,sdf}` + `mirror {sde,sdd}` — оба зеркалированы. - `zpool import`/`mount`/destroy/create — ТОЛЬКО под root (truenas_admin не root). +- **НИКОГДА не импортировать RED_2TB в rw** (kernel panic). Только `labelclear` + `create`. ## Ссылки diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 9d4b0eca..89188315 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -1,10 +1,11 @@ # TrueNAS — инфраструктура -> Обновлено: 2026-08-18 (datasets смонтированы, выгрузка rsync идёт) +> Обновлено: 2026-08-21 (данные спасены на IronWolf, пул RED_2TB OFFLINE, готовность к пересозданию) -> ## ⚠️⚠️ АКТИВНО (2026-08-18): пул RED_2TB — kernel panic, datasets смонтированы, выгрузка данных rsync на IronWolf -> **RED_2TB — это НЕ просто хранилище: на нём лежат конфиги docker (caddy, transmission, Home Assistant `/mnt/RED_2TB/docker/*`), данные Transmission/Arr, сам Obsidian vault и его git-репо (`/mnt/RED_2TB/storage/obsidian`, `/mnt/RED_2TB/storage/git/obsidian-vault.git`).** Пул в kernel panic при rw-импорте (повреждение space map, `adding existent segment to range tree`). **ПОКА НЕ ВОССТАНОВЛЕНО** — данные в процессе спасения. -> **Статус на 2026-08-18:** пан-loop преодолён (загрузка с физически отключёнными дисками → readonly-импорт `zpool import -o readonly=on RED_2TB` успешен, паники нет). **ПРОГРЕСС: дочерние datasets смонтированы под root** (`zfs mount -a` после `mount -o remount,rw /`) — затем rsync на целевой пул **DEST** (IronWolf 12TB, `/mnt/IRONWOLF`, rw, 10.6T свободно). ⚠️ Первая попытка rsync дала только 355G из-за НЕ смонтированных дочерних datasets — после монтирования перезапущен. **`zfs send|recv` НЕ работает** на этом пуле (signal received / Bad file descriptor). Полный рецепт — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пулы», блок 2026-08-18) и `personal/tech/truenas-zfs-panic-recovery.md`. Инфраструктура на `/mnt/RED_2TB` пока не работает (только спасение данных). +> ## ⚠️ СТАТУС на 2026-08-21: пул RED_2TB — данные СПАСЕНЫ, пул OFFLINE, пересоздаём +> **Выгрузка успешно завершена** (подтверждено Alex): данные RED_2TB (4.56T) на IronWolf (пул `DEST`, `/mnt/IRONWOLF`). **Пул RED_2TB — статус OFFLINE** в БД TrueNAS, НЕ импортирован. Конфиги docker (caddy, transmission, HA, immich и т.д.), Obsidian vault и git-репо спасены на `/mnt/IRONWOLF` (`system/`, `docker.bak/`, `docker/`, `storage/obsidian`, `storage/git`). +> **ПЛАН (следующий шаг):** пересоздать пул RED_2TB с новой топологией `mirror {sdc,sdf}` + `mirror {sde,sdd}` (включаем WD2TB#2 зеркалом к WD2TB#1). Команды `zpool labelclear` + `zpool create` — в `family/how-to/truenas-sata-ports-and-zfs-pools.md` (раздел «Пересоздание пула 2026-08-21»). Затем вернуть данные rsync с IronWolf и восстановить инфраструктуру. +> **ПРОТОКОЛ ПОВРЕЖДЕНИЯ (история):** пул паниковал на rw-импорте (`adding existent segment to range tree`, повреждённая space map). Работал только `zpool import -o readonly=on`. In-place починки нет (mav/iXsystems) — только спасать данные и пересоздавать. Полный рецепт — в `family/how-to/truenas-sata-ports-and-zfs-pools.md`. ## Доступ diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 1f33d908..10c0f12d 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -1,8 +1,28 @@ # TrueNAS — SATA порты и пулы -> Обновлено: 2026-08-18 (datasets смонтированы под root, rsync перезапущен). СТАТУС: данные RED_2TB на этапе выгрузки на IronWolf — смонтированные дочерние datasets готовы к rsync. IronWolf 12TB = целевой пул `DEST` (rw, 10.6T свободно). HGST сломан (см. ниже). +> Обновлено: 2026-08-21 (данные спасены, пул RED_2TB OFFLINE, готовность к пересозданию). СТАТУС: выгрузка данных на IronWolf **завершена успешно** (4.56T на `/mnt/IRONWOLF`, подтверждено Alex). Пул RED_2TB **OFFLINE** (не импортирован), диски физически на месте. Идёт подготовка к пересозданию пула с новой топологией (добавляем WD2TB#2 зеркалом к WD2TB#1). HGST сломан (см. ниже). -## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1: пул RED_2TB импортирован READONLY, datasets смонтированы, данные выгружаются rsync +## ✅ РЕШЕНО (2026-08-21): пул RED_2TB — данные спасены, пул OFFLINE, готовность к пересозданию + +**ВЫГРУЗКА ДАННЫХ ЗАВЕРШЕНА УСПЕШНО.** Alex подтвердил: «операция завершилась успешно, ничего не было перезаписано». Данные RED_2TB (4.56T) лежат на IronWolf 12TB — пул `DEST`, `/mnt/IRONWOLF`. Ключевые конфиги подтверждены на `/mnt/IRONWOLF`: `system/tunnel.sh`+`tunnel_key`+`.pub` (критичный SSH-туннель), `docker.bak/` (309M), `docker/` (1.1G), `immich-photos-upload`, `dedupe_rm.sh`, `files.txt.xz`. `storage/obsidian` и `storage/git` существуют (Permission denied для `truenas_admin` из-за NFSv4 ACL, transmission-owner — это нормально, НЕ потеря). + +**Текущее состояние (2026-08-21, live-проверка):** +- **RED_2TB пул — статус OFFLINE** в БД TrueNAS (`midclt call pool.query` → `id=1, guid 3817880812699166755`), пул **НЕ импортирован**. `zpool export RED_2TB` → `no such pool` (уже выгружен/не в активном контексте). +- `zpool import -d /dev` всё ещё **видит** RED_2TB как **ONLINE** импортируемый, члены: `sdc2` (simplex WD2TB#1) + `mirror-1 {sde2 WD4TB, sdd2 Seagate4TB}`. +- rsync не запущен — проверочный прогон завершён. +- Диски физически на месте (by-id, см. таблицу портов ниже). + +**Актуальная раскладка дисков (2026-08-21, по `/dev/disk/by-id`, стабильные имена):** +| Диск | by-id/model | Роль | +|------|------------|------| +| sda | `ata-KINGSTON_SA400S37120G_50026B77844E881C` | Boot SSD (не трогать) | +| sdb | `ata-ST12000NT001-3LX101_WV700FQ5` | ⭐ IronWolf 12TB = DEST, `/mnt/IRONWOLF` (целевой, данные выгружены) | +| sdc | `ata-WDC_WD20EFAX-68B2RN1_WD-WXH2A31D5HDJ` | **WD2TB#1** (исходный simplex-член RED_2TB) | +| sdd | `ata-ST4000DM004-2CV104_WFN66CM2` | **Seagate4TB** (mirror-1 второй член) | +| sde | `ata-WDC_WD40EZAZ-00SF3B0_WD-WX22D51JJFZ7` | **WD4TB** (mirror-1 первый член) | +| sdf | `ata-WDC_WD20EFAX-68B2RN1_WD-WXJ2A31CUNNT` | **WD2TB#2** (доп., НЕ в исходном пуле) | + +## ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №1 (ЗАКРЫТО, история): пул RED_2TB импортирован READONLY, данные выгружались rsync Пан-loop преодолён (рецепт ниже). RED_2TB импортирован readonly удачно — **паники больше нет**. **ПРОГРЕСС 2026-08-18:** дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) **успешно смонтированы под root** (`zfs mount -a` + при необходимости `mount -o remount,rw /`). Данные видны. Выгрузка на IronWolf идёт **rsync** (см. блок ниже). @@ -221,6 +241,54 @@ while true; do clear; date +%H:%M:%S; du -sh /mnt/IRONWOLF/; tail -3 /tmp/rsync2 **Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. +### 🆕 ПЕРЕСОЗДАНИЕ ПУЛА (2026-08-21) — план и команды + +**Решение (подтверждено Alex):** пересоздаём RED_2TB с **новой топологией — ВКЛЮЧАЕМ WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc)**. В итоге: `mirror {sdc, sdf}` + `mirror {sde, sdd}` — оба исходных simplex-члена получают зеркала (ранее WD2TB#1 был simplex без защиты). + +**Записи TrueNAS, которые важно знать (2026-08-21):** +- `midclt call pool.query` → `id=1, name=RED_2TB, status=OFFLINE`, `topology:null`. Устаревшая запись в БД. +- **`midclt call pool.delete 1` НЕ существует** в этом билде (`'PoolService' object has no attribute 'do_delete'`) — запись через API не удалить. Пользоваться командной строкой `zpool` (root) или UI. +- `zpool labelclear -f` **принимает только ОДИН vdev за раз** — «too many arguments» при передаче нескольких дисков. + +**Команды пересоздания (под root, на консоли TrueNAS):** +```bash +# 1. Стереть старые метки ZFS с ПАРТИЦИЙ (пул был построен на разделах *2, НЕ на целых дисках!) +zpool labelclear -f /dev/sdc2 +zpool labelclear -f /dev/sdf2 +zpool labelclear -f /dev/sde2 +zpool labelclear -f /dev/sdd2 + +# 2. Проверить, что RED_2TB исчез из импортируемых +zpool import -d /dev + +# 3. Создать пул заново на ЦЕЛЫХ дисках (TrueNAS создаст свои разделы *2) +zpool create RED_2TB mirror /dev/sdc /dev/sdf mirror /dev/sde /dev/sdd + +# 4. Проверить +zpool status RED_2TB +zpool list RED_2TB +``` + +**⚠️ КРИТИЧЕСКИЕ ЛОВУШКИ labelclear (из openzfs issues #18027, #3156, #14869):** +- **Целиться надо в ПАРТИЦИИ (`*2`), а не в целый диск.** TrueNAS строит пулы на разделах `...2`. `zpool labelclear -f /dev/sdc` (целый диск) даёт `failed to clear label for /dev/sdc` — метки лежат внутри раздела `sdc2`, на целом диске их «не видит» целиком. +- **`failed to clear label` также выводится, когда метки УЖЕ стёрты** (issue #18027) — не обязательно ошибка. Если после `labelclear` `zpool import -d /dev` не показывает RED_2TB — значит метки стёрты, всё ок. +- `labelclear` сам по себе может не стереть оба набора меток (`#14869`), если чистить не ту цель — поэтому чистить по разделам, которые реально добавлялись. + +**🧭 НОВАЯ ТОПОЛОГИЯ ПОСЛЕ ПЕРЕСОЗДАНИЯ:** +| vdev | Члены | Назначение | +|------|-------|-----------| +| mirror-0 | sdc (WD2TB#1) + sdf (WD2TB#2) | Пара WD 2TB (зеркалирование) | +| mirror-1 | sde (WD4TB) + sdd (Seagate4TB) | Пара 4TB (зеркалирование) | + +**После создания пула — НЕ забыть:** +- пересоздать datasets по [[red2tb-dataset-map]] (storage, backup, Photos, Edu, TimeMachine/guest, docker, old-bu, iocage; `.system`/`ix-apps` TrueNAS создаст сама); +- решить судьбу данных ВНЕ датасетов (`system/`, `docker.bak/`, `immich-photos-upload/`, корневые файлы) — после пересоздания окажутся в корневом dataset; +- вернуть данные: `rsync -aHAX /mnt/IRONWOLF/ /RED_2TB/`; +- восстановить инфраструктуру (docker: caddy, transmission, HA, immich...), доступы, cron-бэкапы, Obsidian sync. + +## ⚠️ НЕ ВХОДИТЬ В RW-ИМПОРТ ПОВРЕЖДЁННоГО ПУЛА +**Импорт RED_2TB в не-readonly режиме (`zpool import` без `-o readonly=on`) — ВСЕГДА даёт kernel panic** (`zfs: adding existent segment to range tree`). Это правило подтверждено много раз. При пересоздании пул НЕ импортировать — только стереть метки (`labelclear`) и создать заново. `zpool import -d /dev` (dry-list) безопасен, но не запускает пул. + - Идёт регулярный scrub (запускается ночью воскресенья). From b765e7ecb66750b20728dd915fbae8c56a79f6e6 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Fri, 21 Aug 2026 12:17:08 +0600 Subject: [PATCH 12/81] [2026-08-21] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- family/how-to/truenas-sata-ports-and-zfs-pools.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 10c0f12d..7e478f23 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -241,10 +241,12 @@ while true; do clear; date +%H:%M:%S; du -sh /mnt/IRONWOLF/; tail -3 /tmp/rsync2 **Опция добавить WD2TB#2 как зеркало к WD2TB#1** (`zpool attach RED_2TB `): валидна, но ТОЛЬКО после успешного импорта пула и его стабилизации. Не пытаться до восстановления. -### 🆕 ПЕРЕСОЗДАНИЕ ПУЛА (2026-08-21) — план и команды +### ✅ ПЕРЕСОЗДАНИЕ ПУЛА (2026-08-21) — ВЫПОЛНЕНО **Решение (подтверждено Alex):** пересоздаём RED_2TB с **новой топологией — ВКЛЮЧАЕМ WD2TB#2 (sdf) зеркалом к WD2TB#1 (sdc)**. В итоге: `mirror {sdc, sdf}` + `mirror {sde, sdd}` — оба исходных simplex-члена получают зеркала (ранее WD2TB#1 был simplex без защиты). +**✅ СТАТУС (2026-08-21, live): пул СОЗДАН успешно.** `zpool create RED_2TB mirror /dev/sdc /dev/sdf mirror /dev/sde /dev/sdd` → `state: ONLINE, 0 0 0 ошибок, No known data errors`, `SIZE 5.44T, ALLOC 384K, HEALTH ONLINE`. Пул пустой (данные ещё возвращаются). + **Записи TrueNAS, которые важно знать (2026-08-21):** - `midclt call pool.query` → `id=1, name=RED_2TB, status=OFFLINE`, `topology:null`. Устаревшая запись в БД. - **`midclt call pool.delete 1` НЕ существует** в этом билде (`'PoolService' object has no attribute 'do_delete'`) — запись через API не удалить. Пользоваться командной строкой `zpool` (root) или UI. From d3dadb59259766b1de12319ff5079aaf239addfa Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 10:55:25 +0600 Subject: [PATCH 13/81] [2026-08-24] eagle: personal/business/rf-tax-residency.md --- personal/business/rf-tax-residency.md | 77 +++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 personal/business/rf-tax-residency.md diff --git a/personal/business/rf-tax-residency.md b/personal/business/rf-tax-residency.md new file mode 100644 index 00000000..983fc853 --- /dev/null +++ b/personal/business/rf-tax-residency.md @@ -0,0 +1,77 @@ +--- +tags: + - tax + - russia + - residency +created: '2026-08-24' +--- +# Налоговая резиденция РФ — статус и план + +## Контекст + +- ИП в Кыргызстане, доход от иностранных IT-клиентов +- Живу в Бишкеке, гражданин РФ +- Цель: **не становиться налоговым резидентом РФ** (порог — 183 дня в любые 12 последовательных месяцев) +- Пока нерезидент — доход от КР-ИП РФ не касается + +--- + +## Въезды/выезды в РФ + +| Период | Дней | +| ----------------------- | ------- | +| 29.11.2025 → 14.03.2026 | 106 | +| 04.07.2026 → 15.08.2026 | 43 | +| 29.11.2026 → ? | считаем | + +--- + +## Подсчёт скользящего окна + +### На дату приезда 29.11.2026 + +Окно 29.11.2025 → 28.11.2026: +- 29.11.25 → 14.03.26 = **106 дней** +- 04.07.26 → 15.08.26 = **43 дня** +- **Итого: 149 дней** (запас: 34 дня до 183) + +### Динамика окна при пребывании с 29.11.2026 + +- **Декабрь 2026:** каждый день +1 новый, −1 декабрь 2025 (был в РФ) → **счётчик не растёт**, стоит на 149 +- **Январь 2027:** каждый день +1 новый, −1 январь 2026 (был в РФ) → **счётчик не растёт** +- **Февраль 2027:** аналогично февраль 2026 был в РФ → **счётчик не растёт** +- **С 15.03.2027:** из окна начинают выпадать дни после 14.03.2026 (КР, не РФ) → каждый день в РФ даёт **чистый +1** + +### Итог по поездке с 29.11.2026 + +| Период в РФ | Счётчик | +|---|---| +| 29.11.26 → 14.03.27 | остаётся ~149 | +| С 15.03.27 | растёт: +1/день | +| Лимит исчерпан (~17.04.27) | 183 — нужно выехать | + +--- + +## Риски и что отслеживать + +- ФНС планирует автоматическое определение резидентства по загранпаспорту (данные о въездах/выездах) — статус инициативы неясен +- Для стран ЕАЭС (КР, Армения, Казахстан) граница по внутреннему паспорту не фиксируется автоматически — но это может измениться +- При смешанном резидентстве (РФ + КР одновременно по 183+ дней) применяется СИДН РФ–КР (соглашение от 13.01.1999) + +--- + +## СИДН РФ–КР (на случай если всё же стану резидентом РФ) + +1. Получить **сертификат налогового резидентства КР** (ГНС Кыргызстана) +2. Подать **3-НДФЛ** в РФ, указать доход от КР-ИП, сослаться на СИДН (ст. 7 — предпринимательская деятельность) +3. Приложить: сертификат резидентства КР, квитанции об уплате налога в КР, контракты +4. Налог уплаченный в КР засчитывается — доплачивается только разница (КР ~4–6%, РФ 13%) + +--- + +## Вывод / план + +- **Сейчас:** нерезидент РФ, всё чисто +- **Поездка 29.11.2026:** можно сидеть до ~середины марта 2027 без роста счётчика +- **Март 2027:** выехать до ~17.04.2027 чтобы не пробить 183 +- **Принцип:** ноябрь–февраль в РФ безопасны пока предыдущий год был аналогичным; март — точка слежения From 117dae471cf3d44c8ceaea0e08e534c9a187455b Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 11:00:27 +0600 Subject: [PATCH 14/81] [2026-08-24] eagle: personal/business/rf-tax-residency.md --- personal/business/rf-tax-residency.md | 30 ++++++++++++--------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/personal/business/rf-tax-residency.md b/personal/business/rf-tax-residency.md index 983fc853..7c349eec 100644 --- a/personal/business/rf-tax-residency.md +++ b/personal/business/rf-tax-residency.md @@ -1,9 +1,10 @@ --- +created: '2026-08-24' +updated: '2026-08-24' tags: - tax - russia - residency -created: '2026-08-24' --- # Налоговая резиденция РФ — статус и план @@ -21,7 +22,7 @@ created: '2026-08-24' | Период | Дней | | ----------------------- | ------- | | 29.11.2025 → 14.03.2026 | 106 | -| 04.07.2026 → 15.08.2026 | 43 | +| 04.07.2026 → 12.09.2026 | 71 | | 29.11.2026 → ? | считаем | --- @@ -32,23 +33,19 @@ created: '2026-08-24' Окно 29.11.2025 → 28.11.2026: - 29.11.25 → 14.03.26 = **106 дней** -- 04.07.26 → 15.08.26 = **43 дня** -- **Итого: 149 дней** (запас: 34 дня до 183) +- 04.07.26 → 12.09.26 = **71 день** +- **Итого: 177 дней** (запас: всего **6 дней** до 183) ### Динамика окна при пребывании с 29.11.2026 -- **Декабрь 2026:** каждый день +1 новый, −1 декабрь 2025 (был в РФ) → **счётчик не растёт**, стоит на 149 -- **Январь 2027:** каждый день +1 новый, −1 январь 2026 (был в РФ) → **счётчик не растёт** -- **Февраль 2027:** аналогично февраль 2026 был в РФ → **счётчик не растёт** -- **С 15.03.2027:** из окна начинают выпадать дни после 14.03.2026 (КР, не РФ) → каждый день в РФ даёт **чистый +1** +С 29.11.26 счётчик стоит на 177. Ноябрь и декабрь 2025 были в РФ, поэтому дни конца ноября и декабря 2026 нейтральны (+1 новый −1 выпавший). Но запас 6 дней исчерпывается **раньше**, чем декабрьское выпадание успевает помочь. -### Итог по поездке с 29.11.2026 +- **29.11.26 → 04.12.26:** счётчик 177→182 (5 дней пребывания, нейтральное выпадание ноября 2025) +- **05.12.26:** счётчик достигает 183 → **резидент** -| Период в РФ | Счётчик | -|---|---| -| 29.11.26 → 14.03.27 | остаётся ~149 | -| С 15.03.27 | растёт: +1/день | -| Лимит исчерпан (~17.04.27) | 183 — нужно выехать | +### ⚠️ Безопасный выезд при поездке 29.11.2026 + +**Выехать не позднее 04.12.2026** (5 дней пребывания максимум, включая день приезда). --- @@ -72,6 +69,5 @@ created: '2026-08-24' ## Вывод / план - **Сейчас:** нерезидент РФ, всё чисто -- **Поездка 29.11.2026:** можно сидеть до ~середины марта 2027 без роста счётчика -- **Март 2027:** выехать до ~17.04.2027 чтобы не пробить 183 -- **Принцип:** ноябрь–февраль в РФ безопасны пока предыдущий год был аналогичным; март — точка слежения +- **Поездка 29.11.2026:** запас всего 6 дней — выехать **до 05.12.2026** +- **Принцип:** следить за датами, особенно после длинного лета в РФ — запас резко сокращается From ae0ea7ffebc646bb8ca0f8b666b449d862b55e1c Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 11:05:29 +0600 Subject: [PATCH 15/81] [2026-08-24] eagle: personal/business/rf-tax-residency.md --- personal/business/rf-tax-residency.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/personal/business/rf-tax-residency.md b/personal/business/rf-tax-residency.md index 7c349eec..72cd2192 100644 --- a/personal/business/rf-tax-residency.md +++ b/personal/business/rf-tax-residency.md @@ -34,18 +34,17 @@ tags: Окно 29.11.2025 → 28.11.2026: - 29.11.25 → 14.03.26 = **106 дней** - 04.07.26 → 12.09.26 = **71 день** -- **Итого: 177 дней** (запас: всего **6 дней** до 183) +- **Итого: 177 дней** (запас: **6 дней** до 183) ### Динамика окна при пребывании с 29.11.2026 -С 29.11.26 счётчик стоит на 177. Ноябрь и декабрь 2025 были в РФ, поэтому дни конца ноября и декабря 2026 нейтральны (+1 новый −1 выпавший). Но запас 6 дней исчерпывается **раньше**, чем декабрьское выпадание успевает помочь. - -- **29.11.26 → 04.12.26:** счётчик 177→182 (5 дней пребывания, нейтральное выпадание ноября 2025) -- **05.12.26:** счётчик достигает 183 → **резидент** +- **29.11.26 → 14.03.27:** из окна выпадают дни 29.11.25→14.03.26 — все в РФ → +1 −1 = **счётчик стоит на 177** +- **15.03.27:** из окна начинают выпадать дни с 15.03.26 (КР) → каждый день в РФ даёт **чистый +1** +- Запас 6 дней → нужно выехать до **~21.03.2027** ### ⚠️ Безопасный выезд при поездке 29.11.2026 -**Выехать не позднее 04.12.2026** (5 дней пребывания максимум, включая день приезда). +**Выехать не позднее 20.03.2027** --- @@ -69,5 +68,5 @@ tags: ## Вывод / план - **Сейчас:** нерезидент РФ, всё чисто -- **Поездка 29.11.2026:** запас всего 6 дней — выехать **до 05.12.2026** +- **Поездка 29.11.2026:** можно сидеть до **20.03.2027** — счётчик нейтрален пока выпадают дни зимы 2025/26 (были в РФ), с 15.03.27 начинает расти - **Принцип:** следить за датами, особенно после длинного лета в РФ — запас резко сокращается From 822e072418e725fd46a6bf87f9d2cff95f0460ce Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 14:32:09 +0600 Subject: [PATCH 16/81] [2026-08-24] eagle: personal/plans/ohotnichy-bilety-interaktiv.md personal/projects/personal-os/eagle-dashboard.md --- personal/plans/ohotnichy-bilety-interaktiv.md | 80 +++++++++++++++++++ .../projects/personal-os/eagle-dashboard.md | 15 ++++ 2 files changed, 95 insertions(+) create mode 100644 personal/plans/ohotnichy-bilety-interaktiv.md diff --git a/personal/plans/ohotnichy-bilety-interaktiv.md b/personal/plans/ohotnichy-bilety-interaktiv.md new file mode 100644 index 00000000..953df556 --- /dev/null +++ b/personal/plans/ohotnichy-bilety-interaktiv.md @@ -0,0 +1,80 @@ +# Интерактивные билеты охотника (a1-tir.ru/bilety) + +Проект: скачать страницу билетов для экзамена на гражданское оружие и превратить в интерактивный тренажёр. + +**Возможности:** номер правильного ответа скрыт · ответы кликабельны · выбранный неправильный → красный, правильный → зелёный. + +**Файлы (исходники в `~/Downloads/`):** +- `bilety.html` — скачанная + расширенная страница (инъекция CSS/JS + метаданные) +- `bilety.js` — enhancer: парсер вопросов + click-логика +- `bilety.css` — стили подсветки (зелёный/красный) +- `a1-tir_bilety_raw.html` — оригинальная скачанная копия (667 КБ) + +--- + +## Статус +- ✅ Страница скачана и переработана в интерактив. +- ⏸️ **Доставка в Eagle Dashboard Pages не завершена** — упирается в права: `/Library/WebServer/Documents/` root-owned, `sudo cp` требует пароль из неинтерактивного шелла. Нужно либо получить sudo-пароль от Alex, либо он запустит вручную: + ```bash + sudo cp ~/Downloads/bilety.html ~/Downloads/bilety.js ~/Downloads/bilety.css /Library/WebServer/Documents/ + ``` + После копирования страница появится в `http://localhost:8880/?tab=pages` под именем `bilety` (title/purpose/contains уже заполнены). Рестарт дашборда не нужен. + +--- + +## Источник и структура (Tilda) + +Страница — Tilda-лендинг, весь исходный HTML на одной строке (`a1-tir_bilety_raw.html`, строка 228 содержит контент). + +Экзамен разложен по **4 блокам** `data-record-type="106"` (Tilda text-блок `div.field-text.t-text`): +- `rec465410787` — «Правовая подготовка», вопросы 1.1–1.49 +- `rec1120437831` — без заголовка (продолжение правовой), 1.50–1.93 +- `rec1120438216` — «Огневая подготовка», 2.1–2.41 +- `rec465410788` — без заголовка (правила охоты), 58–103 · **вопросы из нескольких ``** +- Итого ~180 вопросов. + +### Структура одного вопроса в DOM (проверено по сырым данным) +Каждый блок — один большой div; внутри `childNodes`: +- `
` — разделители (шум) +- `Вопрос` — текст вопроса; может занимать **несколько подряд** `` (напр. вопрос 58); внутри возможен вложенный `` (consultantplus) +- шапка раздела — `

Заголовок

` (strong вложен в p → не ловится как вопрос) +- текстовые узлы ответов: `"1. Текст"`, `"2. ..."`, `"3. ..."` (бывают ведущие пробелы) +- `N` — **номер правильного ответа** (чистое число) +- примечание — `Примечание: …` (НЕ номер, сохранить) +- шум: ` `, ` `, пустой `` с `` + +Контентных ``/`` в блоках вопросов нет — только текст. + +--- + +## Решение — чисто клиентский JS (без библиотек/backend) + +`bilety.js` на `DOMContentLoaded` обрабатывает каждый `[data-record-type="106"] .t-text`: + +**Парсер `parseQuiz` (конечный автомат по childNodes):** +- `` с непустым текстом, не ` `: если у текущего вопроса ещё нет ответов и фаза `question` → **мержим** текст (многострочный вопрос); иначе → **новый вопрос**. +- текстовый узел, матчащий `^\d+[\.\s:]` и при отсутствии заданного `correct` → ответ `{n, text}` (фаза → `answers`); иначе — продолжение последнего ответа. +- `` с чистым числом → `question.correct = N` (только в фазе `answers`, чтобы не спутать с «Примечание»); с текстом → `question.note = innerHTML` (сохранить); пустой/` ` → шум. +- `

` при `cur === null` и нет вопросов → `headerHTML` (заголовок раздела сохраняем). +- фильтр: оставляем только вопросы с `correct !== null`. + +**Рендер `renderQuestion`:** карточка `.whale-q` → `.whale-q-text` (вопрос, `textContent`, жирный) + `.whale-answers` с кнопками `.whale-a` (`data-n` = номер ответа) + опционально `.whale-note`. + +**Click-логика:** первый клик блокируется (`data-locked`). Если `n === correct` → класс `correct` (зелёный); иначе класс `wrong` (красный) **и** правильный ответ получает `correct` (чтобы показать верный). Управляется `data-correct` на карточке. + +**Инъекция в страницу:** +- `` перед `` +- `` перед `` +- мета для дашборда в ``: `eagle-test-purpose`, `eagle-test-contains`. + +**Дизайн .whale-a:** карточки-кнопки (flex column), `#f5f5f5`, hover `#ececec`; `.correct`=`#d4edda`/`#28a745`, `.wrong`=`#f8d7da`/`#dc3545` (с `!important`). + +--- + +## Pitfall: локальное открытие `file://` +Страница Tilda использует `sessionStorage` для анимации появления `.t-records` — при открытии локально это работает. Просто открыть `bilety.html` двойным кликом достаточно для проверки функционала. + +--- + +## Связанное +- Доставка в дашборд — механика Pages: `personal/projects/personal-os/eagle-dashboard.md`. diff --git a/personal/projects/personal-os/eagle-dashboard.md b/personal/projects/personal-os/eagle-dashboard.md index 2102dece..8e782794 100644 --- a/personal/projects/personal-os/eagle-dashboard.md +++ b/personal/projects/personal-os/eagle-dashboard.md @@ -149,6 +149,21 @@ PID-file-based — survives Dashboard restarts without crashing. **Pages** — URL input + metadata table for `/Library/WebServer/Documents/*.html` test pages. Each row shows filename, title, purpose, contents, modified date, and opens the page in a new browser tab. +### Как добавить страницу в Pages (2026-08-24, проверено) + +Механика — просто копия `*.html` файла в webroot `/Library/WebServer/Documents/`. Дашборд читает каталог **живьём** через `GET /api/pages` → `_read_page_metadata()` — рестарт дашборда и `launchctl kickstart` **не нужны**. Страница отдаётся по `/local-pages/` (mount `app.mount("/local-pages", StaticFiles(...))`). + +Метаданные парсятся из HTML: +| Поле дашборда | Источник | +|---|---| +| `title` | `...` | +| `purpose` | ``, fallback — `` | +| `contains` | `` | + +**Pitfall — относительные `href`/`src`:** если страница ссылается на свои `.js`/`.css` относительными путями (как `bilety.html` → `bilety.js`, `bilety.css`), эти файлы тоже обязаны лежать рядом в `/Library/WebServer/Documents/`, иначе запрос уйдёт на `/local-pages/bilety.js` и не найдётся. + +**Pitfall — права (блокер):** `/Library/WebServer/Documents/` принадлежит `root:wheel`, права `drwxr-xr-x`. `admin` писать туда **не может** без sudo. NOPASSWD-правил для этого пути в sudoers **нет** (`admin` имеет только `(ALL) ALL` с паролем + спец. pmset/launchctl NOPASSWD). Из неинтерактивного шелла Hermes `sudo cp` встаёт на запрос пароля → **требуется пароль пользователя или ручная команда**: `sudo cp ~/Downloads/bilety.* /Library/WebServer/Documents/`. + **Files** — FileBrowser iframe at `http://localhost:8181`. **Crons** (2-я вкладка) — управление cron jobs из 3 источников: From 04bafb46100594d0c086ff0a92ea0ad1ccec48df Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 14:47:16 +0600 Subject: [PATCH 17/81] [2026-08-24] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- family/how-to/truenas-sata-ports-and-zfs-pools.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index 7e478f23..bfcd6679 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -288,6 +288,16 @@ zpool list RED_2TB - вернуть данные: `rsync -aHAX /mnt/IRONWOLF/ /RED_2TB/`; - восстановить инфраструктуру (docker: caddy, transmission, HA, immich...), доступы, cron-бэкапы, Obsidian sync. +### ✅ LIVE-СТАТУС ПОСЛЕ ПЕРЕСОЗДАНИЯ (2026-08-24, проверка Китом) + +**Пул УЖЕ зарегистрирован в TrueNAS и работает — перезагрузка/импорт НЕ нужны:** +- `zpool status RED_2TB` → **ONLINE** (mirror-0 {sdc,sdf} + mirror-1 {sde,sdd}), ошибки `0 0 0`. +- `midclt call pool.query` → `id=1, name=RED_2TB, status=ONLINE`, topology заполнена новой (оба mirror, GUIDs). БД TrueNAS привязала пул по GUID, запись обновлена под новую топологию. +- Пул смонтирован (`/mnt/RED_2TB/`, `mounted=yes`), CAP 79% (5.44T, ALLOC 4.35T, FREE 1.09T). +- **rsync возврата данных ЗАВЕРШЁН.** Вернулись все datasets: storage 3.29T, immich-photos-upload 353G, backup 287G, Edu 214G, Photos 146G, old-bu 65.2G, docker 2.92G, docker.bak 789M, system 112K. Корни IronWolf↔RED_2TB идентичны по ls. + +**⚠️ НЕ ЗАКРЫТО: TimeMachine (~277G) НЕ вернулся.** Причина: на IronWolf `/mnt/IRONWOLF/TimeMachine/` существует (277G), но root-only NFSv4 ACL → `truenas_admin` НЕ может прочитать (`Permission denied`) → rsync его не докопировал. На RED_2TB датасет `TimeMachine` НЕ воссоздан (нет в `zfs list`, каталога нет). **TODO под root:** создать dataset `RED_2TB/TimeMachine` (+ дочерний `guest` как было) и `rsync -aHAX /mnt/IRONWOLF/TimeMachine/ /mnt/RED_2TB/TimeMachine/`. iocage-каталог восстановлен, но старые jails не нужны (всё в docker) — решено ранее. + ## ⚠️ НЕ ВХОДИТЬ В RW-ИМПОРТ ПОВРЕЖДЁННоГО ПУЛА **Импорт RED_2TB в не-readonly режиме (`zpool import` без `-o readonly=on`) — ВСЕГДА даёт kernel panic** (`zfs: adding existent segment to range tree`). Это правило подтверждено много раз. При пересоздании пул НЕ импортировать — только стереть метки (`labelclear`) и создать заново. `zpool import -d /dev` (dry-list) безопасен, но не запускает пул. From 9e7b6a46fe45f230e727786ef6a0b8c1676380d6 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 14:52:18 +0600 Subject: [PATCH 18/81] [2026-08-24] eagle: family/how-to/truenas-sata-ports-and-zfs-pools.md --- .../truenas-sata-ports-and-zfs-pools.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/family/how-to/truenas-sata-ports-and-zfs-pools.md b/family/how-to/truenas-sata-ports-and-zfs-pools.md index bfcd6679..3f3cf292 100644 --- a/family/how-to/truenas-sata-ports-and-zfs-pools.md +++ b/family/how-to/truenas-sata-ports-and-zfs-pools.md @@ -298,6 +298,26 @@ zpool list RED_2TB **⚠️ НЕ ЗАКРЫТО: TimeMachine (~277G) НЕ вернулся.** Причина: на IronWolf `/mnt/IRONWOLF/TimeMachine/` существует (277G), но root-only NFSv4 ACL → `truenas_admin` НЕ может прочитать (`Permission denied`) → rsync его не докопировал. На RED_2TB датасет `TimeMachine` НЕ воссоздан (нет в `zfs list`, каталога нет). **TODO под root:** создать dataset `RED_2TB/TimeMachine` (+ дочерний `guest` как было) и `rsync -aHAX /mnt/IRONWOLF/TimeMachine/ /mnt/RED_2TB/TimeMachine/`. iocage-каталог восстановлен, но старые jails не нужны (всё в docker) — решено ранее. +### ⚠️⚠️ АКТИВНАЯ ПРОБЛЕМА №3 (2026-08-24): Docker/слой приложений НЕ поднят — контейнеры лежат + +Пул с файлами работает, но **слой приложений (docker/TrueNAS Apps) НЕ восстановлен**. Проверка live (Кит): +- `docker ps` → `Cannot connect to the Docker daemon`. `systemctl status docker` → `inactive (dead)`, **disabled**. +- **`docker daemon.json` (`/etc/docker/daemon.json`):** `{"data-root": "/mnt/.ix-apps/docker", "exec-opts": ["native.cgroupdriver=cgroupfs"], "iptables": true, "storage-driver": "overlay2", "default-address-pools": [{"base": "172.17.0.0/12", "size": 24}]}` → это классическая схема TrueNAS Apps. +- **Датасета `.ix-apps`/`ix-applications` НЕТ** в `zfs list` на пересозданном пуле → docker storage/образы/volumes (в старом пуле это был датасет `ix-apps`, docker 23.6G) **НЕ мигрировали** / потеряны. +- **Конфиги ВСЕХ приложений на месте** в `/mnt/RED_2TB/docker/` (29 каталогов): arr, backups, caddy, cups, filebrowser, gitea, ha, hermes, homeassistant, immich, inpx-web, inpxer, library, mbusd, modbus-bridge, mosquitto, nodered, portainer, portainer-mcp, python, rclone, ser2net, syncthing, transmission, vless-proxy, watchtower, webdav, xray-admin, zigbee2mqtt. +- `override.conf` (`/etc/systemd/system/docker.service.d/override.conf`): только `ExecStartPost=iptables -P FORWARD ACCEPT && ip6tables -P FORWARD ACCEPT` — применяется при старте docker. + +**Вывод:** `/mnt/RED_2TB/docker/` — это конфиги; docker-образы (layers) не сохранились → контейнеры надо пересоздавать с перекачкой образов. + +**ПЛАН ВОЗВРАТА КОНФИГА В СТРОЙ (4 шага, пока НЕ выполнен):** +1. **WebUI TrueNAS → Apps → Settings → Choose Pool → RED_2TB.** TrueNAS сама создаст датасет приложений (ним `ix-applications`), примонтирует docker storage в `/mnt/ix-applications` (data-root `.ix-apps/docker`), поднимет `docker.service`. *(`docker` сейчас disabled — старт произойдёт именно через настройку Apps, не вручную.)* +2. Конфиги приложений уже лежат в `/mnt/RED_2TB/docker/` — трогать не надо. +3. **Пересоздать каждый контейнер** (WebUI Apps нативный/Custom App) с **bind-mount** `/mnt/RED_2TB/docker/` → внутрь контейнера. Образы перекачаются при старте, контейнер подхватит свой существующий конфиг. +4. Разовое: `override.conf` (iptables FORWARD) применится сам при старте docker; порты/сеть прежние; данные приложений (immich library, transmission downloads и т.д.) уже в `/mnt/RED_2TB/`. + +**⚠️ Перезагрузка НЕ поможет** поднять контейнеры: docker `disabled` + пул приложений не настроен. Перезагрузка полезна только ПОСЛЕ шага 1. +**⚠️ Вопрос к Alex:** docker storage `.ix-apps` (образы, ~23.6G) точно НЕ переносили на IronWolf? Если перенесли — указать куда, вернуть и настройка упростится (образы сохранятся). Если нет — только перекачка. + ## ⚠️ НЕ ВХОДИТЬ В RW-ИМПОРТ ПОВРЕЖДЁННоГО ПУЛА **Импорт RED_2TB в не-readonly режиме (`zpool import` без `-o readonly=on`) — ВСЕГДА даёт kernel panic** (`zfs: adding existent segment to range tree`). Это правило подтверждено много раз. При пересоздании пул НЕ импортировать — только стереть метки (`labelclear`) и создать заново. `zpool import -d /dev` (dry-list) безопасен, но не запускает пул. From 1620109097f5a45df26e642a6d41d2a8c8a10eab Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 14:57:21 +0600 Subject: [PATCH 19/81] [2026-08-24] eagle: family/how-to/truenas-infrastructure.md --- family/how-to/truenas-infrastructure.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 89188315..766a449c 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -1,6 +1,15 @@ # TrueNAS — инфраструктура -> Обновлено: 2026-08-21 (данные спасены на IronWolf, пул RED_2TB OFFLINE, готовность к пересозданию) +> Обновлено: 2026-08-24 (пересоздание закончено, пул ONLINE, остался подъём docker) + +> ## ✅ СТАТУС на 2026-08-24: пул ПЕРЕСОЗДАН и работает; docker НЕ поднят +> **Пул RED_2TB пересоздан и УЖЕ зареган в TrueNAS** — перезагрузка/импорт НЕ нужны. `zpool status` ONLINE (`mirror-0{sdc,sdf}`+`mirror-1{sde,sdd}`), `midclt call pool.query` id=1 RED_2TB ONLINE, топология обновлена. rsync возврата данных ЗАВЕРШЁН (storage 3.29T, immich 353G, backup 287G, Edu 214G, Photos 146G, old-bu 65G, docker, docker.bak, system — все смонтированы, `/mnt/RED_2TB/`). +> **⚠️ НЕ ГОТОВО — слой приложений (docker) НЕ восстановлен:** +> - `docker.service` — `inactive (dead)`, `disabled`. Образы/тома/контейнеры НЕ запущены. +> - **`.ix-apps` датасет (docker storage, был 24G) НЕ перенесён при выгрузке на IronWolf** и НЕ сохранён — rsync шёл из `/mnt/RED_2TB/*` и не включал монтируемый в `/mnt/.ix-apps` системный датасет. Проверено: `/mnt/.ix-apps` пуст, на IronWolf его нет, в `zfs list` нет. Образы = кеш → перекачаются из registry сами; конфиги целы в `/mnt/RED_2TB/docker/`. +> - **Контейнеры запускались через `docker-compose`, НЕ через TrueNAS Apps (TrueCharts/Custom App).** Управление в доке — `docker restart homeassistant`, `docker exec ...`; daemon.json `data-root:/mnt/.ix-apps/docker`. `.ix-apps` = просто data-root docker, не TrueNAS Apps. +> **TODO подъёма docker:** (1) создать датасет/папку под `data-root` (куда смотрит `/mnt/.ix-apps/docker`), (2) вернуть/найти compose-файл, (3) `docker compose up -d` → контейнеры поднимутся с маунтами на `/mnt/RED_2TB/docker/` (конфиги на месте). +> **⚠️ НЕ ЗАКРЫТО отдельно:** TimeMachine (~277G, бэкапы macOS) НЕ возвращён — на IronWolf `/mnt/IRONWOLF/TimeMachine/` root-only NFSv4 ACL → rsync не докопировал. Алекс решение по нему не подтвердил («какой нахуй возврат time machine» — вероятно не нужен, старые снепшоты не важны). > ## ⚠️ СТАТУС на 2026-08-21: пул RED_2TB — данные СПАСЕНЫ, пул OFFLINE, пересоздаём > **Выгрузка успешно завершена** (подтверждено Alex): данные RED_2TB (4.56T) на IronWolf (пул `DEST`, `/mnt/IRONWOLF`). **Пул RED_2TB — статус OFFLINE** в БД TrueNAS, НЕ импортирован. Конфиги docker (caddy, transmission, HA, immich и т.д.), Obsidian vault и git-репо спасены на `/mnt/IRONWOLF` (`system/`, `docker.bak/`, `docker/`, `storage/obsidian`, `storage/git`). From 975e6ed6878840b69a1e5e9cafc0d77e79b24e71 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 15:12:28 +0600 Subject: [PATCH 20/81] [2026-08-24] eagle: family/how-to/truenas-infrastructure.md --- family/how-to/truenas-infrastructure.md | 26 ++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/family/how-to/truenas-infrastructure.md b/family/how-to/truenas-infrastructure.md index 766a449c..91cbd94d 100644 --- a/family/how-to/truenas-infrastructure.md +++ b/family/how-to/truenas-infrastructure.md @@ -8,8 +8,9 @@ > - `docker.service` — `inactive (dead)`, `disabled`. Образы/тома/контейнеры НЕ запущены. > - **`.ix-apps` датасет (docker storage, был 24G) НЕ перенесён при выгрузке на IronWolf** и НЕ сохранён — rsync шёл из `/mnt/RED_2TB/*` и не включал монтируемый в `/mnt/.ix-apps` системный датасет. Проверено: `/mnt/.ix-apps` пуст, на IronWolf его нет, в `zfs list` нет. Образы = кеш → перекачаются из registry сами; конфиги целы в `/mnt/RED_2TB/docker/`. > - **Контейнеры запускались через `docker-compose`, НЕ через TrueNAS Apps (TrueCharts/Custom App).** Управление в доке — `docker restart homeassistant`, `docker exec ...`; daemon.json `data-root:/mnt/.ix-apps/docker`. `.ix-apps` = просто data-root docker, не TrueNAS Apps. -> **TODO подъёма docker:** (1) создать датасет/папку под `data-root` (куда смотрит `/mnt/.ix-apps/docker`), (2) вернуть/найти compose-файл, (3) `docker compose up -d` → контейнеры поднимутся с маунтами на `/mnt/RED_2TB/docker/` (конфиги на месте). +> **TODO подъёма docker:** (1) создать датасет/папку под `data-root` (куда смотрит `/mnt/.ix-apps/docker`), (2) Docker engine: `systemctl enable --now docker` + проверить `docker info`, (3) поднять контейнеры: большинство уже имеют `docker-compose.yml` в `/mnt/RED_2TB/docker//` → `docker compose up -d`; **4 контейнера без compose (ha, webdav, modbus-bridge, zigbee2mqtt) восстанавливать вручную** — параметры и полный инвентарь в разделе «Инвентарь compose-файлов по папкам» ниже. Конфиги целы в `/mnt/RED_2TB/docker/`, образы перекачаются из registry (storage `.ix-apps` потерян = только кеш). > **⚠️ НЕ ЗАКРЫТО отдельно:** TimeMachine (~277G, бэкапы macOS) НЕ возвращён — на IronWolf `/mnt/IRONWOLF/TimeMachine/` root-only NFSv4 ACL → rsync не докопировал. Алекс решение по нему не подтвердил («какой нахуй возврат time machine» — вероятно не нужен, старые снепшоты не важны). +> **⚠️ ДРУГОЕ (проверено 2026-08-24):** пул `DEST` (IronWolf, источник спасения) на момент проверки `DEGRADED` в `zpool list` — стоит разобраться, почему (вероятно отвалился mirror-член). Также SSH с Mac к TrueNAS по 192.168.2.197 нестабилен (`Connection reset/reset by peer`, `kex_exchange_identification read`), возможен конфликт сессий при активном входе на консоль — использовать `mallexxx.duckdns.org` и ретраи. > ## ⚠️ СТАТУС на 2026-08-21: пул RED_2TB — данные СПАСЕНЫ, пул OFFLINE, пересоздаём > **Выгрузка успешно завершена** (подтверждено Alex): данные RED_2TB (4.56T) на IronWolf (пул `DEST`, `/mnt/IRONWOLF`). **Пул RED_2TB — статус OFFLINE** в БД TrueNAS, НЕ импортирован. Конфиги docker (caddy, transmission, HA, immich и т.д.), Obsidian vault и git-репо спасены на `/mnt/IRONWOLF` (`system/`, `docker.bak/`, `docker/`, `storage/obsidian`, `storage/git`). @@ -106,6 +107,29 @@ TrueNAS использует **NFSv4 ACL**, а не стандартный POSIX | modbus-bridge | modbus-bridge | — | — | | cups-splix | cups-splix | — | принтер | +### Инвентарь compose-файлов по папкам (проверено 2026-08-24) + +Каждый контейнер = своя папка `/mnt/RED_2TB/docker//`. Модель — **не один общий compose, а per-service compose** (контейнеры поднимались `docker compose up -d` из своей папки / `docker run`). + +**✅ Есть `docker-compose.yml` (поднимаются `docker compose -f ... up -d`)** — 21 шт: +arr, caddy, cups, filebrowser, gitea, hermes, immich, inpx-web, inpxer, library, mbusd, mosquitto, nodered, portainer-mcp, portainer, rclone, ser2net, syncthing, transmission, vless-proxy, watchtower + +**⚠️ НЕТ compose-файла — только конфиг (восстанавливать вручную, параметры из доки ниже):** +- **ha** — Home Assistant: `/mnt/RED_2TB/docker/ha/` (automations.yaml). Образ `ghcr.io/home-assistant/home-assistant:stable`, порт `8123`, volume `/mnt/RED_2TB/docker/ha` → `/config`. +- **webdav** — `/mnt/RED_2TB/docker/webdav/` (config.yml). Образ `hacdias/webdav:latest`, домен webdav.mallexxx.duckdns.org. +- **modbus-bridge** — `/mnt/RED_2TB/docker/modbus-bridge/` (config.yml + modbus_ha_bridge.py). Образ `modbus-bridge` (локальная сборка из репо `HA-ZONT-Modbus`). Volumes: config.yml → `/app/config.yml` (ro), modbus_ha_bridge.py → `/app/modbus_ha_bridge.py` (ro). +- **zigbee2mqtt** — `/mnt/RED_2TB/docker/zigbee2mqtt/` (configuration.yaml). Образ `koenkk/zigbee2mqtt:latest`, работает через mosquitto. +- **homeassistant** — в доке упомянут как отдельный контейнер (порт 8123, volume → /config); папка `docker/homeassistant/` есть, но название контейнера в таблице `homeassistant`, а папка конфига HA фактически `ha/`. При восстановлении сверить, какой реально используется. + +### Порядок восстановления docker-стека (зависимости) + +1. **docker engine:** `systemctl enable --now docker` (после создания data-root, см. шапку). Проверка: `docker info | grep -iE "Server Version|Docker Root Dir"`. +2. **Инфраструктура/сеть:** mosquitto (MQTT) → zigbee2mqtt (нужен mosquitto) → nodered (MQTT) → caddy (прокси, тянет все домены) → vless-proxy (SOCKS5 для hermes). +3. **Умный дом:** mbusd (Modbus TCP:502) → modbus-bridge (через mbusd) → ha (homeassistant, нужен caddy для домена). +4. **Медиа/хранилище:** transmission (нужен caddy) → arr (radarr/sonarr/prowlarr) → inpxer (books), inpx-web, library → rclone, syncthing, filebrowser, webdav, gitea. +5. **Сервисы/свои:** hermes-taiga (нужен vless-proxy), portainer, portainer-mcp, watchtower, cups, ser2net. +6. **Проверка:** `docker ps`. HA: `docker exec homeassistant python -m homeassistant --script check_config --config /config`. + ### Transmission — детали - **Config:** `/mnt/RED_2TB/docker/transmission/` (монтируется как `/config`) - **Данные:** `/mnt/RED_2TB/storage` (монтируется как `/mnt/storage`) From c8988eb058acc8f70b008722a1223872199d9e3a Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 24 Aug 2026 15:32:37 +0600 Subject: [PATCH 21/81] [2026-08-24] eagle: personal/projects/personal-os/eagle-dashboard.md personal/tech/bilety-oxota-interaktiv.md --- .../projects/personal-os/eagle-dashboard.md | 1 + personal/tech/bilety-oxota-interaktiv.md | 65 +++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 personal/tech/bilety-oxota-interaktiv.md diff --git a/personal/projects/personal-os/eagle-dashboard.md b/personal/projects/personal-os/eagle-dashboard.md index 8e782794..0cb62bbf 100644 --- a/personal/projects/personal-os/eagle-dashboard.md +++ b/personal/projects/personal-os/eagle-dashboard.md @@ -314,6 +314,7 @@ When a launchd cron is created and `launchctl print gui//