virtual bootscripter

Вопрос сначала теоретический от новичка в генту

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

Реально ли с помощью ebuild-ов обойти разницу между распространёнными загрузчиками (хотя бы семействами isolinux и grub/grub4dos)? Даже структура директорий различается, не говоря о синтаксисе опций.

Вот здесь я только что попытался спросить совета у разработчика sysresccd

http://www.sysresccd.org/forums/viewtopic.php?f=14&t=2857&p=8700&sid=71cfabc61fee2a0cfce20b92c6356dd8#p8700

.

Мне нравится эта идея. Поясните, как бы вы хотели пользоваться virtual bootscripter-ом после его создания. Описание шагов и параметров подскажет, как реализовать эту абстрактную задачу.

Это подпись, которую невозможно истолковать неправильно

Излагаю простейший минимум

Излагаю простейший минимум (хотелок на самом деле больше, но с этого по-любому надо начинать)

На входе:

1) набор ресурсов (не уверен, какие именно нужны ограничения на их размещение, и нужны ли они вообще)

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

Не уверен, что стоит изобретать очередной ни на что непохожий формат описания. Можно взять за основу формат grub4dos (кажется он полностью перекрывает grub), или isolinix, может быть, grub2.

На выходе:

легкий вариант - конфиги загрузчиков
средний вариант - также структура директорий с разложенными ПОД КОНКРЕТНЫЙ ЗАГРУЗЧИК ресурсами
тяжелый вариант - полностью установленный загрузчик.

Предложение по тестированию:

-берем известные загрузочные среды (с известных LiveCD),
-пишем руками реверснутый исходник
-воспроизводим оригинал

ПРОГРАММА-МАКСИМУМ

1)Стандартизировать структуру директорий с ресурсами для разных загрузчиков - чтобы последующее скриптование не зависело от выбора конкретного загрузчика.

2) Свести к "единому исходнику" варианты загрузки одного и того же:

из файловой системы,
из сжатого образа (типа sysrcd.dat)
из сжатого образа упкованного в iso

- локальной (с диска, с флешки, с сидюка)
- сетевой (PXE, iSCSI...)

3) Навести ревизию и исключить не имеющие смысла избыточные варианты. Объявить неподдерживаемыми и ОБОСНОВАТЬ почему (как тот же результат достигается из нашей универсальной инфраструктуры).

.

1) Заполните пропуски: "Когда будет создан virtual bootscripter, я смогу .... и всё готово. А сейчас мне приходится ... чтобы сделать то же самое." Раскройте разницу между "сейчас" и "потом" именно в такой форме, если не затруднит
2) Предложение по тестированию радует. Добавьте примеров и ссылок, чтобы я мог взять и сделать что-то конкретное, и потом запостить ссылки с результатом, из которых любому видно, что оригинал воспроизведён без ошибок.

Это подпись, которую невозможно истолковать неправильно

1) Заполните пропуски: "Когда

1) Заполните пропуски: "Когда будет создан virtual bootscripter, я смогу .... и всё готово. А сейчас мне приходится ... чтобы сделать то же самое." Раскройте разницу между "сейчас" и "потом" именно в такой форме, если не затруднит

Очень здраво. Собираюсь подойти ответственно.

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

.

Давайте начнём с малого.

Это подпись, которую невозможно истолковать неправильно

1)

Я смогу поддерживать единственный исходник своего загрузочного меню - и билдить из него конфиг загрузчика по выбору либо для syslinux, либо grub2dos. В перспективе также для прочих загрузчиков, включая ныне несуществующие или недоделанные (особо привлекает обещанная в grub2 фича - скриптование).

Сейчас нечастая работа над слиянием-модификацией загрузочных меню требует исследовательской работы, результат которой невозможно зафиксировать в виде "единого исходника". Я вынужден изучать-вспоминать два совершенно разных декларативных синтаксиса (не говоря о диалектных особенностях между syslinux и isolinux, grub4dos и grub...) Особенно - и даже запретительно - затратным занятием мне представляется попытка внешнего скриптования syslinux загрузки. Я предвижу обесценивание любой работы, проделанной в этом направлениии, с переходом на нативно скриптуемый загрузчик (предположительно grub2).

Т.е., грубо говоря, вы хотите

Т.е., грубо говоря, вы хотите разработать свой, третий синтакс и набор конвертеров из него в существующие синтаксисы конфигов различных загрузчиков?

P.S. Затея единого ебилда, имхо, дурь - его мейнтейн будет головной болью, да и interactive ebuild - тоже не очень приятная штука. Мой совет - ограничится именно написанием набора конвертеров и одного враппера, который будет определять установленные загрузчики, конвертировать ваш формат в их формат и запускать hardcoded комманду перепрошивки загрузчика (i.e. dolilo для lilo или ничего для grub).
P.P.S. Да, ну и к ебилдам это не имеет никакого отношения. Лучше это писать на чем-нить с хорошей поддержкой regexp (мой выбор: perl, но отдельные змееводы наверняка начнут спорить). Можно и на Си. На баше не стоит - слишком уж тормознуто и громоздко выйдет.

P.P.P.S Я бы на вашем месте поставил бы еще задачу супер-максимум - сделать свой универсальный загрузчик, который заменит весь существующий зоопарк ;)

P.P.P.S Я бы на вашем месте

P.P.P.S Я бы на вашем месте поставил бы еще задачу супер-максимум - сделать свой универсальный загрузчик, который заменит весь существующий зоопарк ;)

Такой загрузчик уже обещан: это grub2 Однако на него не спешат переходить, по слухам, из-за глюков и недоделанности.

Но скриптовать загрузку хочется уже сейчас. Извне мучить isolinux.cfg - занятие запретительно дорогое; результат неминуемо пойдёт насмарку с переходом на grub2

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

Ну, всякие там, не к утру

Ну, всякие там, не к утру сказано будет, убунты и иже с ними уже перешли на него и вполне ничего. Собсно - зачем вам тогда такие сложности, если груб2 умеет грузить хоть с флоппов? Вот недавно починили-таки поддержку lvm.

Если настроить его механизм автоконфига, то он даже сам список делает, весьма симпотично, надо тока ядро скомпилить, да комманду запустить.

См. исходное сообщение. УЖЕ

См. исходное сообщение. УЖЕ существует множество готовых загрузочных дисков на xxxlinux и grub(2dos). "Для себя"-то можно выбрать на будущее grub2... но как ДЁШЕВО воспользоваться продукцией разработчиков альтернативной ориентации?

Было бы проще, если бы они все прямо сейчас перешли на grub2. Но ведь это нереально, не так ли?

Ууу, вот вы что хотите - ну

Ууу, вот вы что хотите - ну тогда вам надо конвертеры _из_ форматов лоадеров _в_ унифицированный формат - проще, да, будет сразу в grub2 и заливать сразу груб2 - тогда обратные конвертеры не потребуются.

Если бы в альтернативных

Если бы в альтернативных загрузчиках не было "изюминок" - из-за которых полный перевод на grub2 проблематичен... Если бы разрабы grub2 имели и желание, и возможность оперативно перекрыть все такие фичи...

Почти уверен в обратном.

(И в том, что этими функциями на деле [почти] никто не пользуется. И что, тем не менее, за них бeдут фанатично держаться и охаивать grub2...)

2) План тестирования и дальше

Делаю предположение: за язык "единого исходника" выбран синтаксис grub4dos
(Я не навязываю этот выбор: Вы можете предпочесть обратное, тогда надо будет брать другие объекты тестирования. Может быть, взять за основу синтаксис grub2? - я не в курсе того, насколько он зрел).

Берем knoppix(LiveCD) и sysresccd
Из каждого из них родным способом делаем флешку.
Итого: четыре загрузочных среды.

Руками пишем для них исходники в синтаксисе grub4dos
Билдим из исходников четыре варианта загрузочных конфигов.

Билдим аналоги с загрузчиком grub4dos. Смотрим, вылезут ли особенности (отличия между CD и флешкой), и какие именно.

Поддаётся ли автоматизации (полной или частичной) объединение загрузочных меню knoppix и sysresccd прямо в исходниках? Из объединённого исходника должна сбилдиться объединённая флешка.

Чтобы сэкономить на

Чтобы сэкономить на изобретении велосипеда, любопытный проект: http://unetbootin.sourceforge.net/

Это тулза для разделки iso-дистров почти любых линуксов и бсд
перенос на флешку или "установка по-бырому" сразу на HDD

.

Принимая во внимание изложенное выше, сам я планирую поступить так:
* Следуя "2) План тестирования" найти время, выкачать свежие knoppix(LiveCD) и sysresccd,
сделать USB и получить 4 конфига
* в этой теме grub2 упомянут неоднократно, поэтому планирую взять за основу синтаксис grub2 -
видимо, всё равно рано или поздно на него переходить. Или что-то другое, не решил пока - буду пробовать.
* по замечанию NightNord-а попытаюсь написать "обратный конвертер" для получения на выходе спец-конфига.
* Напишу и приложу сюда скрипт, на входе которого спец-конфиг, на выходе - (легкий|средний|тяжелый) вариант в зависимости от ключей. Возможно, все три варианта будут реалиованы только в версии 0.9 :)

Это подпись, которую невозможно истолковать неправильно

еще

Еще http://habrahabr.ru/blogs

.

KNOPPIX_V6.2CD-2009-11-18-EN.iso выкачан
systemrescuecd-x86-1.3.2.iso выкачан
из Karmic 9.10 извлечён grub.conf от grub2 http://paste.org.ru/?duqk0b

Это подпись, которую невозможно истолковать неправильно

Ей богу, второй день читаю и

Ей богу, второй день читаю и стараюсь понять - не выходит.
Пара Вопросов :

Есть абстрактная задача - соз

Что это все даст мне как юзеру в чисто практическом плане ?

Что это все даст мне как администратору в чисто практическом плане ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

.

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

Это подпись, которую невозможно истолковать неправильно

.

slepnoga написал(а):
Что это все даст мне как юзеру в чисто практическом плане ?

Что это все даст мне как администратору в чисто практическом плане ?

Практика без теории (понимания что и зачем делается, а также --- чего следует ожидать в результате) слепа.

:wq
--
Live free or die

функционал загрузчиков и бутстрап осей

Я попытался описать процесс загрузки "вообще" (без привязки к ОС и загрузчику) здесь:

http://forum.ru-board.com/topic.cgi?forum=8&topic=34193&start=40#15
(вероятно, правки буду продолжать вносить: критика и уточнения приветствуются)

Из "мозгового штурма" проясняется сдвиг, который выйдет от распространения grub2 (ну и gpxe, если тот будет допилен до истинной модульности и скриптуемости)

Знатные

Знатные процентики
http://forum.ru-board.com/profile.cgi?action=show&member=LevT

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

1) Ничего не ясно,

1) Ничего не ясно, несвязанный набор фраз. Сакраментального смысла всего этого дела я не понял
2) Вы там вроде биос собрались переделывать, вот с этого и начните, когда дойдете хотя бы до уровня coreboot, который, по вашему мнению, "мертв", тогда и продолжим =)
3) "Сборка на лету сетевых осей" - фееричный термин, но даже из него понятно, что система, которую вы хотите получить и так достаточно сложна, чтобы не стоило пытаться её еще больше усложнять добавлением невнятной и никому не нужной "универсальности". Т.е. зачем вам всякие syslinux, grub4dos и прочая?
4) Зачем? Вы хотите сделать супер-пупер-мега-универсальный терминальный мейнфрейм, чтобы пришел с ноутом, воткнулся в сеть и загрузил любую ОС, какую пожелаешь? а) зачем? б) и всякую систему вы собрались таким образом пилить на части? Винду еще ладно, а всякие солярисы, ириксы... Да и что будете делать с архитектурами, ныне экзотическими для большинства систем, но вполне встречающимися - например cell с ps3?

почему усложнять? Упрощать!

почему усложнять? Упрощать! Особенно применительно к линуксу, у которого все потроха наружу. Применительно к винде кажется, что требуется усложнение - но после анализа, типа того что у меня по ссылке, в этом тоже растут сомнения.

Настраивать загрузочные ресурсы скоро сможет "мини-ось" (то, во что развиваются продвинутые загрузчики; ближе всего к таковой подобрался grub2 и на пятки ему наступает gpxe. В винде, вероятно, аналогичного функционала можно будет добиться от bootmgr, а если через промежуточную PE -так давно почти всё готово - WDS/WAIK и MDT.. Мешают некоторое техпринуждение к "лицензии" и избыточное корпоративное переусложнение - последнее можно попробовать смягчить, вдохновившись линуксом).

-
>>> в сеть и загрузил любую ОС, какую пожелаешь?

достаточно для начала линукса и венды. Типа стереоскопическая картинка, помогает не зашориваться :)
(Лично я, только начав возиться с генту, дохрена всего понял в винде: экспириенс офигительный, а-ля читанное когда-то в книжках по анатомии пощупал сам руками, препарируя "алиена")

Мотивация: отвязаться от железа. Железо x86_64 дешёвое и его всё больше в каждом доме. Слишком дорогое "удовольствие" вручную связывать железки и сервисы и ногами мигрировать между железками.

Я вижу два ценных направления развития:

1) универсальный единственный образ типа "sysreccd" - который заводится на всём что шевелится и только инициализируется по-разному (сигналами из единого центра управления)

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

Вы случаем не oVirt

Вы случаем не oVirt изобретаете ?

П.С все придумано до нас

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Это управлялка типа vCenter.

Это управлялка типа vCenter. Работает через libvirt, причем реально пока что понимает только KVM.

А я исхожу из размножения физических железок - и, действительно, предлагаю ими в будущем рулить примерно как виртуалками. (Хотя это всё ж аллегория, и различий тоже немало)

Ради этого необходимо свести их к единой железной абстракции. Coreboot применительно к x86_64 не жилец (ну не будет он никогда поддерживать дешевый PC-самосбор из современной комплектухи!). А вот grub2 - достойная база, чтобы на ней уже сейчас стандартизироваться. Не забывая о чайнлоаде gpxe для сетевых вариантов загрузки, plop для укрощения USB и grub4dos для винды - до тех пор, пока не появилась родная поддержка в grub2

И еще добавлю: я считаю

И еще добавлю: я считаю гентушную рекомендацию вкомпилировать (только нужные) модули - источником будущего геморроя (дороговизны владения размножающимися железками)

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

Ещё о

Ещё: http://forum.ru-board.co

Мультиинсталлятор -

Мультиинсталлятор - установщик сразу нескольких RO образов в единственное загрузочное меню.
http://forum.ru-board.com/topic.cgi?forum=8&topic=34193&start=60#11

и ещё несколько сообщений там рядом по теме

LevT написал(а): Реально ли с

LevT написал(а):
Реально ли с помощью ebuild-ов обойти разницу между распространёнными загрузчиками

полагаю, что нужно просто написать патч, который делал бы из lilo grub и наоборот...

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".