Мне кажется, тут надо брать testdisk и чинить раздел (предварительно забэкапив, если там есть что-то ценное). А потом заново восстанавливать загрузчик.

fdisk автоматически со смещением по GPT размечает диск.

Тред не читал.

Ну диск уже размечен

$ fdisk -l /dev/sda

Диск /dev/sda: 931,51 GiB, 1000204886016 байт, 1953525168 секторов
Disk model: TOSHIBA MQ02ABD1
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: gpt
Идентификатор диска: A612EF98-5CB8-4A29-AACC-4A3AC8C38D68

Устр-во        начало      Конец   Секторы Размер Тип
/dev/sda1        2048  663228415 663226368 316,3G Microsoft basic data
/dev/sda6   663228416 1638948863 975720448 465,3G Microsoft basic data
/dev/sda7  1743806464 1953523711 209717248   100G Файловая система Linux
/dev/sda8  1638948864 1743806463 104857600    50G Файловая система Linux

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

Просто надо как-то сказать ему теперь, что первый раздел с нуля начинается а не с 2048

Не, это не помагает. Да и смысла нет, фалы доступны если смонтировать правильно.

В последнем блоке диска есть бекап таблицы разделов, попробуй восстановить из него:

gdisk -l /dev/sda

Понаписал я много, но после заметил:

mount -o ro,offset=0 /dev/sda1 /mnt

Что значит ″offset=0 /dev/sda1″? Какой смысл для сдвинутого раздела указывать смещение 0?

---- Исходное сообщние:

Вы сначала посмотрите, что у вас с разделами, а то может у вас совсем разное:

# fdisk --type dos --list /dev/sda
# fdisk --type gpt --list /dev/sda

Для этого удобнее установить sgdisk. И сначала записать в файл резервную копию таблицы разделов, чтобы потом можно было через ключ -l восстановить.

делаете им резервную копию таблицы разделов
# sgdisk -b=sgdisk-sda.bin /dev/sda
смотрите подробную информацию по 1 разделу:
# sgdisk -i 1 /dev/sda
пишете команду, удаляющую и создающую раздел:
# sgdisk -d 1 -n 1:0:663228415 -u 1:"Partition unique GUID" -t 1:"Partition GUID code"

Ага, учитывая, что у него теперь ФС с нулевого сектора, звучит как хороший способ похерить суперблок. Я, правда, в душе не представляю, как это можно было сделать. Но если сделано именно это, то сейчас может использоваться резервная копия GPT.

Вы сначала посмотрите, что у вас с разделами, а то может у вас совсем разное:

Вот:

$ fdisk --type dos --list /dev/sda

Диск /dev/sda: 931,51 GiB, 1000204886016 байт, 1953525168 секторов
Disk model: TOSHIBA MQ02ABD1
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: dos
Идентификатор диска: 0xcd4d2c03

Устр-во    Загрузочный начало      Конец    Секторы Размер Идентификатор Тип
/dev/sda1                   1 1953525167 1953525167 931,5G            ee GPT

Раздел 1 начинается не на границе физического сектора.

$ sgdisk -i 1 /dev/sda

Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: D556246C-CE5F-47C7-A329-C2AF70AB649B
First sector: 2048 (at 1024.0 KiB)
Last sector: 663228415 (at 316.3 GiB)
Partition size: 663226368 sectors (316.3 GiB)
Attribute flags: 0000000000000000
Partition name: 'Win7'

Мож побробую ваши инструкции, но решил поставить венду заново на другой диск. Потом когда всё сбэкаплю, попробую

Я пробовал gdisk’ом в Recovery меню комманды

b	use backup GPT header (rebuilding main)
c	load backup partition table from disk (rebuilding main)

но ничё не дало это.

А w после этого нажимал?

Вот что ответил автор проги ms-sys:

The –partition switch does not in any way alter the partition table, only the file system of the given partition (in this case sda1). This can be done on FAT or NTFS file systems. Usually ms-sys is able to get everything right automagically except for the number of heads. So ms-sys has the switch -H where you manually can set the expected number of heads of the disk.

-p, –partition Write partition info (hidden sectors, heads and drive id) to boot record

вроде бы да. Но это уже не актуально

Да, изначально этот раздел sda1 - это Windows 7 система, была установлена на MBR диск и склонирована ntfsclone’ом на GPT диск.

Вы не торопитесь применять мои инструкции. Я ведь в начале задал вопрос, как у вас монтируется ФС, если ″offset=0″ ничего не меняет?

Если бы у вас было: mount -o ro,offset=0 /dev/sda, то тогда, да, у вас каким-то образом ФС начинается с нулевого сектора диска. Но у вас на нулевом секторе правильный MBR (Protective MBR), а далее нормальный GPT. 2048 — общепринятое начало первого раздела GPT.

начало раздела не 2048, а 0

Так быть не может. В начале диска находится таблица разделов. Не может раздел начинаться с сектора 0.

Я, правда, в душе не представляю, как это можно было сделать.

Сделать ФС с нулевого сектора /dev/sda1? Это наоборот, нужно постараться сделать ФС с не нулевого сектора раздела.

Дай сюда вывод:

# sfdisk -d /dev/sda

Как советовали testdisk /dev/sda поможет восстановлению GPT расделов с резервной копии в конце диска.

Я бы делал так:

# sfdisk -d /dev/sda >sda.txt

# cp sda.txt sda_new.txt

Правим как надо и записываем новую таблицу разделов:

# nano sda_new.txt

# sfdisk /dev/sda <sda_new.txt

Если что не получилось можно откатить:

# sfdisk /dev/sda <sda.txt

А, я не заметил, что он монтирует раздел, а не sda.

Видимо, это какие-то специфичные грабли NTFS и виндового загрузчика, если там такая дичь бывает.

Вы не торопитесь применять мои инструкции. Я ведь в начале задал вопрос, как у вас монтируется ФС, если ″offset=0″ ничего не меняет?

Ну оно указывает начальный сектор 0, как я понимаю. А если без него, то 2048, как я понимаю

$ sudo mount -o ro /dev/sda1 /mnt

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

Дай сюда вывод:

sfdisk -d /dev/sda

$ sfdisk -d /dev/sda
label: gpt
label-id: A612EF98-5CB8-4A29-AACC-4A3AC8C38D68
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1953525134
sector-size: 512

/dev/sda1 : start=        2048, size=   663226368, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=D556246C-CE5F-47C7-A329-C2AF70AB649B, name="Win7"
/dev/sda6 : start=   663228416, size=   975720448, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=8061B0A2-01B3-4DA5-B267-4A34E90763E2
/dev/sda7 : start=  1743806464, size=   209717248, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=F3B72DBC-B276-4687-B1B2-BD299FD42B96
/dev/sda8 : start=  1638948864, size=   104857600, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=E7B3714D-B62C-4B3D-AE03-352CEC57224A

Короче я венду новую поставил, загрузился с неё, и подключил диск с больным разделом через usb адаптер. Раздел конечно не определился (ну как неформатированный). Потом перезагружался обратно в линь, раздел ещё монтировался. Потом опять в венду грузился. И вот сейчас короче раздел перестал монтироваться даже с offset=0

$ sudo mount -o ro,offset=0 /dev/sda1 /mnt

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

Значится окончательно потух.

И я кстати ещё до всего этого, когда раздел ещё раздел монтировался с offset=0, делал бэкап в файл и gdisk’ом и sfdisk -d /dev/sda.

Попробовал восстановить gdisk’овый бэкап - не помогает - не монтируется - не помогло никак.

Попробовал gdisk’ом в Recovery меню комманды:

b	use backup GPT header (rebuilding main)
c	load backup partition table from disk (rebuilding main)

не помогло никак.

А бэкап sfdisk -d /dev/sda точь-точь совпадает с текущим выводом. Так что его пробовать восстановить нет смысла.

Значит проблема в чём-то другом была.

Ну кароч походу всё, теперь не восстановить.

До перезагрузок в венду раздел был как:

$ sudo blkid
...
/dev/sda1: LABEL="Win7" BLOCK_SIZE="512" UUID="01D68F1882578850" TYPE="ntfs" PARTLABEL="Win7" PARTUUID="d556246c-ce5f-47c7-a329-c2af70ab649b"

А теперь как:

$ sudo blkid
...
/dev/sda1: PARTLABEL="Win7" PARTUUID="d556246c-ce5f-47c7-a329-c2af70ab649b"

UPD:

Нет, паниковать рано пытался смонтировать sudo mount -o ro,offset=0 /dev/sda1 /mnt получал ошибку.

тыкал команды из истории терминала
sudo sfdisk /dev/sda
sudo lilo -T geom
sgdisk -i 1 /dev/sda

монтировал соседний раздел
мож ещё чёто делал

В итоге опять смонтировался раздел по sudo mount -o ro,offset=0 /dev/sda1 /mnt
Какая-то магия.

Правим как надо и записываем новую таблицу разделов:

Да, это попробовать можно.
Но сначала забкаплю файлы с раздела.

Нет, 2048 — это начало раздела на диске. А ФС стандартно начинается с нулевого сектора раздела. То есть, offset=0 ничего в поведении mount менять не должен. Может у вас диск сыпется и начальные сектора раздела читаются через раз?

Да, надо сбекапить как минимум файлы, а если есть возможность то и целый раздел с помощью dd if=/dev/sda1 of=/path/to/backup bs=1M status=progress

Экспериментировать на копии бекапа раздела! Но это надо много места.

По-моему там ntfs глючит, а не таблица разделов. Гоняй chkntfs, chkdsk, ntfsfix, …

Может какая вирусов прицепились. Сбекапить файлы, забить диск нулями, рандом и установить все по-новой.

Нет, 2048 — это начало раздела на диске. А ФС стандартно начинается с нулевого сектора раздела. То есть, offset=0 ничего в поведении mount менять не должен. Может у вас диск сыпется и начальные сектора раздела читаются через раз?

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

По-моему там ntfs глючит, а не таблица разделов. Гоняй chkntfs, chkdsk, ntfsfix, …

Может какая вирусов прицепились. Сбекапить файлы, забить диск нулями, рандом и установить все по-новой.

Чтобы это гонять, надо чтобы венда видела диск как ntfs, а она не видит https://0x0.st/XOKh.png
И точно не в вирусах дело.

Да, надо сбекапить как минимум файлы, а если есть возможность то и целый раздел с помощью dd if=/dev/sda1 of=/path/to/backup bs=1M status=progress

Мне кажется без указания offset склонируется что-то нерабочее

Скопируется то что есть в sda1. Можно скопировать ещё первые 2048 сектора sda.

Попробуйте еще: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#310

В dmesg сообщений об ошибках на sda нет? SMART нормальный?

Я бы делал так: …

Не, это по всей видимости не сработает

$ sfdisk --no-act  /dev/sda <sda_new.txt

Диск /dev/sda: 931,51 GiB, 1000204886016 байт, 1953525168 секторов
Disk model: TOSHIBA MQ02ABD1
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: gpt
Идентификатор диска: A612EF98-5CB8-4A29-AACC-4A3AC8C38D68

Старая ситуация:

Устр-во        начало      Конец   Секторы Размер Тип
/dev/sda1        2048  663228415 663226368 316,3G Microsoft basic data
/dev/sda6   663228416 1638948863 975720448 465,3G Microsoft basic data
/dev/sda7  1743806464 1953523711 209717248   100G Файловая система Linux
/dev/sda8  1638948864 1743806463 104857600    50G Файловая система Linux

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

>>> Заголовок скрипта принят.
>>> Заголовок скрипта принят.
>>> Заголовок скрипта принят.
>>> Заголовок скрипта принят.
>>> Заголовок скрипта принят.
>>> Заголовок скрипта принят.
>>> Заголовок скрипта принят.
>>> Создана новая метка диска GPT (GUID: A612EF98-5CB8-4A29-AACC-4A3AC8C38D68).
/dev/sda1: Сектор 0 уже используется.
Failed to add #1 partition: Числовой результат вне представимого диапазона
Выход.

В dmesg сообщений об ошибках на sda нет? SMART нормальный?

да всё ок там

автор ms-sys ответил:

It is fully possible to do a legacy boot also with a GPT partition table. However, most new machines have UEFI boot and ms-sys is not useful for UEFI boot systems. For UEFI boot a GPT partition table is required, but a GPT partition table does not require UEFI boot.

I am not aware of any other way than lilo to find out the number of heads to give to ms-sys. However, there is another tool called testdisk: https://www.cgsecurity.org/wiki/TestDisk . I have used it a few times to restore erased partitions and I have also used PhotoRec to restore contents of lost files. TestDisk claims to be able to «Rebuild NTFS boot sector», maybe that tool will be able to restore the data in the NTFS boot record that you overwrote with «ms-sys –partition»?

However whether it is a good idea to use ms-sys on a GPT disk or an UEFI disk totally depends upon the state of that disk. Ms-sys is a tool designed to fix broken boot records. If something isn’t broken you should not try to fix it. The –partition feature of ms-sys was added so make file systems bootable which had been formatted by more or less flaky formatting programs. With old versions of the Linux kernel that feature used to work fine and fix everything automagically. With not so old versions of the Linux kernel it might be necessary to manually give the number of heads.

It would not be a good idea to use brute force to try to guess the right number of heads. That number is stored in a 16 bit integer giving you more than 32000 numbers to guess from. If you have a similar drive with an NTFS partition it might be possible to study the contents of that NTFS boot record to see the number of heads on that drive. If you have some spare space on the same drive as the borked NTFS partition it might be possible to create another NTFS partition on the drive and study its boot record to find out the number of heads.

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

Разобраться-то не сложно, но я, честно говоря, так и не понял, в чем у тебя проблема.

ты ж записал ms-sys на sda1, а не на sda. Насколько я понимаю ситуацию, то ты похерил не раздел, а начало ФС на sda1.

А можешь смонтировать без offset=0, но указав тип ФС? -t ntfs или прямо смотнтировать с помощью mount.ntfs

ты ж записал ms-sys на sda1, а не на sda. Насколько я понимаю ситуацию, то ты похерил не раздел, а начало ФС на sda1.

Да, но я действовал в рамках инструкций https://wiki.archlinux.org/title/Dual_boot_with_Windows#Restoring_a_Windows_boot_record

Ага, учитывая, что у него теперь ФС с нулевого сектора, звучит как хороший способ похерить суперблок. Я, правда, в душе не представляю, как это можно было сделать. Но если сделано именно это, то сейчас может использоваться резервная копия GPT.

mkfs запросто накатывает файловую систему хоть на ~/курсач.doc, хоть на /dev/sdb. Такой же трюк без создания таблицы разделов я несколько раз проделывал в gparted. Ну и сделать dd if=bolgenos.iso of=/dev/sdb - святое дело.

На онтопике такие флешки и диски работают так же, как если бы соответствующая файловая система находилась на единственном разделе. Офтопик же их видит как не отформатированные и не может с них даже установиться.

Короче вот нерабочий алгоритм действий:

$ sudo mount -o ro,offset=0 /dev/sda1 /mnt

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

$ sudo mount.ntfs /dev/sda1 /mnt

Unexpected clusters per mft record (-128).
Failed to mount '/dev/sda1': Недопустимый аргумент
The device '/dev/sda1' 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?

Вот рабочий алгоритм действий:

$ gnome-disks

# Монтирую и размонтирую в gnome-disks соседний ntfs раздел /dev/sda6, а потом уже:

$ sudo mount -o ro,offset=0 /dev/sda1 /mnt

Монтируется только с offset и только после gnome-disks