LINUX.ORG.RU

Стёрлась разметка разделов после установки Windows!

 , ,


0

2

Текущая структура разделов:

Диск /dev/sda: 500.1 Гб, 500107862016 байт
255 головок, 63 секторов/треков, 60801 цилиндров, всего 976773168 секторов
Units = секторы of 1 * 512 = 512 bytes
Размер сектора (логического/физического): 512 байт / 512 байт
I/O size (minimum/optimal): 512 bytes / 512 bytes
Идентификатор диска: 0x00005a20

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sda1            2048    51201266    25599609+  83  Linux
/dev/sda2        51202048   216289279    82543616   83  Linux
/dev/sda4       216293374   976773119   380239873    5  Расширенный
/dev/sda5       949411840   976773119    13680640   83 Linux
Также вот скрин Gparted

Как было: вместо большой неразмеченной области был раздел ext4 (файлохранилище), а после него swap раздел.

Что делал: Отрезал от sda2 60 гигабайт, поставил туда windows для одной специфичной программы (да-да, можно было полдня любиться с wine или ловить тормоза VirtualBox, а я избрал расово неверный путь, знаю). Винду этим же днём я уже удалил и разуплотнил sda2 назад. Больше ничего не делал. Как установка винды могла затронуть расширенный раздел sda4 — вообще без понятия.

Теплиться надежда, что стёрлась только таблица разметки, а сами данные на месте. Прошу помощи!

Вот этим скриптом:

#!/bin/sh
for ((sector=216293374; sector<=949411839 ; sector++)) 
do
   offset=$(($sector*512))
   cmd="mount -t ext4 /dev/sda /mnt/tmp/ -o ro,offset=$offset"
   echo "sector: $sector offset: $offset";
   $cmd 2>/dev/null && echo "partition found @ offset $offset!" && break
done
поищи сектор, в котором находится суперблок файловой системы, затем как найдёшь посредством fdisk удали запись об sda5, затем создай запись об найденном разделе и запись об стёртой sda5. Для указания нижней границы потерянного раздела расчитай номер сектора нижней границы из данных суперблока файловой системы или исходя из её размера.

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

Используй именно fdisk.

kostik87 ★★★★★ ()
Последнее исправление: kostik87 (всего исправлений: 3)
Ответ на: комментарий от kostik87

Спасибо за скрипт, я запустил его в терминале, посмотрел время выполнения — примерно 500 секторов в секунду — это получается 1460000 секунд = 16 дней.

Есть ли способы быстрее?

Pershin ()
Ответ на: комментарий от Pershin

Есть ли способы быстрее ?

Делать это не на шеле и проверять не монтированием. Только, по идее, начало раздела должно быть примерно там же, где и начало sda4. Если секунд через несколько не нашлось, то что-то тут уже не так.

И почему раздел Linux в конце ? После свопа что-то ещё было, или это у свопа тип раздела поменялся ?

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от Pershin

Значит неправильно указаны границы поиска суперблока файловой системы или тип файловой системы. Вспоминай не было ли других изменений в таблице, в остальном она осталась прежней? Попробуй передвинуть верхнюю границу.

kostik87 ★★★★★ ()
Ответ на: комментарий от AS

Делать это не на шеле и проверять не монтированием.

А на чём и чем ещё? Можно написать скрипт на python или php, но смысл это особо не изменит, да и скорость выполнения тоже. Ну, а по поводу монтирования, чем же ты ещё предлагаешь проверять? Можно конечно использовать, к примеру tune2fs, если там extX, но не думаю, что это будет быстрее, либо искать в HEX в дампе содержимого диска коды начала суперблока, так же маловероятно, что это будет быстрее.

kostik87 ★★★★★ ()
Ответ на: комментарий от AS

После свопа был и есть /kali для экспериментов. Его почему-то не затронуло. Какие есть ещё способы? И что вообще произошло, если уж с самого начала?

Pershin ()
Ответ на: комментарий от kostik87

Я расширенный раздел вообще не трогал, это железно. Единственное, что теоретически могло что-то испортить, это следующее: Монтирование свапа у меня в /etc/crypttab было по /dev/sdaX, а не по UUID. Я знаю, что это дико, но у Ubuntu есть старая родовая травма с монтированием раздела подкачки, и это был единственный рабочий способ монтирования. И кстати, так советуют делать во многих руководствах.

Что могло произойти: появился новый раздел (с виндой), номера sda двинулись на единицу, убунта при загрузке попыталась примонтировать 350 гигов свапа с раздела файлопомойки, благополучно испортив раздел

Я все же склоняюсь к версии, что инсталлер винды что-то запорол. «Стёр MBR» или как это правильно гуглить-то хоть?

Pershin ()
Ответ на: комментарий от Pershin

Монтирование свапа у меня в /etc/crypttab было по /dev/sdaX

Так у тебя, видимо, и раздел с данными, а точнее файловая система, была зашифрована и находилась на шифрованном разделе? В таком случае - хз как найти участок диска, на котором находилась шифрованная файловая система.

kostik87 ★★★★★ ()
Ответ на: комментарий от Pershin

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

В любом случае,

testdisk /dev/sda
читай и жмякай enter. Поможет короче, если записи на раздел не было.

anonymous ()
Ответ на: комментарий от Pershin

Можешь попробовать вручную создавать запись о шифрованном разделе посредством fdisk или посредством losetup создавать loop устройство, указывающее на некоторое смещение на диске и пытаться открыть это loop устройство для расшифровки данных на нём командой:

cryptsetup luksOpen /dev/loopX имя

kostik87 ★★★★★ ()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

А на чём и чем ещё ?

Да на чём угодно. Суть в том, чтобы читать данные и проверять структуру сразу. Но это на коленке не сделаешь по-быстрому, надо что-то готовое брать. Тот же testdisk, уже упомянутый. dfsee можно, но он проприетарный.

AS ★★★★★ ()
Ответ на: комментарий от Pershin

Я все же склоняюсь к версии, что инсталлер винды что-то
запорол. «Стёр MBR» или как это правильно гуглить-то хоть?

Не MBP, а таблицу разделов. Причём, видимо, не ту, что в MBR, а нарушил цепочку записей в /dev/sda4, то есть, вместо ссылки на первый раздел получилась ссылка сразу на последний. По хорошему, найти бы старый вывод fdisk -l (у меня, кстати, распечатанная бумажка лежит в корпусе компьютера). Но можно попробовать найти следующий раздел - у него вполне заметная метка, на сколько помню, двухбайтовая. по ней поределяется конец, а начало - по началу sda4 - тоже не помню смещение, откуда должен начинаться раздел с данными, но это опытным путём на тестовом стенде (хоть в виртуалбоксе) можно посмотреть. Но, разумеется, копия исходного состояния должна быть сохранена, чтобы оставался шанс начать сначала.

AS ★★★★★ ()
Ответ на: комментарий от AS

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

Первый раздел с данными в расширенном томе начинается со смещение в 63 сектора, это если диск имеет обычные секторы в 512 байт, а не секторы в 2048 байт`а, в таком случае может быть как 64, так и 2048, последнее более вероятно, в особенности если версия util-linux относительно новая, в новых версиях на всех дисках смещение в 2048 секторов.

Причём, видимо, не ту, что в MBR, а нарушил цепочку записей в /dev/sda4,

Так и есть.

Да на чём угодно. ... Тот же testdisk, уже упомянутый.

Мне, к примеру, более понятно как работает мой скрипт, но он полезен только в случаях когда точно знаешь файловую систему. Но у ТС, вообще, скорее всего, используется шифрование, так что ни мой скрипт, ни testdisk не найдёт шифрованный раздел

Монтирование свапа у меня в /etc/crypttab было по /dev/sdaX, а не по UUID. Я знаю, что это дико, но у Ubuntu есть старая родовая травма с монтированием раздела подкачки, и это был единственный рабочий способ монтирования. И кстати, так советуют делать во многих руководствах.

kostik87 ★★★★★ ()
Ответ на: комментарий от kostik87

Шифрование на диске было только свап-раздела (ну и sda2, он же home). А файлохранилище было обычное.

Сейчас попробую всё, что написали в топике, отпишусь.

Pershin ()
Ответ на: комментарий от AS

testdisk вот что нашёл:

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63
     Partition               Start        End    Size in sectors
 * Linux                    0  32 33  3187  45 58   51200000
 P Linux                 3187  45 59 13463  98 11  165087232
>P HPFS - NTFS          13463 163 13 58460 157  1  722876416 [/data]
 L Linux                59098  39 14 60801  80 15   27361280

Понятия не имею, откуда там NTFS взялся. Раздел /data точно был ext4 (я проверил сейчас на всякий случай по /etc/fstab). Ну да, припоминаю, он когда то давным-давно был NTFS, год назад наверное. Могла ли с того времени какая-то старая метка (индикатор раздела) остаться или что-то такое? И винда увидела «родной» NTFS, и попыталась его примонтировать... Или это бред? Что дальше делать?

Pershin ()
Ответ на: комментарий от Pershin

Если перевести CHS в номера секторов

P HPFS - NTFS          13463 163 13 58460 157  1  722876416 [/data]
echo $((13463*255*63 + 163*63 + 13 - 1))
216293376
и сравнить с номером сектора начала расширенного раздела:
/dev/sda4       216293374   976773119   380239873    5  Расширенный
то мы увидим
echo $((216293376 - 216293374))
2
что раздел NTFS был создав в расширенном разделе, по крайней мере в пространстве секторов расширенного раздела, так что раздел с данными затёрт.

Ищи софт, который умеет восстанавливать данные с частично перезаписанной файловой системы ext4 или какая у тебя там была.

kostik87 ★★★★★ ()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

винда не может быть установлена в расширенный раздел, поэтому она не могла быть там.

old_bastard_ ()
Ответ на: комментарий от old_bastard_

винда не может быть установлена в расширенный раздел

Я в курсе.

поэтому она не могла быть там.

Как видишь, testdisk говорит, что раздел был primary.

ТС, посмотри на номера секторов начала файловой системы. Попробуй её смонтировать:

mount -t ntfs-3g /dev/sda /mnt/tmp/ -o ro,offset=216293376
правда не уверен, что драйвер NTFS-3g так сможет, но попробуй. Ну либо попросту посредством fdisk создай запись о разделе с файловой системой NTFS с указанием рассчитанного сектора начала раздела, рассчитай по аналогии нижнюю границу, затем попробуй смонтировать файловую систему NTFS.

А так, впредь советую несколько раз проверять свои расчёты перед внесением изменений. Ну и если ты двигал разделы посредством gparted, то тут нужно быть очень осторожным, лучше использовать консольные утилиты по изменению размера файловых систем, а затем fdisk - для изменения записей в таблице разделов.

kostik87 ★★★★★ ()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

Да не было там никакого ntfs и быть не могло. На диске вообще ntfs не было нигде уже минимум год.

Pershin ()
Ответ на: комментарий от Pershin

Так ты же сам говоришь, что ставил Windows, вот, видимо в эту область, и поставилась Windows.

Попробуй указанную команду для монтирования файловой системы по смещению.

UPD: Не забудь создать директорию /mnt/tmp/ для точки монтирования, при выполнении скрипта она также должна была существовать.

kostik87 ★★★★★ ()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

Но ставил-то я её в другой раздел! От sda2 отщипнул справа кусок в 60 гигов, получился sda3 в NTFS. При установке винда только этот раздел и видела, туда я и поставил, а остальные линуксовые для неё вообще были размером 0 байт. Не представляю, какого черта она могла залезть в расширенный раздел вообще.

Попробовал.

Failed to mount '/dev/loop0': Недопустимый аргумент
The device '/dev/loop0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Pershin ()

Попробовал в testdisk изменить тип раздела на ext4 и сделать его логическим - тоже не монтируется.

В общем ладно, всем спасибо, тема закрыта. Вся важная инфа есть в бэкапах, так что не страшно.

Pershin ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.