Альтернативное расположение таблицы записей раздела GPT

731
Juan

Заголовок GPT (обычно в LBA 1) имеет PartitionEntryLBAполе (см. 5.3.2 Заголовок GPT в спецификации). В различных ссылках (таких как запись GPT в Википедии) есть язык, описывающий это поле, которое говорит, что оно должно указывать на LBA 2.

В спецификации сказано: «Первичный массив ввода разделов GPT должен располагаться после основного заголовка GPT и заканчиваться перед первым используемым LBA».

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

Я использую встроенный процессор, который ищет таблицу векторов 4k во втором секторе карты памяти (например, SD). Поэтому я не могу поместить туда записи раздела GPT. Поэтому я хотел бы написать записи раздела GPT после этой таблицы (смещение 5 Кбайт при условии 512 байт секторов). Я думаю, что это разумно, но я не смотрел ни на какие стандартные инструменты разметки GPT (например, parted на linux), чтобы посмотреть, будет ли / как это поддерживаться. Также не смогут ли стандартные загрузчики (например, u-boot) найти таблицу записей разделов в таком месте.

Поэтому мне интересно услышать о практическом опыте с нетипичными местоположениями таблицы записей разделов GPT (т. Е. Не на LBA 2 для основной копии таблицы) с различными инструментами разбиения и загрузчиками. Предпочтение bsd / linux, но мне интересно услышать и о других средах (даже анекдоты о некоторых коммерческих операционных системах).

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

Вы можете ознакомиться со спецификациями UEFI здесь: http://www.uefi.org/specifications . Я смотрел последнюю версию (ревизия 2.4, опечатки C).

У меня пока нет членства в UEFI ( http://www.uefi.org/join ), поэтому у меня нет доступа к форуму там ( http://www.uefi.org/FWOSForum ).

ps Кажется, существует еще более строгое требование (?), чтобы основной заголовок GPT был на LBA 1, даже если StartingLBAв PMBR есть поле (на LBA 0). В спецификации это специально пишется, что StartingLBAполе должно быть LBA 1. Но зачем имея поле, если оно должно быть в LBA 1? Почему бы не позволить заголовку GPT находиться на LBA 10, если ситуация требует этого? Это не является необходимым в моем текущем случае использования, и вопросы на этом форуме несколько риторически (вероятно, лучше задавать на официальных форумах UEFI).

0
Я думаю, что я могу использовать процессор, похожий на ваш. Мне удалось изменить U-Boot, чтобы «правильно» использовать смещение записи раздела, чтобы оставить необходимый регион без изменений. Я также не видел каких-либо инструментов, поддерживающих использование этого поля по умолчанию, что является проблемой, но оно не позволяет пользователям быть укушенными другими инструментами, не поддерживающими его. oscode 7 лет назад 0

1 ответ на вопрос

0
Rod Smith

I could have sworn I'd seen something like this in some hybrid ISO images (the sort used for Linux distributions so that they can be burned to a CD-R or written to a USB flash drive without post-processing); however, I just checked a few and they don't seem to be doing this. Maybe I'm not remembering correctly, or maybe I've just not checked the right ones. I also don't see anything about this in the isohybrid man page -- but I'm not sure this is what's most commonly used to create these images. Still, you might want to follow this lead further than I did....

FWIW, I'm the author of GPT fdisk. It's been quite a while since I've had to touch the relevant code, but a quick review suggests that GPT fdisk should read a disk in which the primary partition table does not begin at LBA 2; however, GPT fdisk does not support changing this location, and I can't promise it would save the table back at the original location even if it could successfully read such a disk. You might be able to hack it to start that table elsewhere for experimentation purposes. In fact, I just gave that a try, but there are a number of places in the code that use hard-coded "1" or "2" values to populate the LBA values, and I didn't find them all in my initial attempt, so I ended up writing the header into the middle of the partition table, which of course was not pretty. If you want to try, look at the gpt.cc file. Start by looking for where partitionEntriesLBA and firstUsableLBA are set -- but some of the relevant constants are in function calls, too.

As to the location of the primary GPT header, I doubt if you could change that. The protective MBR isn't really part of the GPT data structures per se; its purpose is to identify the disk as a GPT disk and to keep GPT-unaware tools from mucking with the disk, not to identify where GPT data structures begin. The StartingLBA field there exists because it's part of the MBR data structure, not because GPT uses it for anything. I suppose it's possible that some tools might use the start point of the MBR protective partition as a pointer to the primary header, but I doubt if a majority would do that. Certainly GPT fdisk doesn't; it hard-codes LBA 1 as the location of the primary header.

If you have more questions about this, you might want to post on the edk2-devel mailing list. Lots of EFI developers hang out there, and it's possible that some of them know of precedents for what you're trying to do, or know of alternative ways to accomplish your goal.

Похожие вопросы