Этот поток (thread) создан, чтобы задокументировать произошедшее и как это было исправлено, на случай, если это сможет кому-то помочь. Работает pve-manager/8.4.1/2a5fa54a8503f96d (ядро: 6.11.11-2-pve) в однохостовой конфигурации для лабораторной среды. Обычно система стабильна, пока не становится иначе. После нескольких зависаний, система перестала загружаться. На всякий случай я вернулся к загрузке ядра 6.8.x по умолчанию, каким-то образом система постоянно откатывалась обратно к ядру 6.11, которое теперь должно быть исправлено. Сообщение на экране "невозможно импортировать пул, пул или датасет не найден" сопровождалось предложением восстановить данные из резервной копии или попробовать ручной импорт.
Статус
Сейчас система работает нормально, и данные не были потеряны.
Что сделало систему снова загрузочной, не установлено на 100%, и причина неисправности также не установлена на 100%.
Я не буду делиться с вами несколькими часами пота и проб и ошибок.
Наблюдения
`zpool status` (очевидно) не удался, так как пул не был найден.
Ручной запуск `zpool import` не привел к онлайн `rpool`, была указана одна неактивная разделенная часть.
Пул был указан как `UNAVAILABLE GAP`.
Хотя это изначально не наблюдалось, один из дисков просто перестал отображаться.
Решение
Загрузил систему с помощью простой live-системы, использовал `gdisk` для восстановления таблицы разделов GPT, выключил питание, выключил PSU (для полноты картины), оставил выключенным на 10-20 секунд (для очистки состояния памяти, необязательно), включил питание. Система загрузилась, невидимый диск снова отобразился, недоступная разделенная часть стала доступна.
Скрипт
Чтобы обеспечить возможность восстановления любых повреждений таблицы разделов GPT, я написал простой скрипт для резервного копирования таблиц разделов GPT.
```bash
mkdir gptbackup
```
```bash
#!/bin/bash
disks=`lsblk -p --nodeps --noheadings | grep -v zd | cut -d" " -f1`
h=`hostname -s`
p="gptbackup"
dat=`date --iso-8601`
for d in $disks
do
x=`echo "$d" | cut -d"/" -f3`
sgdisk -b "$p"/"$h"_"$dat"_"$x" "$d"
done
```
Теперь в папке `gptbackup` должна быть резервная копия таблиц GPT для физических дисков.
Опасения и соображения
Если на этой системе нет вредоносной активности (не невозможно, хотя и маловероятно), то использование ядра 6.11 сопряжено с реальными рисками, лучше не стоит. Эта система не работает с ECC-RAM и страдала от множества ситуаций "зависания", что может "искажать" таблицы разделов. Тот факт, что один диск просто "не отображался" при нескольких перезагрузках, по-прежнему вызывает опасения, на которые у меня нет ответа. Если в ядре 6.8 также возникнет аналогичная ситуация, я обновлю эту тему. Пока я полагаю, что это решено путем повторного переключения на ядро по умолчанию.
Статус
Сейчас система работает нормально, и данные не были потеряны.
Что сделало систему снова загрузочной, не установлено на 100%, и причина неисправности также не установлена на 100%.
Я не буду делиться с вами несколькими часами пота и проб и ошибок.
Наблюдения
`zpool status` (очевидно) не удался, так как пул не был найден.
Ручной запуск `zpool import` не привел к онлайн `rpool`, была указана одна неактивная разделенная часть.
Пул был указан как `UNAVAILABLE GAP`.
Хотя это изначально не наблюдалось, один из дисков просто перестал отображаться.
Решение
Загрузил систему с помощью простой live-системы, использовал `gdisk` для восстановления таблицы разделов GPT, выключил питание, выключил PSU (для полноты картины), оставил выключенным на 10-20 секунд (для очистки состояния памяти, необязательно), включил питание. Система загрузилась, невидимый диск снова отобразился, недоступная разделенная часть стала доступна.
Скрипт
Чтобы обеспечить возможность восстановления любых повреждений таблицы разделов GPT, я написал простой скрипт для резервного копирования таблиц разделов GPT.
```bash
mkdir gptbackup
```
```bash
#!/bin/bash
disks=`lsblk -p --nodeps --noheadings | grep -v zd | cut -d" " -f1`
h=`hostname -s`
p="gptbackup"
dat=`date --iso-8601`
for d in $disks
do
x=`echo "$d" | cut -d"/" -f3`
sgdisk -b "$p"/"$h"_"$dat"_"$x" "$d"
done
```
Теперь в папке `gptbackup` должна быть резервная копия таблиц GPT для физических дисков.
Опасения и соображения
Если на этой системе нет вредоносной активности (не невозможно, хотя и маловероятно), то использование ядра 6.11 сопряжено с реальными рисками, лучше не стоит. Эта система не работает с ECC-RAM и страдала от множества ситуаций "зависания", что может "искажать" таблицы разделов. Тот факт, что один диск просто "не отображался" при нескольких перезагрузках, по-прежнему вызывает опасения, на которые у меня нет ответа. Если в ядре 6.8 также возникнет аналогичная ситуация, я обновлю эту тему. Пока я полагаю, что это решено путем повторного переключения на ядро по умолчанию.
