Назад | Перейти на главную страницу

Ошибка XFS после изменения размера раздела

Я в значительной степени следовал той же общей идее, что и здесь: Изменение размера раздела

-Resize VMware disk: Through vSphere, resize disk from 100GB to 300GB
(Reboot VM)
-Delete partition
(fdisk /dev/sdb, d, 1)
-Recreate partition
(While still in the same fdisk session with /dev/sdb, n, p, 1, <defaults>)
(Reboot VM)

К сожалению, теперь XFS FS больше не будет монтироваться.

Я в основном получаю ошибку "плохой суперблок". Я смотрю вокруг, где на самом деле находится SB? Это в разделе или в самом начале диска?

Сейчас:

Когда я пробую команду xfs_repair -n, она довольно долго сканирует и в конце концов отказывается.

xfs_repair -n /dev/sdb1
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
.....<> .....
found candidate secondary superblock
unable to verify superblock continuing...
.....<> .....
Sorry, could not find valid secondary superblock
Existing now.

Должен ли я отмечать начальную позицию после удаления и воссоздания раздела? Теперь я замечаю, что для раздела 1 по умолчанию установлено начало 2048 года, но то, что я заметил в аналогичных системах, это начало 63.

Да, не думал, что запись начала старого раздела перед его удалением важна. Он никогда не встречался во всех моих недавних поисках и, возможно, здесь ключ.

Возможно, мой оригинальный суперблок находится в диапазоне 63-2048? Я скопировал виртуальную машину, так что я могу попробовать несколько вещей, не слишком много играясь с исходной виртуальной машиной. К сожалению, эта копия была взята после Я сломал оригинал.

UFS Explorer https://www.ufsexplorer.com/ufs-explorer-standard-recovery.php, обнаруженный во время поиска, видит файловую систему XFS и, по-видимому, все ее содержимое (через сканирование VMDK).

Вам действительно следовало записать начальный номер сектора раздела. На этом этапе сделайте не коснитесь самой файловой системы, не восстанавливая предварительно правильную структуру разделов.

Вы можете вручную проверить наличие Магический номер MBR (0xAA55) или, что еще лучше, используйте testdisk для восстановления таблицы разделов.

Фактическая основная причина сбоя ... На диске была таблица разделов DOS, которая была уничтожена. Некоторые новые версии fdisk требуют, чтобы вы запускали его с опцией -c=dos, и похоже, что в будущем он будет полностью удален.

Как только я поискал в googled по запросу «fdisk start сектор 63 2048» (который в основном заполняется автоматически!), Все стало более ясным.

https://superuser.com/questions/352572/why-does-the-partition-start-on-sector-2048-instead-of-63