ALTERNATE SUPER-BLOCK FAILED

[SergES]

Здравствуйте, после расширения файловой системы заметил при загрузке такое:
CANNOT READ BLK: 1951569472
CONTINUE? yes
THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1951569472, 1951569473, 1951569474, 1951569475, 1951569476, 1951569477, 1951569478, 1951569479,
LOOK FOR ALTERNATE SUPERBLOCKS? yes
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8).
Mounting local filesystems:.
Система грузиться, но пропало питание ИБП сдох, система упала, просила запустить fsck, но натыкается на это же и в никакую, помогает только акронис с клонированным винтом, 5 часов на восстановление системы и 5 часов на восстановление почты, 10 часов простоя шлюза. Где же найти альтернативный суперблок? В дебрях системы не очень силен.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[guest]

SergES » 2019-09-24 10:13:41
Здравствуйте, после расширения файловой системы заметил при загрузке такое:
CANNOT READ BLK: 1951569472
CONTINUE? yes
THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1951569472, 1951569473, 1951569474, 1951569475, 1951569476, 1951569477, 1951569478, 1951569479,
LOOK FOR ALTERNATE SUPERBLOCKS? yes
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8).
Mounting local filesystems:.
Система грузиться, но пропало питание ИБП сдох, система упала, просила запустить fsck, но натыкается на это же и в никакую, помогает только акронис с клонированным винтом, 5 часов на восстановление системы и 5 часов на восстановление почты, 10 часов простоя шлюза. Где же найти альтернативный суперблок? В дебрях системы не очень силен.

ключевые слова:
- расширение файловой системы (как)
- акронис (брррр)

fsck - общий враппер, использовать нужно fsck_ffs

# man fsck_ffs
-b

# man newfs
-N

если никаких флагов не задавали:
# newfs -N /fs
покажет альтернативные суперблоки
если использовали флаги в newfs, можно через dumpfs посмотреть
характеристики и затем:
# fsck_ffs -b NUM /fs

[SergES]

Расширял через growfs, раздел ufs был 500, а винт 1 терр, после расширения dd отказало, а нужно было быстро перенести один к одному на сервачный блок, потому кроме клонирования акронисом ничего путнего не придумал.

superblock.txt

(17.17 КБ) 25 скачиваний

[SergES]

Будет ли верно если сделать
fsck_ffs -b 192 /fs
?

[guest]

SergES » 2019-09-24 11:16:08
Расширял через growfs, раздел ufs был 500, а винт 1 терр, после расширения dd отказало, а нужно было быстро перенести один к одному на сервачный блок, потому кроме клонирования акронисом ничего путнего не придумал.

Код: Выделить всё

/dev/da0s1a: 948224.0MB (1941962752 sectors) block size 32768, fragment size 4096
        using 1515 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
super-block backups (for fsck_ffs -b #) at:
 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592
 ...
 

da0s1a - диск da0, s1 - первая партиция MBR, "a" - bsd партиция, это корень

# fsck_ffs -y -b 192 /dev/da0s1a (выполнять на несмонтированной FS или смонтированной в RO)
или вместо 192 -> 1282432 или 2564672 и тд и тп

[SergES]

В продолжение, fsck_ffs перевел на альтернативный суперблок, все равно затыкается на
mail kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1951569472, 1951569473
Попробовал следующий блок, fsck выдает то же самое.

[guest]

SergES » 2019-09-27 18:20:32
В продолжение, fsck_ffs перевел на альтернативный суперблок, все равно затыкается на
mail kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1951569472, 1951569473
Попробовал следующий блок, fsck выдает то же самое.

на суперблок уже не ругается?

пишет что не может прочитать указанные сектора, а
smartctl вы прогоняли: short и long? если один из них вылетит,
кирдык.

Я обычно делал так, брал проверенный диск большого объема
или проверял его smartctl, если ok, писал на него образ,
и подключал к рабочей freebsd или ставил freebsd на usb.

В принципе, можно прямо с образом работать:
- ставим freebsd на usb, ставим smartmontools, testdisk
- допустим у нас есть побайтный образ диска bsdold.img

# mdconfig -u md1 -f bsdold.img
# ls -la /dev/md1*
# gpart show /dev/md1
- далее fsck_ffs -y /dev/md1s1a

# man mdconfig

или можно попробовать testdisk, тоже с образом: /usr/ports/sysutils/testdisk
http://www.cgsecurity.org/

Нужно только иметь адьтернативу:
- оригинальный диск + копию и работать с чем-то одним для восстановления
- две копии и работать с одной копией

[SergES]

Да вот как раз нет сдвига ни в какую сторону
Sep 27 16:36:12 mail kernel: /dev/da0s1a: CANNOT READ BLK: 1951569472
Sep 27 16:36:12 mail kernel: /dev/da0s1a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Sep 27 16:36:12 mail kernel: File system preen failed, trying fsck -y
Sep 27 16:36:12 mail kernel: ** /dev/da0s1a
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: CANNOT READ BLK: 1951569472
Sep 27 16:36:12 mail kernel: CONTINUE? yes
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1951569472, 1951569473, 1951569474, 1951569475, 1951569476, 1951569477, 1951569478, 1951569479,
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: LOOK FOR ALTERNATE SUPERBLOCKS? yes
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
Sep 27 16:36:12 mail kernel: -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
Sep 27 16:36:12 mail kernel: SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8).

[SergES]

Перед каждым движением делаю бэкап, пока акронисом (блин), так как любые нормальные утилиты на это и матерятся.

[guest]

SergES » 2019-09-27 20:19:30
Да вот как раз нет сдвига ни в какую сторону
Sep 27 16:36:12 mail kernel: /dev/da0s1a: CANNOT READ BLK: 1951569472
Sep 27 16:36:12 mail kernel: /dev/da0s1a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Sep 27 16:36:12 mail kernel: File system preen failed, trying fsck -y
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

очень интересно, Вы как fsck_ffs запускаете, с чего грузитесь?
filesystem preen failed, preen режим?

Sep 27 16:36:12 mail kernel: ** /dev/da0s1a
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: CANNOT READ BLK: 1951569472
Sep 27 16:36:12 mail kernel: CONTINUE? yes
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1951569472, 1951569473, 1951569474, 1951569475, 1951569476, 1951569477, 1951569478, 1951569479,
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: LOOK FOR ALTERNATE SUPERBLOCKS? yes
Sep 27 16:36:12 mail kernel:
Sep 27 16:36:12 mail kernel: SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
Sep 27 16:36:12 mail kernel: -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
Sep 27 16:36:12 mail kernel: SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8).

если суперблок не читается, fsck вылетит сразу.

"лучше акронис"?! Вы вероятно с unix'ами не имели опыта.

утилита dd во всех unix-like OS и на все времена

# dd if=/dev/что_копируем of=/dev/куда_копируем [bs=512] [conv=sync,noerror]

if=входное устройство: файл, партиция, диск
of=выходное устройство
bs=512 размер буфера
conv - особый параметр, noerror - означает не завершать работу в случае ошибок
sync - заполнить нулями выходной буфер, если во входном ошибки чтения

итого:
# dd if=/dev/da0 of=/dev/da1 bs=128k conv=sync,noerror

лучше подобрать оптимальный размер блока для буфера, для
этого пробовать разный размер bs:
Например, будем копировать 1280MB
# dd ... bs=16k count=80000
# dd ... bs=32k count=40000
# dd ... bs=64k count=20000
# dd ... bs=128k count=10000

bs - blocksize, какой размер блока использовать при операциях READ/WRITE.
by default bs=512 - 512 байт. При таком размере блока, копирование будет
медленным, но более точным. Почему, вот тут выступает опция conv=sync.
Допустим у нас размер блока bs=1M и в нем один сектор сбойный,
в этом случае, на второй диск будет записан весь блок 1M будет записан
нулями - в соответствии с опцией sync (man dd).

можно для каждого диска отдельно посмотреть скорость
- для da0 скорость чтения
# dd if=/dev/da0 of=/dev/null [bs=16k|bs=32k|bs=64k|bs=128k] [count=80000|...]
обычно в unix документации, в квадратных кавычках указывают необязятельный
параметр, а через пайп - возможные параметры.

чтобы dd работал быстрей, часто используют утилиту pv в качестве мониторинга
и промежуточной буферизации

пример:
# dd if=/dev/da0 of=/dev/da1 bs=1M count=1000 (копируем 1GB = 1M * 1000)
выше одна утилита одновременно работает с двумя дисками,
с одного читает, на другой пишет.

ниже, работают две утилиты dd
# dd if=/dev/da0 bs=32k | pv --buffer-size=4m -q | dd of=/dev/da1 bs=32k

первая часть, dd читает с диска da0: dd if=/dev/da0 bs=32k
далее через пайп "|" передает данные на вход pv с размером буфера 4MB,
pv в свою очередь, передает каждый буфер 4MB на вход второй запущенной
dd, которая пишет на другой диск или в файл:

# dd if=/dev/da0 bs=32k | pv --buffer-size=4m -q | dd of=/mnt/disk.img bs=32k

А что там делает акронис, лично мне непонятно.

Я копировал еле живые диски, лишь бы головки читали, иногда приходилось
ставить диски на ребро, ибо лежа головки все время дергались и не
могли считывать, а на ребре могли.

Бывало что с bs=512 байт, копирование диска занимало от 8 часов до 24 часов
и более, если была очень важная информация.

Важно: fsck нельзя прерывать CTRL-C, можно получить кашу вместо файловой
системы, если fsck работала в background, тоже можно было получить кашу,
это ненадежный режим, fsck нельзя запускать если диск смонтирован в RW.

Sorry, но я не уверен в правильности Ваших действий ни при расширении growfs,
ни в акронисе, ни в использовании fsck, надеюсь верхний ликбез поможет,
если что, пишите.

[SergES]

"лучше акронис"?!
Это и для меня дилетанта смешно, но, когда рушится система (она досталась по наследству) а офис должен жить (наверно Вы не против что это правило системщика) применяется любой метод, growfs делал по ману, я системщик виндосерверов, но тут познания малость имею, dd нахрапом при применении получал только матюки из-за fsck, методы увидел, по применяю, для справки, это все работает на dell t110 с рейдом в трех дисках, насчет битых секторов...наверно понятно, а вот насчет growfs Ваша правота, сам не уверен в правоте действий.

[SergES]

PS
Акронисом делаю клон диска, так переносится один в один хоть черт на метле с бутсектором, если Вам известно то пофик файловая система, посекторка точно так же как dd работает, спасает именно это, падает напруга с записью неправильности завершения работы (как вариант, тут и мои действия могут быть причиной) - 7 часов (ночь) - офис в работе. Жаль я не могу на лету и каждый день это пытаться делать, офис работает круглосуточно, но выдираю окна для работы.

[guest]

Акронисом делаю клон диска, так переносится один в один хоть черт на метле с бутсектором, если Вам известно то пофик файловая система, посекторка точно так же как dd работает, спасает именно это, падает напруга с записью неправильности завершения работы (как вариант, тут и мои действия могут быть причиной) - 7 часов (ночь) - офис в работе. Жаль я не могу на лету и каждый день это пытаться делать, офис работает круглосуточно, но выдираю окна для работы.

правильно сказать не "посекторка", а байт в байт, действительно - пофик чем делать,
за одним исключением, параметры для dd я сам подбираю, сам контролирую, знаю
что, как и почему, в течение работы - наблюдаю и записываю сектора на которых
были сбои.
Акронис я не контролирую никак.

Тонкости использования "dd"
- с меньшего размера HDD на больший
- лучше когда система в down, тогда не будет проблем с fsck
- можно и на рабочей системе, но нужно понимать, что dd имеет
время работы и не делает моментальный срез, вот тогда:
a) желательно чтобы FS была без журналирования, в крайнем случае SU, но не SUJ!
b) после завершения "dd" выдаем fsck_ffs -y -f /dev/... на новою копию, иначе
при первом использовании fsck сама попытается это сделать
c) в случае GPT, альтернативная таблица будет не на своем месте и GPT будет corrupt,
что нужно исправить.

"На лету" - можно делать "dd", но возможны проблемы в случае SUJ, понятно что
фавйловая система изменяется в процессе работы "dd", но делать можно, если
объем не превышает 100-200GB, ну и если работают БД, то их нужно отдельно
дампить, dd на живую их убъет.

Ну и "dd" - копирует все без разбора, есть данные, нет данных, это долго,
альтернатива: dump|restore, cpio, pax, tar.

Хотите чтобы не было проблем в будущем, уберите журналирование: man tunefs,
тогда и с "dd" будет меньше проблем и с dump|restore.
Когда диски под систему небольшого размера до 200GB, при верхних условиях,
dd можно делать по расписанию даже по живой FS, за ночь по крону.

Можно использовать rsync, вариантов полно.

Во всех вариантах, нужно чтобы диск на который мы делаем dump, dd или
другой вариант копирования, был в хорошем состоянии, smartctl - ваш
лучший друг, а не Виктория.

Важное: чтобы и на работающей системе не было проблем, правильно
в /etc/rc.conf задавать:
#
fsck_y_enable="YES"
background_fsck="NO"
#

[SergES]

К продолжению.
Дождался выходного офиса, сделал бэкап, на бэкапе запустил однопользовательский режим, и fsck_ffs -y /dev/ada0s1 отказывается исправлять из-за включенного soft update, отключение ничего не дало, показывает отключение успешно но остается включенным, после этого система не реагирует ни на одну команду (device not configured), снова перезагруз но монтирование корня в режиме ro, tunefs -p показывает все отключено, запускаю fsck_ffs -y /dev/ada0s1 промелькивает куча ошибок, но в конце marked clean, перегружаюсь снова, запускаю fsck снова ошибка суперблока...Наверно все же неправильно было сделанно growfs, оставил все попытки, мелькнула мысль, так как на этих системах с битым супеблоком dump не запускается, но есть самая первая оригинальная чистая система, до growfs, могу ли с нее загрузиться, сделать на винте новую разметку и накатить dump-ом с битой системы данные? Не перенесутся ошибки системы?

[Alex Keda]

если у вас файловая система живая, и данные читаются - не мучайтесь, создайте один раздел под /, и переложите на него всё что текущих дисках, через tar c пропуском всего что не читается

[guest]

SergES » 2019-10-07 17:01:28
К продолжению.
Дождался выходного офиса, сделал бэкап, на бэкапе запустил однопользовательский режим, и fsck_ffs -y /dev/ada0s1 отказывается исправлять из-за включенного soft update, отключение ничего не дало, показывает отключение успешно но остается включенным, после этого система не реагирует ни на одну команду (device not configured),

сделал бэкап битой fs? как?
причем тут soft update?
Проблемы с UFS2 возникают в случае включенного журнала "j", если система ставилась с умолчаниями
во время Install, то UFS2 by default создается с опциями "SUJ", это когда:

Код: Выделить всё

# newfs -U -j ...

флаг -U - soft update
флаг -j - journaling
В инсталляторе есть возможность изменить параметры создания UFS2.

Прим: не путать журнал J (от gjournal/geom), с ufs2 журналом j.

ufs2 journaling - за счет ведения журнала, позволяет ускорить процесс fsck на
порядок или два, что существенно для FS >20-30GB и позволяет сократить
время проверки, что существенно при загрузке системы.
Вот только надежность журналирования - никакущая, без UPS лучше не использовать.

В журналировании исправили МОРЕ ошибок, но не все, не помню в каком году,
и признали работу ufs journaling стабильной и запустили в production, да еще
и в Installer'е использую ключи -U и -j by default.
На этом проект закрыли и уведомили что больше развивать и править ufs2 journaling не будут.
То что ошибок в журналировании еще достаточно - факт известный.

В отличие от UFS2+SUJ, чистый UFS2 или UFS2 + SU (soft update), практически неубиваем.

Вот только если у Вас UFS2 уже битая, tunefs -j disable - отключение журанала,
и tunefs -n disable - отключение soft update, на fsck не повлияют.
Сперва нужно привести в порядок FS, а затем отключать journaling.

снова перезагруз но монтирование корня в режиме ro, tunefs -p показывает все отключено, запускаю fsck_ffs -y /dev/ada0s1 промелькивает куча ошибок, но в конце marked clean, перегружаюсь снова, запускаю fsck снова ошибка суперблока...Наверно все же неправильно было сделанно growfs, оставил все попытки, мелькнула мысль, так как на этих системах с битым супеблоком dump не запускается, но есть самая первая оригинальная чистая система, до growfs, могу ли с нее загрузиться, сделать на винте новую разметку и накатить dump-ом с битой системы данные? Не перенесутся ошибки системы?

Ваша проблема в том, что Вы хотите исправить ошибку, не понимая сути и логики, отсюда и
проблемы, что и как Вы делаете - не ясно.

Вот почему я могу делать dd на лету, использовать dump|restore и другие варианты переноса,
sorry, а Вы не можете.

Вернемся к нашим баранам:
- у нас FS создана с SUJ, и не проходит fsck - значит что, правильно - dump|restore
не катит по двум причинам:
1) SUJ (тут есть выход, загрузка с live cd/usb и dump| restore с указаним device, например ada0s1a)
2) не проходит FSCK

В это случае, если FS все же монтируется RO, все данные можно перенести на другой размеченный
диск, используя на выбор: tar, pax, cpio или rsync.

Как:
- если используем tar или pax или cpio - достаточно загрузиться с live cd/usb
- если rsync - нужно сделать загрузочную флешку FreeBSD с установленным нее
rsync

PC: ada0 - битый, ada1 - новый
- загрузились с flash
- используя gpart размечаем ada1, прописываем загрузчик и создаем FS: newfs
- теперь создаем маунт поинты для монтирования FS
# mkdir /ada0 (если у нас несколько FS, то с поддиректориями: /ada0/usr /ada0/var ...)
# mkdir /ada1 (можно одну корневую FS или несколько, как поддиректориями для ada0)
- монтируем битые FS с ada0 в RO (только в RO)
# mount -r /dev/ada0sa /ada0
- монтируем новые FS созданные на ada1
# mount /dev/ada1sa /ada1

Что теперь, теперь можем tar|cpio|pax|rsync с /ada0 на /ada1.
Что имеем, на ada1 мы создали FS руками: newfs -U /dev/ada1sa - она
девственно чистая и без ошибок, затем мы ее смонтировали в /ada1 на RW
и скопировали с /ada0 (RO) все что нам нужно.
Все. (мысль проста, битую FS смонтировали RO, новую в RW и сопировали
все с битой на новую)

Если у нас есть образ или диск с оригинальной FS до growfs, можно
взять и ее, только мы потеряем все изменения и новые файлы,
которые появились после переноса.

Берем PC:
- флешку с FreeBSD
- диск до growfs, далее старый
- новый диск
1. загружаемся с флешки
2. выполняем fsck_ffs -y для FS которые на "старом" диске
далее можем через tunefs отменить journaling, тогда потом
можно dump|restore
3. размечаем новый диск и прописываем загрузчик: gpart,
понятно что на новом диске можем создавать FS больше чем на старом
4. создаем FS на новом диске
5. создаем директории для mount points
6. монтируем

далее варианты
a. dump|restore
b. tar|pax|cpio|rsync

[SergES]

И в заключении, действительно, битый ФС исправлять практически невозможно, ресайз из-за спешки сделал криво, но все работало если правильно завершать, только ставит метку неправильного завершения - пиши пропало, сделал так, создал установщиком стандартную разметку при установке (авто), загрузился с другого винта, сделал бэкап битого винта таром всего раздела / (бэды на рейде из трех винтов получить сложно, тар подошел), применил на всякий newfs и накатил таром созданный бэкап (рах на отрез отказался бэкапить некоторые файлы). В итоге наконец то получил
/dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS. Тему можно закрывать, всем спасибо за помощь.