» Скрипт. загрузка, сборка на лету, установка образов в меню

Установка оси на устройство XY.



1. Ось должна уметь грузиться с устройства XY (вариант: по протоколу ZZ из сети).
Возможно, что такая загрузка не является штатной с точки зрения ее разработчиков.

Варианты действий:
a) установить ось на обычный диск, модифицировать и перенести образ на устройство XY (вручную или с помощью кем-то созданного инструмента)

б) модифицировать инсталлятор так, чтобы ось устанавливалась уже модифицированная
б-1) на обычный диск
б-2) на устройство XY
(Штатный инсталлятор сам представляет собой скрипт или гуй, исполняемый в некоторой оси, не обязательно совпадающей с целевой и имеющей свои отдельные особенности)

Каждый следующий вариант на порядок более трудоёмок и требует больших знаний и опыта, чем предыдущий.


Суть модификации оси - предзагрузка критических модулей (драйверов) устройства XY.

Пример: драйверов "USB" не существует; существуют три (скоро будет больше) физических разновидности этого интерфейса и многоуровневый стек зависимостей, в каждой оси свой.

Мало того, железные компоненты USB имеют баги: кривые участки надо детектить и обходить софтом (и в загрузчике, и в драйвере).
Потому загрузка из сети по чисто софтовому протоколу (при условии надежной реализации нижележащего сетевого стека в загрузчике) - вещь более надёжная, чем загрузка с USB.


2. Один из загрузчиков должен уметь инициализировать устройство XY в качестве загрузочного и передать его дальше по цепочке родному загрузчику оси и ее ядру.

Grub4dos -хорошее и годное средство решения подзадачи 2), а не самоцель.
Без 2-й подзадачи задача в целом не будет решена.

Но Grub(4dos) - лишь одно из возможных средств, не обязательно лучшее. Нужна площадка, посвящённая выбору и планированию последствий сделанного сейчас выбора.

Эта тема - попытка создания такой площадки.

Варианты загрузки винды по HTTP, на сегодняшний день

http://sanbarrow.com/phpBB2/viewtopic.php?p=6854

Добавлено:


Виндовая часть темы раскрыта, кажется, полностью здесь:

http://sanbarrow.com/phpBB2/viewforum.php?f=68

Вот тут
http://forum.ru-board.com/topic.cgi?forum=35&bm=1&topic=12660#1 [?]
упёртая с трудом демка коммерческой софтины.

Управление сетевой раздачей загрузочных образов (DOS и все разновидности PE), установкой и переустановкой осей, запуском тонких клиентов.


ПЛЮСЫ: Дохрена скриптов с потрохами наружу (загруз. образы билдятся из файлов, которые предназначены для ручной правки). PDF-доки с перечислением всех конфиг. файлов и их роли.

МИНУСЫ: Нет спецификаций протокола управления (если интересно - придётся снифать). Нет ключей к виндовой управлялке; возможно и какие-то бинарники только в демоверсиях.

Компьютер - это железо плюс софт. Железо - это процессор, память и периферия. Процессор исполняет софт, загруженный в память с периферийного устройства, избранного загрузчиком.

В любом железе есть фирмваре (биос) - специальный софт, запускаемый процессором сразу после старта, до того, как он узнал о доступной периферии. Фирмваре хранится в постоянной памяти, обновляется программатором или спец. процедурами. Для своей инициализации оно использует конфигурацию, сохранённую в nvram (то есть конфиг оказывается прямо в памяти, для доступа к нему не требуется инициализации никаких необязательных устройств).


Введём понятие предзагрузчика. Фирмваре это прошитый в железо предзагрузчик следующего загрузчика. Задача предзагрузчика - старт следующего загрузчика, более развитого (в зависимости от точки зрения, являющегося bios extender/расширителем фирмваре или мини-операционной системой).


Процесс срабатывания предзагрузчика:

1) определение периферийных устройств, необходимых для доступа к следующему загрузчику (или к ОС) и к его конфигурации.
2) инициализация хранилища конфигурации и её получение.
3) доступ к хранилищу следующего загрузчика (или ОС), его загрузка, инициализация и передача ему управления.


Доступ предзагрузчика к конфигурации и к телу загрузчика может осуществляться либо сразу через сетевое железо посредством сетевого протокола, либо через железо стораджа, посредством опознавания разбивки диска на разделы, выбора загрузочного раздела и минидрайвера файловой системы.

Сторадж сейчас всё чаще виртуален, и также реализуется сетевым протоколом. DAS (непосредственно подключенный диск) - реликтовая технология. Современный сторадж - сетевой (NAS или SAN)


Цепочка грузящих друг дружку загрузчиков оканчивается загрузкой операционной системы. Считается что полноценная ОС должна располагаться на блочном RW устройстве, чтобы сохранять конфигурацию своих сервисов - не говоря о драйверах/модулях ядра - в одном контейнере со своими исполняемыми файлами (т.е. в своей загрузочной фс с доступом на запись).

Но... перечитайте последнюю фразу. Это ведь всё НЕОБЯЗАТЕЛЬНО! Тут каждая деталь - притянутое за уши наследие трудного прошлого, когда компьютеры были обособленными и могли полагаться только на локальные диски. В эпоху сетей, и особенно сетей хранения данных, это представление - дремучий атавизм, крайне обременительный в поддержке, и тем более затратный, чем больше дешёвых железок под боком требуют нашего внимания.



Выводы:

1) Загрузка из сети ПРОЩЕ, ЧЕМ С ЛОКАЛЬНОГО ДИСКА - если избавиться от лишней эмуляции (блочного устройства, таблицы разделов и файловой системы раздела) при загрузке.

2) Конфигурация следующего этапа вытягивается ПОФАЙЛОВО (точнее даже посимвольно) и совершенно независимо от расположения самого загрузочного образа. Достаточно RO доступа.

3) По инерции считается, что доступ к окончательно загруженной оси должен быть блочным и RW - но ЭТО НЕОБЯЗАТЕЛЬНО, если сохранять конфигурацию её драйверов/модулей ядра и сервисов отдельно от загрузочного образа. Цена такого выбора - необходимость регулярной перестройки загрузочного образа (проблема уже решается многослойными файловыми системами и основанными на них дистрибутивами ).


4) Альтернатива многослойным ФС - сочетание подпунктов
4.1 тщательно разработанная система внешнего конфигурирования образа.
4.2 выбор наиболее подходящего образа из расположенного в сети "склада готовых изделий" или его автоматическая заказная сборка, по требованию предзагрузчика.

5) Если многослойная фс неизбежно зависит от платформы (линуксовые и PE дистры живут в параллельных мирах), то 4.1 может быть продуман, а 4.2 и реализован единообразно (платформо-независимым образом).
Но и у многослойных фс есть преимущество: с такой фс можно юзать (почти) не модифицированную ОС, продолжающую думать про себя, что она грузится и берёт конфиг с единственного блочного RW загрузочного контейнера. Так что многослойные ФС - костыль на переходный период, пока не распространились модифицированные для истинно сетевой загрузки оси.


6) Длина цепочки предзагрузчиков-загрузчиков поддаётся сокращению и должна быть сокращена, без ущерба для гибкости выбора загружаемой оси и её функционала.
См. (U)EFI.

"Проблема двух разных драйверов" для одного устройства, отмеченная в википедии - неустранима, доколе существует многостадиийная загрузка (то есть пока ОС не прошита в фирмваре и следующее ядро выбирается в рантайме, после старта железки).

Предзагрузчику нужен доступ к телу ОС, а ОС нужен доступ к собственному телу.

Если бы EFI не был собственнической примочкой интела - он был бы естественным кандидатом на роль универсальной ОС. А Coreboot не жилец потому, что интел не делится спецификациями, дескать, вызовы SMI секретны: иначе TPM по мнению интела будет недостаточно "trusted"

многослойная файловая система - это UnionFS (Aufs и т.п.) в линуксе.


В винде подобное сконструировал Ulli http://sanbarrow.com в своей МОА.

Что-то подобное достигается также с помощью монтирования wim (кажется). Рано или поздно - когда дойдут руки у самого разобраться - я напишу об этом обзорный пост - но предпочитаю, чтобы это сделал кто-нибудь ещё.

подписался

Раньше я плодил связанные темы, теперь попробую поступить иначе. Предлагаю к обсуждению:

Модификация винды, линукса и проч. операционных систем для непредусмотренных способов загрузки


Желаемая последовательность загрузки может быть не предусмотрена:

1) инсталлятором конкретного экземпляра оси
2) билдером конкретного образа
3) разработчиком дистрибутива.


Грузить оси нам надо:

1) с рамдисков сторонних (пред)загрузчиков,
2) с непредусмотренных разработчиком устройств (например с USB или по сетевому протоколу, или из шифрованных контейнеров)
3) на другом железе (включая виртуальное железо гипервизоров).


Есть похожие темы о клонировании только винды; юниксоиды не любят клонировать свои оси, а любят делать tar или dump/restore
- а загрузочный путь конкретизируют либо руками, либо доверяют разработчику инсталлятора.


Клонирование не совсем тот термин, предлагаю обсуждать универсализацию оси.

Ценность имеет перенос настроенной конфигурации сервисов для исполнения на другой платформе (включая виртуальные). Неизбежная подзадача, имеющая самостоятельную ценность - загрузка системы с загрузочного пути, не предусмотренного разработчиками.


Известный мне на текущий момент чемпион-универсал - Ubuntu 9.10. Конкретный установленный штатным образом ее экземпляр грузится без модификации, одинаково успешно под многими гипервизорами, с каналов USB, вариантов SATA и виртуального PATA в своём загрузочном пути.

Цель данного направления темы - допиливание до аналогичного состояния прочих осей (точнее, средств их инициализации и конфигурации загрузчиков) и дальнейшее расширение возможностей их инициализации-конфигурации.

Универсализация операционной системы - действие, обратное её инсталляции.

Инсталлятор уточняет конфигурацию софта в соответствии с конкретным оборудованием (включая загрузочный путь).
Этого требовала эпоха тормозных компов, оставшаяся в прошлом. Сейчас мы можем позволить себе пожертвовать выигрышем (всё более эфемерным) ради универсальности.

По сути, не надо делать нового: надо не доводить до конца процедуру "инсталляции"!


Практически: либо создавать новый класс "универсальных инсталляторов", либо бороться отчасти с результатами деятельности штатных инсталяторов (конкретизацией загрузочного пути).

Реальный пример универсального инсталлятора - инсталлятор Убунты 9.10.


Добавлено:

Частные случаи универсализации:

- "интеграция драйверов"
- разработка дистрибутивов и лайвцд
- автоматизация инсталляторов
- ...


То есть: ничего нового, сообщество давно и успешно занимается универсализацией - но фрагментарно, "не успевая разглядеть леса за деревьями". Предлагаю это осознать и довести дело до конца систематическим образом.


Добавлено:


Инсталлятор делает несколько вешей:

- планирует местонахождение корневой ФС
- настраивает разметку RW стораджей (локальных и предоставленных сетью хранения данных)
- создаёт или модифицирует существующие файловые системы, желательно - разворачивает универсальный образ
- настраивает загрузчик (собственный и/или уже существующий)
- конфигурирует сервисы
- конкретизирует загрузочный путь и автозагружаемые модули
- ...


Универсальный инсталлятор делает всё то же самое, кроме выделенного курсивом пункта. Забота его разработчиков обратная: автозагрузить максимум загрузочных модулей, не допустив конфликта между ними.



Добавлено:

Подчёркиванием выделена точка рекурсии. "Универсальный образ разворачивает универсальный образ".
Рекурсию желательно сократить.

Рекурсия осмыслена только в перспективе bootstrapping: "образ одной системы разворачивает образ другой системы", "разворачивает несколько образов разных систем - по выбору, интерактивному или автоматизированному, или сразу целое загрузочное меню".



Добавлено:

Включение приготовленного образа в определённый загрузочный путь - частный случай инсталляции. Сейчас это самое действие часто осуществляется в форме локального копирования образа и включения его в меню grub4dos.

Итак, у нас есть два пути:
1) Универсальные инсталляторы - рассмотрены выше

2) Универсализация продуктов жизнедеятельности штатных инсталляторов.
Предлагается: к каждому недостаточно универсальному штатному инсталлятору прицепить универсализующие пост-инсталл скрипты.

Когда-то установка единичного линукса была доступна немногим гуру - и многие из них не считали нужным оформлять свои познания и навыки в виде публичных How-To и программ-инсталляторов.

В том же состоянии нынче находится мультизагрузка с использованием grub2, grub4dos, gpxe, xyzlinux и т.п.


Точнее, в состоянии даже худшем: за дистрибутивами линукса стоят коммерческие фирмы, а за мультизагрузчиками даже в перспективе не просматривается никого, кроме заинтересованных пользователей.

"Спасение утопающих - дело рук самих утопающих".


Инсталляторы бывают:

1) интерактивными / автоматизированными (например файлом ответов).

2) более или менее универсальными
Степень универсальности может быть разной: например учитывать или не учитывать варианты сетевой загрузки. Или, скажем, USB 3.0 в загрузочном пути

тут тоже две шкалы:

2.1 - внутренняя универсальность - всякие необычные блочные устройства, с которых должна грузиться рутовая ФС с помощью штатных драйверов целевой ОС. (Нынче в моде писать такие драйверы поверх абстрактного SCSI, но в старых осях на этом месте зоопарк)

2.2 - внешняя универсальность - способность мультизагрузчика подсунуть целевой оси эмулированное блочное устройство с содержимым её корневой ФС. Поддержанная содержимым образа ОС, которое нужным образом изменено.

То есть: внешняя универсальность подразумевает наличие внутренней.


3) единичными / массовыми
Массовые инсталляторы бывают:

- сетевыми (установка сразу нескольких экземпляров системы на несколько компов, например, с использованием мультикаста) и

- мультизагрузочными (установка сразу нескольких универсальных образов разных систем в одно загрузочное меню).


Поскольку инсталлятор системы в раздел локального диска (т.е. на блочный RW сторадж) объект известный и всем знакомый, назовём мультиинсталлятором установщик сразу нескольких RO образов в единственное загрузочное меню.

Повторяю: пока ограничиваемся установкой RO образов, нескольких разных, в меню единственного загрузчика.


Функции мультиинсталлятора:

- планирует загрузочный путь к каждому из устанавливаемых образов
- настраивает разметку RW стораджей (локальных и предоставленных сетью хранения данных)
- создаёт или модифицирует существующие файловые системы; желательно - разворачивает универсальный образ
- настраивает загрузчик (декларативное меню и процедурные скрипты).
- перестраивает образы, гарантируя их загрузку с конкретного загрузочного пути, либо выбирает подходящий комплект со "склада готовых изделий"
- ...???

Чем отличается линукс, установленный вручную в середине 1990-хх гг. и нынешний, установленный с помощью инсталлятора и сопровождаемый популярными How-To?

Первый - не поддаётся поддержке: цена только уточнения конфигурации, вызвавшей проблемы, является запретительной. Разбираться в этом готовы лишь фанатики, красноглазые и ...безответственные.


Так выпьем же за то, чтобы были созданы мультиинсталляторы - которые решат аналогичную актуальную проблему применительно к настройке меню популярных загрузчиков!

Проект является интеграционным, в интересах всех нас-конечных потребителей: я не вижу за ним никакого спонсорского потенциала (может быть, его смогло бы поддержать объединение сообществ gpxe и syslinux... если бы они сами располагали хоть какими-то деньгами)

Разработка плагинов к PE - тоже не что иное, как разработка инсталляторов.

Главная проблема этой деятельности - колоссальный разрыв в компетенции между типичным заказчиком и успешным разработчиком.

Единственное спасение - отчуждение разработок в общее достояние (создание "склада готовых изделий"). Это давно делается ("плагины BartPE" и т.п.)... но при смене платформы все наработки идут прахом.


Выход - выбрать/разработать платформу с учётом такой цели проектирования, как переносимость плагинов. Не забывая об ограниченной, по нашим временам, ценности отдельных образов: людям нужны МУЛЬТИинсталляторы.

Переносимость может достигаться с помощью недоинсталляции. По этому пути пошел разработчик MOA 2.* (все его изобретения - это эксперименты с многостадийной инсталляцией.)

Линуксы и универсализация.


В одних дистрибутивах initramfs зависит от конфигурации конкретного железа. Таковы Fedora/Redhat, где команда mkinitrd вызывается автоматически при установке или обновлении ядра и результат содержит дрова только того железа, которое присутствует в системе (а программу lvm только если LVM используется...)

В других дистрибутивах, таких как Debian Lenny, initramfs универсальный из коробки!

Источник

Цитата:

перестраивает образы, гарантируя их загрузку с конкретного загрузочного пути, либо выбирает подходящий комплект со "склада готовых изделий"

Всё это похоже на бред! Представьте себе предприятие с сотнями компов,
которые используют специализированный софт и их системы переваливают за 10 гиг.
Причем у компов железо разное. И утром при загрузке все начинают грузиться
по сети с конкретного загрузочного пути. Это какой же надо иметь сервер
и сеть, чтобы обеспечить быструю загрузку всех сразу. Или может предложите
растянуть всё это до обеда? И какой коллектив спецов надо держать,чтоб
обеспечить подходящие комплекты. Перестаньте бредить! Это утопия и к реальной
жизни не подходит никаким боком. Во всяком случае сейчас. Лет через 10-20
может прогресс и сможет допустить такое. Сегодня это абсурд.
Всего доброго!

Вот здесь о том, как сделали линуксоиды (OpenSuse, KIWI): http://habrahabr.ru/company/scalaxy/blog/87312/


Хорошо бы обобщить. Сначала хотя бы на [почти] любой линукс. А затем подумать и про венду.

Локальный смысл менеджера томов - в преодолении ограничений MBR-разметки "дисков".
Частично этот смысл утратится с переходом на GPT-разметку, так или иначе вынужденным в связи с 2TB пределом MBR-размеченных "дисков"

Разметка "дисков" на разделы-партиции - это то, что способны интерпретировать аппаратная часть компьютера (точнее, его BIOS, UEFI или иного сорта фирмваре, с целью передать управление загрузчику оси) и загрузчики осей (с целью найти подходящую файловую систему, откуда можно взять необходимые для дальнейшей загрузки ядро и конфиги).

Подробнее тут


Единственное, что нужно операционке для старта - чтобы её загрузчик смог получить доступ к ядру и конфигам. Локального стораджа может не быть вовсе, включая псевдо-локальный (предоставленные SAN блочные девайсы).

Линуксу давно достаточно NAS-стораджа для бездисковой работы, пишут, что восьмая винда приобретёт аналогичную способность.

Micr0soft собирается предложить навязать "решение" рассмотренной здесь проблемы в своём обычном духе

В восьмёрке разделы доступных на сетевых шарах VHD станут пригодными для обработки менеджером томов и монтирования.

Следующим шагом они смогут закопирайтить конфигурацию блочного стораджа внутри проприетарного фирмваре (и допускать админа ОС к этим операциям дозированно, в зависимости от купленной лицензии).




Добавлено:
Сетевую аутентификацию будет осуществлять тоже фирмваре, ага. Спасут нас от лишних знаний и возможностей навсегда.

Добавлено:

То бишь windows-way на ближайшее будущее - это проприетарное упрощение вот этого

http://xgu.ru/wiki/NAS
http://xgu.ru/wiki/SAN

Вместо того (файлового) и другого (блочного) доступа к сетевому стораджу юзерленд винды будет работать с томами, собранными предзагрузчиком из VHD. А контроль доступа к VHD и интерпретацию разметки блочного стораджа вынесут в фирмваре и защищенное (в том числе и от владельца компа) ядро.

Опять нас хотят заставить платить за каждый чих и желание что-то поменять на нижних уровнях модели.
http://xgu.ru/wiki/MultilayerStorageModel


Добавлено:


Идея-то разумная в смыле борьбы со сложностью и дурной рекурсией, но я бы определённо предпочёл свободные её реализации.

Это для частников и сохо. А для энтерпрайзов остаётся SAN с попилами и откатами специальными управляльными драйверами под System Center

"За лицензию на право управления своими железом и софтом надо платить".
И скоро все позабудут, что так было не всегда.

по новой осилил сетевую win ram загрузку winpe 1.x
основное ядро + драйвера сетевых и RAID (winpe 1.x не умеет их "доопределять") по pxe
программы потом монтируются по SMB

Dimsoft
Передохнёшь - напиши здесь howto, хорошо?

запуск по сети winpe RusLive
в корень tftp сервера :

NTLDR - переименовываем PXELDR из iso от Ruslive
winpe.wim - переименовываем I586\BOOTDI.WIM
startrom.n12 - достаем из windows xp
winnt.sif

Код:
[SetupData]
BootDevice="ramdisk(0)"
BootPath="\i386\System32\"
OsLoadOptions="/fastdetect /minint /rdimageoffset=8192 /rdimagelength=3161088 /rdpath=winpe.wim"

[wimain]
systrim=1

https://github.com/puppetlabs/Razor/wiki

Добавлено:

http://cuddletech.com/blog/?p=779

Добавлено:

https://gist.github.com/2234639

http://forum.ru-board.com/topic.cgi?forum=55&topic=6444&start=1940#19

State considered harmful
A proposal for a stateless laptop
Joanna Rutkowska
December 2015
http://blog.invisiblethings.org/papers/2015/state_harmful.pdf

Взято отсюда https://habrahabr.ru/company/dsec/blog/278549/#comment_8793877