Добрый вечер, день, ночь или кому как удобнее.
Есть десктопный компьютер с винчестером, размером в один терабайт.
На нём была установлена Windows 7, на трёх разделах.
Разбивка на разделы и форматирование производилось с
помощью средств самого инсталлятора Windows.
Разбивка производилась с расчётом, что на вторую половину
винчестера будет устанавливаться OS Linux.
Windows 7 установлена, но установить тот же MINT не получается
- gparted вообще не видит разделов и считает винчестер
девственно новым. Попробовал и Ubuntu и даже Parted Magic
последней версии был опробован. Ни в одном дистре gparted
не видит разбивки винчестера, хотя она есть и Windows
работает.
cfdisk всё прекрасно видит, может создавать разделы.
Slackware прекрасно установился и работает...
Но как быть, если я хочу установить ещё и linuxmint, допустим?
Или я ошибаюсь, может у меня винчестер особенный такой?
А у gparted нет проблем с таблицей разделов на винте
размером в 1 терабайт?
Кто сталкивался с подобной ситуацией, отзовитесь пожалуйста.
Может уже есть готовое решение проблемы?
PS
Установил в Slackware gparted, запустил с консольного окна.
Вот что пишет:
[console]/dev/sda contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?[/console]
Скрин gparted?, чуть позже...
GParted и винт на 1 терабайт
Я бы покопал в сторону UEFI. Похоже, что включено.
Я бы покопал в сторону UEFI. Похоже, что включено.
Выключено. Я имею в виду в биосе. Сам выключал.
[quote=Cruiser78]Я бы покопал в сторону UEFI. Похоже, что включено.
Выключено. Я имею в виду в биосе. Сам выключал.[/quote]
Тогда внимательно читаем всё, что связано с GPT. Это далеко не старый добрый MBR про который знают все инсталляторы.
Тогда внимательно читаем всё, что связано с GPT. Это далеко не старый добрый MBR про который знают все инсталляторы.
Дело не в установщике, я так думаю. cfdisk увидел диск и таблицу mbr, доразбил разделы и благодаря этому Slackware установился и работает.
Lilo (не elilo), тоже отработал номально - прописался в mbr...
Но gparted НЕ ВИДИТ таблицу разделов!!!
На данный момент ищет! :D

А система работает ведь...
Поэтому поправка к вопросу - у кого нибудь, gparted видит винчестер размером в 1 терабайт?
[console]/dev/sda contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?[/console]
/dev/sda содержит GPT cигнатуры и таблицу. Короче, здесь Gparted в этом случае не помощник >:o Обратите внимание на GPT Fdisk
Спасибо, но я уже это читал...
С gparted и моим случаем, можно только подозревать.
Вам перевести выхлоп консоли? :[
Вам перевести выхлоп консоли? :[
Не надо...
Лучше объясните как cfdisk врубился в "выхлоп консоли"...
По идее, должен был не понять.
Вообще-то он может создавать GPT разделы
Вообще-то он может создавать GPT разделы
Вот это уже интересно!
А lilo, может видеть?
[quote=Oleg65]Вообще-то он может создавать GPT разделы
Вот это уже интересно!
А lilo, может видеть?[/quote]
Фиг знает, походу нет... http://blog.a2o.si/tag/slackware64/
Поэтому поправка к вопросу - у кого нибудь, gparted видит винчестер размером в 1 терабайт?
Еще раз - внимательно читаем всё, что относится к GPT. И делаем выводы:
1. В оригинальном стартовом топике сказано: gparted вообще не видит разделов и считает винчестер девственно новым
2. Из спецификации GPT очевидно, что установленный там MBR (в первый сектор) служит только для обеспечения совместимости с MBR-ориентированными системами. И этот MBR представляет жесткий диск (независимо от его размера) как единое неразмеченное ничем устройство.
То есть, утилиты, которые не умеют работать с GPT, а могут работать только с MBR здесь бесполезны. А то, что там именно GPT - об том прямо говорит выхлоп консоли.
Варианта решения два:
1. Снести весь диск напрочь, отключить UEFI и GPT, после чего ставить системы обычным порядком на MBR. Будет работать гарантированно всё.
2. Развернуть нужную ось отдельно, а затем перетарить её на GPT-разделы. Ну и соответственно подправить конфиги при этом. Будет ли при этом работать _всё_ - не скажу. Вряд-ли.
cfdisk ничего про GPT не знает, поэтому ничтоже сумняшеся сделал разметку MBR, хвосты от GPT остались.
parted видит получившийся бред в виде несоответствия данных в MBR и в GPT и спрашивает, специально ли поломали разметку и пользуетесь MBR или все-таки использовать GPT?
Полагаю, gparted и установщики, пользуются parted и сего вопроса просто не ожидают, поставлены вопросом в тупик: parted ждет ответа на вопрос, gparted/установщик вопроса не ожидал и тупо ждет обычного вывода списка разделов. За этим веселым занятием и были застуканы на скриншоте выше.
Если разметку привести к разумному виду, когда станет недвусмысленно ясна используемая разметка, вопрос у parted перестанет возникать и установщики смогут видеть разметку диска.
cfdisk и sfdisk не умеют GPT совсем, только MBR.
fdisk знает про GPT, но не работает с ней.
gdisk, cgdisk, parted, gparted умеют GPT и защитный MBR как часть GPT.
Слишком кардинально. Проще всего взять gdisk и починить разметку. Поскольку фактически используется MBR -- починка будет состоять в удалении остатков GPT.Варианта решения два
Если мятный установщик умеет GPT, можно пойти и в эту сторону, сконвертив gdisk-ом текущий MBR в GPT. Если Mint не сумеет, можно сконвертить обратно, GPT в MBR.
Выбор итогового варианта за зачинателем топика.
LILO такие мелочи по барабану. Разделы видит ядро. LILO спрашивает у ядерного драйвера ФС номера секторов, принадлежащие файлам ядра, initrd, складывает в свой файл (map), запрашивает номер сектора этого файла, прописывает его в загрузчик, записывает загрузчик в самый первый сектор диска (если проинструктировали ставиться в MBR, а не на раздел). Загрузчику в первом секторе отведено 466 байт, остальное из наличных 512 -- место под 4 записи таблицы разделов и 2-байтная сигнатура -- LILO по барабану.А lilo, может видеть [разделы GPT]?
cfdisk и sfdisk не умеют GPT совсем, только MBR.
Здесь после выбора ФС выбирается тип раздела ( посмотрите: вариант ЕЕ - GPT; вариант EF - EFI( FAT 12/16/32) т.е. cfdisk может работать с GPT разделами
да и здесь то же самое
На сарае ... написано, а там дрова лежат. Указанный список -- это лишь расшифровка одного байта "Тип раздела" в MBR.[console]# cfdisk -vcfdisk может работать с GPT разделами
cfdisk (util-linux 2.21.2)
# cfdisk /dev/sda
Warning!! Unsupported GPT (GUID Partition Table) detected. Use GNU Parted.[/console]И следом, конечно, можно уродовать MBR как угодно. Вот только расположенная в конце диска GPT от этого не поменяется.
Понятно, что чем дальше в лес, тем больше дров и степень вероятности заблудиться возрастает по прогрессирующей.
Поэтому в лес я не полезу, задача сейчас немного другая - должна стоять Windows 7 и мне жена оставляет пол-диска на "растерзание"...
Готов начать всё сначала, то есть пререразбить винт заново.
Согласен с этим вариантом:
Снести весь диск напрочь, отключить UEFI и GPT, после чего ставить системы обычным порядком на MBR. Будет работать гарантированно всё.
Только возникает вопрос на счёт Windows 7, как правильно разбить диск для неё, с учётом того, что диск C:\ - системный, диск D:\ - пользовательский.
Это так желательно. Но установщик Windows 7, зачем то создал раздел "Зарезервировано системой". Не очень хочется ему давать возможность заниматься разбивкой
диска впредь. Так вот вопрос, собственно - так ли нужен ей этот раздел, может ли обойтись Windows без него?
Опасаюсь такого варианта - винда заделает диск C:\ разделом "Зарезервировано системой", на диске D:\ пристроится сама...
Что очень не желательно. Если кто в курсе, поделитесь пожалуйста опытом.
cdrw, В данном разделе хранятся загрузочные файлы и загрузчик системы файл - «bootmgr». При этом файлы, хранящиеся в скрытом разделе, непосредственно принимают участие для вызова среды восстановления системы, но сам образ восстановления в этом разделе отсутствует