>Это не спроста! Поддержка GPT в ядре есть/включена?
Поддержка есть. Ее наличие/отсутствие может помещать?
Почему когда винт не в коробке, то GPT нет, а в коробке есть?
Возможно она осталась от попыток установить Барсика...
Не думаю, что она на что-то влияет.

Попробуйте с SystemRescueCd смонтировать сам винт подключенный по SATA, там точно поддержка GPT есть и работает.
А так как в первом листинге партед явно написано «таблица мсдос» значит EPI GPT Support не работает ИМХО.

>А так как в первом листинге партед явно написано «таблица мсдос» значит EPI GPT Support не работает ИМХО.
Ядро то тоже самое и супорт в нем есть, это точно.
Видимо содержимое 0 сектора различается в зависимости от того, как подключен винт. Может он вообще в контроллере как нибудь хитро храниться?
fdisk ведь игнорирует GPT? Почему содержимое записей различно?

И выкиньте, пожалуйста, лично мне (для самообразования c GPT не работал ещё) дамп первых 34 секторов с блоком 512 байт и блоком 4096 байт (плюс если можно с конца то же 34 сектора так же)

# dd if=/dev/sdb of=/home/aleksey/dump_1 bs=512 count=34
# dd if=/dev/sdb of=/home/aleksey/dump_2 bs=4096 count=34
# dd if=/dev/sdb of=/home/aleksey/dump_3 bs=512 skip=625142239 count=34
# dd if=/dev/sdb of=/home/aleksey/dump_4 bs=4096 skip=78142751 count=34

>И выкиньте, пожалуйста, лично мне (для самообразования c GPT не работал ещё) дамп первых 34 секторов с блоком 512 байт и блоком 4096 байт (плюс если можно с конца то же 34 сектора так же)

Это когда он в коробке?

на Вики написано что в GPT-таблице в 0 секторе записана «наследственная MBR», то есть там обычная MBR для таких как fdisk. В ней записано об одном разделе на весь диск. Если я правильно понял, там первый сектор этого раздела и количество записано с учётом 4096 секторов/а не 512, поэтому в 8 раз меньше получается размер винта (40 вместо 320)
Давайте посмотрим все вместе hex дамп нулевого сектора винта и убедимся в этом

# dd if=/dev/sdb of=/home/aleksey/dump_0 bs=512 count=1
# vi -b /home/aleksey/dump_0
:%!xxd
сделайте snapshot
:%!xxd -r
:q!

Без разницы, можно в USB-кармане, но тогда все 4 пункта обязательно

Снял дампы в коробке:

http://www.sharemania.ru/0289154

http://pastebin.com/auedYzmE

Снял через hexdump, боюсь я этого вашего vi... бр....

Я был прав:

000001C0 01 00 83 FE FF FF 3F 00 00 00 C1 52 A8 04 00 00 ......?....R....
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.

--- dump_1 --0x100/0x4400--sector 0----------------------------------- 

Давайте попробуем... Главное чтобы не накрылось ничего. :)
Спасибо, что помогаете!

Честно говоря, я не совсем понял, винт с физическим размером в 4096 байт. Так в чем проблема?

Мне чисто для опыта интересно. Ну и ЛОР комьюнити всё-таки!
Берите листик, надёжней листика с ручкой нет
hexedit установите, с ним удобней работать, прямо на винте редактируются байты

# hexedit -s /dev/sdb //(sdb-искомый винт, желательно подключить по SATA, ведь проверять будем уже без USB кармана)
//перепишите строку 000001C0 на листик, нолики перечёркивайте :)
//идея такая: у нас стартовый сектор 63 но 4096 байт размера, это соотвествует сектору 504 но 512 байт размера (63*8=504)
//конечный сектор 78140097 но 4096 байт размера, это соотвествует сектору 625120783 но 512 байт размера (78140097*8+7=625120783)
//на 8 множим так как 4096/512=8
//если видите нестыковки говорите сразу, я сейчас на ходу рассуждаю
//дальше правьте
//3F 00 00 00 C1 52 A8 04 на 
//F8 01 00 00 0F 96 42 25 
//так как 0x000001F8 = 504
//так как 0x2542960F = 625120783

В никсах не всё так гладко с 4096 байтными секторами
Вам сложно попробовать исправить 16 байт, имея их точных бекап в четырёх местах (ЛОР, у себя в /home, на шаремании, и у меня)? Если заработает, то потом будете екопать как заставить кернел нормально оперировать 4096 секторами. Найдёте, исправите обратно. Не заработает сейчас, тут же вернёте обратно.

>Берите листик, надёжней листика с ручкой нет
Спасибо, несколько позже приступлю к делу, а то скоро топать надо, а процесс ответственный...

Ламерский вопрос:
А нельзя как-нибудь указать размер логического сектора, чтобы сделать его 4096?
Тогда и править ничего не надо будет. Физически ведь винт с секторами в 4096 байт, обращения к нему как к 512 байтному не эффективны, насколько я понимаю.
А адресация внутри раздела как происходит? Ничего что поменяем?

Забыл сказать, что обязательно нужна возможность грузиться с него (в т.ч. и вражескую ОС возможно надо будет водрузить), иначе все это не имеет смысла.

после ребута выкиньте сюда выхлоп parted, только прежде чем p сделайте unit s
Потом попробуйте смонтировать как обычно /dev/sdb1

Раз так, то лучше читайте о том как заставить кернел понимать 4096.
Для 4096 секторов 512 костыль конечно. Я просто писал тот длинный пост с расчётом что винт с 512 физ сектором, ещё не зная что у вас 4096.
Тогда конечно лучше разобраться с 4096!

А адресация внутри раздела как происходит? Ничего что поменяем?

в 0-ом секторе только границы раздела, к файловой системе отношения никакого не имеют

Кажется нашёл кое-что
У вас в dump_4 (вы поняли что я имею ввиду) есть метка «Системный раздел EFI C12A7328-F81F-11D2-BA4B-00A0C93EC93B»
А в dump_2 нет, это наводит на размышдения.
Скажите UUID ext4 раздела # ls -la /dev/disk/by-uuid

root@linux:~# ls -la /dev/disk/by-uuid|grep sdb1
lrwxrwxrwx 1 root root 10 2011-01-14 13:50 9f33822e-bc37-46c4-b1c9-298b7109a11d -> ../../sdb1

P.S. Пока отложил модификации, читаю разбираюсь...