ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Alexandr S. Agranovsky               2:5020/400     18 Dec 2002  23:49:12
 To : All
 Subject : Анатомия /boot/map в LILO
 -------------------------------------------------------------------------------- 
 

 
 
   Hi, All
 
 Hиже - мое исследование в ответ на вопрос в RU.UNIX.LINUX,
 отфорварженое сюда для критики и информации, авось кому
 пригодится, тем более что подобной информации нет в документации
 LILO (только разбиение ОЗУ). 
 
 >> DK> Lilo: у него ведь должен быть "хвост" (не может же 1 сектор держать и
 >> DK> загрузчик, и map для нескольких ядер и ещё менюшку). Где тогда весь этот 
 >> DK> хвост?
 >> "хвост" - это файлы в /boot/*
 
 Я тут малость ошибся. Вот ниже изложение как все на самом деле...
 
 >> в загрузочный сектор пишется расположение map'а, а уже в map'е
 >> все остальное.
 
 Если не вдаваться в детали, то примерно так.
 
 DK> Получается, файл map - единственный файл, который должен быть "непрерывный",
 DK> иначе, его трудно зачитывать, так?
 
 Эх,  достал ты меня :). Пришлось взять сырцы, вывод lilo -v5, od
 /boot/map а также od /tmp/boot (с предварительным dd if=/dev/hda
 of=/tmp/boot bs=512 count=1)
 
 Вот что выяснилось.
 
 1.  Загрузочный  сектор (512 байт, завершающая сигнатура 55AA) в
 бутсектор  пишется загрузочный код вместе с четырьмя указателями
 на  сектора  (в  сырцах  смотреть  структуру  BOOT_PARAMS_1    в
 common.h)   Из  них  по  существу  вопроса  имеют  значение  два
 последних keytab и secondary.
 
 В  моем  случае  (здесь  и  далее  цифры даны для того, чтобы не
 запутаться  в  указателях)  они  оказались  равными  0x4dc019  и
 0x4da8bb,  что  соответствует  смещениям  18944 (0x4A00) и 10752
 (0x2A00)  от  начала  /boot/map  (согласно выводу lilo -v5). Уже
 видно, что /boot/map - не "непрерывный".
 
 2. указатель secondary указывает на таблицу секторов, в которых
 размещен собственно код загрузчика.
 То   есть   в   секторе   со  смещением  LBA=0x4da8bb  оказались
 записанными  числа  0x004da8ab,  0x004da8ac, 0x004da8ad и тд. до
 0x004da8ba  (соответствуют  смещениям  от 2560 (0x0A00) до 10752
 (0x2800)  в  файле /boot/map). В секторах с номерами от 0x4da8ab
 до 0x4da8ba оказалась копия /boot/boot-menu.b
 
 Итак, с расположением кода "хвоста" aka second-stage loader -
 разобрались. 
 
 3.  указатель  keytab указывает на сектор 0x4dc019 (aka смещение
 18944  в  /boot/map).  Внутри этого сектора нашлись указатели на
 0x4da8a7,  0x4da8a8 и 0x4da8a9 - это оказались байты в /boot/map
 по смещению 512 (0x200), 1024 (0x400) и 1536 (0x600))
 
 4.  В секторах 0x4da8a7, 0x4da8a8 и 0x4da8a9 записаны собственно
 варианты  выбора LILO, по 7 шт. на сектор, число секторов задано
 жестко  при  компиляции LILO. Каждый выбор содержит указатель на
 соотв.  сектор,  где (для image=) хранится таблица всех секторов
 загружаемого образа.
 
 Таким   образом,  boot-сектор  (а  впоследствии  и  second-stage
 loader),  имея  в  самом  начале  всего  два сектора, постепенно
 раскручивает  эти  данные,  на  каждом  шаге  получая  четкие  и
 недвусмысленные указания, какой сектор на каком шагу грузить.
 Кстати,  по вопросу о перезаписи данных. lilo при вызове сначала
 резервирует  в начале /boot/map место под выбор по умолчанию (со
 смещения  0),  данные  (с байта 512 (0x200)) под варианты выбора
 (число  секторов  заранее  задано  при  компиляции!),  почему-то
 пропускает  1  сектор  (с  байта  2048 (0x800)), затем пишет код
 second-stage  loader  (со  смещения 2560 (0xA00)), как только он
 записан,   заполняет  таблицу  расположения  этого  second-stage
 loader  (по смещению 10752 (0x2A00)), затем постепенно заполняет
 таблицы   выбора  и  размещения  всех  образов  (с  байта  11776
 (0x2E00)),  среди  которых  затесался  chain.b (он был записан в
 map,   как   только   выяснилось,   что  есть  other=),  таблицы
 закончились  на  байте  18944  (0x4A00),  где, после записи всех
 предшествующих   байтов,   подбит   итог  по  секторам,  которые
 отображены  на  байты  со  смещениями  от  512  до 1535 (а также
 имеется  таблица клавиатурных перекодировок). После записи этого
 сектора  становится  известным  и  его  местоположение,  которое
 пишется в бутовый сектор как указатель keytab.
 
 а вот и таблица-резюме (все числа - для моего /boot/map, у вас
 они могут быть другими)
 *0x0000 0x0200   default selection
  0x0200 3*0x200  menu data (в т.ч. ссылки на таблицы образов)
  0x0800 0x0200   reserved (?)
  0x0a00 0x2000   second-stage loader (boot-menu.b)
 *0x2a00 0x0200   таблица размещения секторов second-stage loader
  0x2c00 0x0200   reserved (?)
  0x2e00 N        таблицы образов:
   .... (? - не совсем ясен формат для задания other=, ну да фиг с ним)
     start        0x0200     командная строка
     start+0x0200 0x0400(?)  таблица размещения загружаемого образа...
     
  (0x4A00) 0x0100  таблица перекодировки клавиатуры
 *(0x4B00) 0x0100  некоторые вспомог. данные, включая физическое
                    размещение секторов menu data
  (0x4E00)        конец файла /boot/map
 
 Физическое размещение помеченных(*) секторов пишется в boot sector.
 
 - ---
 Alexandr S. Agranovsky llb@udmnet.ru
 --- ifmail v.2.15dev5
  * Origin: LLB, LLC (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор