| OSDev http://osdev.su/ |
|
| GRUB2 http://osdev.su/viewtopic.php?f=12&t=647 |
Страница 5 из 5 |
| Автор: | phantom-84 [ 11 дек 2012, 17:33 ] |
| Заголовок сообщения: | Re: GRUB2 |
В тех бинарниках GRUB'а вроде бы не было поддержки разделов вообще, поэтому эксперименты с ними могут и не дать объективной картины. Я проверил на флоппике текущую сборку модиф. GRUB'а - результат такой же, что и на CD. Значения минус 2 и меньше не проверял, т.к. они не могут быть получены в результате трансляции. Если нужно, могу дать мой текущий core.img (получен из-под убунту 10.10 след. командой: grub-mkimage -O i386-pc -o core.img biosdisk part_gpt part_msdos iso9660 fat ntfscomp ntfs ext2; доп. файлы можешь взять из sys-grubldr-2.0-compact-add.zip). Я проверил пропатченный GRUB с текущим core.img на флоппике. Действительно 0-7FFFFFFFh вызывает ошибку, а 80000000h-0FFFFFFFFh трактуется нормально. В принципе я давно знал, что GRUB расширяет номер раздела в двойное слово, чтобы трактовать "невалидное" для обозначения номера раздела значение, как минус 1, а сами разделы нумеровать неотрицательными числами. При желании можно было использовать unsigned char и "невалидное" значение 255, но по каким-то причинам этого делать не стали. По-прежнему непонятно, как у тебя грузится GRUB с первого раздела при любых значениях dos_part. |
|
| Автор: | Yoda [ 11 дек 2012, 22:55 ] |
| Заголовок сообщения: | Re: GRUB2 |
Только что ещё раз проверил бинарный GRUB 1.98 из поставки Debian. Всё так и есть, это поле действительно не влияет на начальную загрузку на флешке с одним разделом Ext2. Проверял и отрицательные значения, и 0, и положительные значения, включая заведомо отсутствующие при любых сдвигах номера разделов, например, 20 или -20. Один хрен - грузится. Но я могу констатировать, что ничего особенно плохого в этом факте нет. Вероятно, в ГРУБе есть какая-то дополнительная проверка на диапазон валидости в некоторых случаях. Может даже и в Дебиановской сборке. |
|
| Автор: | phantom-84 [ 11 дек 2012, 23:26 ] |
| Заголовок сообщения: | Re: GRUB2 |
Думаю, что все-таки лучше разобраться. Предположим, что модиф. GRUB'у передается неправильное значение в "нашем" формате, а он вместо сообщения об ошибке как-то выбирает "системный" раздел и не факт, что правильно. Попробуй сравнить исходный core.img с тем, что получается после инсталляции. Если никаких неизвестных отличий не будет, попробуй передать коду GRUB'а (по адресу 8200h) ноль в ebp и в qword'е по адресу 8200h-12. Может, он перестанет находить "системный" раздел самостоятельно (без корректной подсказки в dos_part). |
|
| Автор: | Yoda [ 12 дек 2012, 00:25 ] |
| Заголовок сообщения: | Re: GRUB2 |
phantom-84 писал(а): Предположим, что модиф. GRUB'у передается неправильное значение в "нашем" формате Разборки с ГРУБ2 на дискете показывают, что значение правильное. phantom-84 писал(а): а он вместо сообщения об ошибке как-то выбирает "системный" раздел и не факт, что правильно. Как же он неправильно выбирает раздел, если грузится? Для более корректной проверки надо создать диск с несколькими разделами и желательно на всех иметь установленные ОС. Тогда можно будет сказать "да, при таком-то значении он загрузился с такого-то раздела". phantom-84 писал(а): Попробуй сравнить исходный core.img с тем, что получается после инсталляции. Исходный core.img и есть файл после инсталляции. Я их беру из директории /boot/grub. phantom-84 писал(а): Если никаких неизвестных отличий не будет, попробуй передать коду GRUB'а (по адресу 8200h) ноль в ebp и в qword'е по адресу 8200h-12. Я абсолютно уверен, что он не проверяет того, что записано ниже границы 8200h. Во-первых, там таблица, а не один элемент по фиксированному адресу. Во-вторых, на него нет внешних ссылок. В-третьих, этот кусок - достаточно самостоятельный модуль и должен быть заменяем. |
|
| Автор: | phantom-84 [ 12 дек 2012, 01:14 ] |
| Заголовок сообщения: | Re: GRUB2 |
Yoda писал(а): Разборки с ГРУБ2 на дискете показывают, что значение правильное. Я имел в виду, что если целенаправленно передавать неправильное значение, то и реакция должна быть соответствующей.Цитата: Как же он неправильно выбирает раздел, если грузится? Это может быть случайностью. Я в общем говорю. Без доказательств затруднительно говорить, что это всегда будет работать правильно. Нужно понять, как именно это работает.Цитата: Исходный core.img и есть файл после инсталляции. Я их беру из директории /boot/grub. Под исходным я подразумевал файл после компиляции (точнее компоновки, осуществляемой grub-mkimage). Отличия между этим файлом и тем, что получается в результате инсталляции, позволят наглядно понять, какие изменения вносит инсталлятор GRUB'а. Может, есть что-то еще, о чем мы не знаем.Цитата: Я абсолютно уверен, что он не проверяет того, что записано ниже границы 8200h. Во-первых, там таблица, а не один элемент по фиксированному адресу. Во-вторых, на него нет внешних ссылок. В-третьих, этот кусок - достаточно самостоятельный модуль и должен быть заменяем. По указанному мной адресу всегда хранится начало первого экстента ядра (того, что загружается по адресу 8200h), т.к. элементы описывают последовательное размещение экстентов и расположены в обратном порядке. Я вроде бы тоже не находил внешних ссылок, но может ссылки формируются как-то по-особому, т.к. адрес по сути статичный. Чтобы как-то обрабатывалось значение, сохраненное в регистре ebp, я вроде бы тоже не замечал (в тех исходниках, что у меня на руках, оно вроде бы затирается). Но ведь эту команду вписали в helper явно с какой-то целью:Код: /* save the sector number of the second sector in %ebp */ movl (%di), %ebp Кстати еще может использоваться поле StartSector (в моей статье я его называю kernelstart(64).kernel_sector), находящееся внутри бутсектора. Адрес тоже статичный. |
|
| Страница 5 из 5 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|