LevT
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Предлагаю обобщенную схему стадий загрузки. Комментарии-исправления приветствуются. Цель - уйти от однобокого линуксоидного или PEшного сектантства 1 - биос(фирмваре) - монолитный, частично модульный (автоподгрузка модулей например вставных рейдов должна быть поддержана разработчиком матери, а для сборщика систем не владеющего hex хаканьем железа расклад типа 50/50: "модуль либо заработает, либо нет"). Есть попытка открытого фирмваре coreboot (имхо, этот пациент скорее мёртв чем жив). 1a) mbr (gpt, uefi?) загрузчик стартуемый из фирмваре, и в свою очередь запускающий либо 1б) либо сразу что-то из следующей стадии) 1б) (для разбитого на партиции устройства) 1/3ntldr, grub stage1, xxxlinux... - расположен на бутовом разделе (конкретизированном на стадии1б). В случае бутового устройства без разделов совпадает с 1a) 1.5) - недоос с монолитным фиксированным минидрайвером загрузочного устройства и фс (в случае винды также читалкой реестра) Это то, от чего сейчас уходят и линукс, и винда 2/3ntldr, grub stage1.5... варианты isolinux-syslinux-pxelinux отчасти grub4dos 2) - мини-ОС/расширитель фирмваре (уровень абстракции железа, пригодного для дальнейшей загрузки.) В курсе таблиц разделов и файловых систем, продвинутые - понимают неизвестные биосу варианты загрузки с USB и прочих стораджей, также из сети. статические: обработчик boot.ini в xp (3/3ntldr), менюшки прочих загрузчиков динамические: grub stage2, отчасти grub4dos - монолитные grub4dos - умеет патчить в памяти образы и проч. файлы-ресурсы! bootmgr - проприетарный, степень модульности неизвестна. plop - проприетарный, заточен для расширения возможностей USB. gpxe и grub2 - модульные, открытые, скриптуемые. Первый заточен под всевозможные варианты сетевой загрузки, второй обещает универсальность. 3. OC В зависимости от конструкции ядра два типа старта: 1. pnp - genkernel с модулями (требует 1.5 или 2 стадию для доступа к модулям и их конфигам, либо запускается из инициализирующей embedded системы) 2. embedded - монолитное ядро с критическими дровами (в принципе может заводиться прямо из 1, минуя 1.5(?) и 2 стадии). 3a) Старт типа embedded в специальных целях - когда нужна именно фиксированная среда, которую юзеру сложно испортить. 3б) В остальных случаях ось с ядром типа embedded используется для бутстрапа следующей, более продвинутой, оси - после исполнения некоторой инициализирующей-выбирающей логики. Осложнение: вылупившаяся система должна содержать все дрова (стораджа и-или сетевого псевдостораджа, а также файловых систем), критичные для физического доступа к собственному телу. Скрипты инициализации (или выбора) потомка, а также модули _потомка_ могут быть намертво вкомпилированы в образ оси-родителя, а могут конфигурироваться или целиком браться из ресурсов, расположенных - на доступном носителе (подсунутых, pushed) и считанных без авторизации - в сети (вытянутых, pulled, в частности клиентом RIS/WDS в зависимости от результата авторизации AD *) 3б-1) "Матрёшечный" вариант, когда 3б) повторяется рекурсивно: пример загрузка с PXE. 3б-2) Наконец, рекурсия может окончиться подбором ресурсов (модулей), инициализацией динамических параметров и финальным запуском модульного ядра. Ещё недавно это была самая гибкая техника - но в свете развитой 2 стадии избыточная: вся логика может быть перемещена туда, а рекурсия сведена к минимуму или вовсе выкинута. 4. OC с файла-образа (рамдиска, iso или иного контейнера), расположенного на CD, USB или ином загрузочном устройстве, выбранном на стадиях 2) или 1) 4а) В образе ядро типа еmbedded . Осложнение: в ядро такого образа должны быть вкомпилированы дрова того стораджа, откуда он реально грузится (Похоже на 1.5 стадию, не правда ли?) 4б) В образе модульное ядро. Осложнение: его необходимо выбрать и-или динамически сконфигурировать с учётом фактического загрузочного устройства. Здесь может помочь только развитая "мини-ОС" (2 стадия): она должна определить фактический (физический) путь загрузки и снабдить пациента нужными ресурсами (модулями, дровами), скриптами инициализации и параметрами стартовой конфигурацции. Упрощая картину в свете развития 2 стадии в "мини-ОС": если нужно запустить ось с модульным ядром - на 2 стадии выбираем компоненты, настраиваем, инициализируем и сразу стартуем без embedded стадий если нужно запустить образ типа embedded - на 2 стадии выбираем из доступного арсенала, который именно. (Например, можем выбрать pxelinux.0 или startrom и оттуда забутстрапить всё остальное по сценарию 3б-1) Высший пилотаж здесь - подбор ресурсов (модулей и параметров конфигруации) модульных ядер и-или конструирование сложных embedded образов на лету, под управлением сигналов с более простого агента, уже запущенного на целевом железе. Таким агентом в идеале может и должна быть сама мини-ос (естественно, скриптуемая). Запускать для этой цели агента типа embedded - только избыточное усложнение процесса. Коренное новшество текущего исторического момента -- возможность истинно динамической (скриптуемой) логики настройки системы-потомка из мини-ОС 2 этапа. Упд. *) В домашних условиях городить авторизацию для доступа к загрузочным ресурсам смысла я не вижу. Однако промежуточные оси типа embedded логично использовать как носители ключей доступа (или частей многофакторных систем доступа) к публичным и корпоративным ресурсам. А также политик, соблюдение которых вытекает из факта принадлежности юзера к тем или иным группам (типа "хочешь наше SSO - изволь регулярно проверяться антивирем"). | Всего записей: 17126 | Зарегистр. 14-10-2001 | Отправлено: 20:54 23-11-2009 | Исправлено: LevT, 12:23 26-11-2009 |
|