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

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

#!/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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

testdisk /dev/sda

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

cryptsetup luksOpen /dev/loopX имя

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

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

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

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

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

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

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

Так и есть.

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

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

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

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

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

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, и попыталась его примонтировать... Или это бред? Что дальше делать?

Там ещё и P стоит, а он был не Primary ни разу

Если перевести 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

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

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

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

Я в курсе.

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

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

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

mount -t ntfs-3g /dev/sda /mnt/tmp/ -o ro,offset=216293376

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

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

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

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

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

он не сможет это сам сделать всё

Но ставил-то я её в другой раздел! От 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?

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

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