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

У меня размер moa24_std.iso 343 760 896

Думаю, что стоит ответить на что-нибудь по-разному - и результат окажется разным. Например, я включил поддержку smp

Ещё раз: если правильно отвечать на "автоматические" вопросы, то получится тот же эффект, как если нажимать пункты меню config сверху вниз. Этого НЕДОСТАТОЧНО. Для дальнейшей обработки нужен postprocessing. Его меню недоступно, пока не создастся MOA core (закончится конфиг и отработает pebuilder).

А вот потом оно доступно - но логично было бы заблокировать config. Этого разработчиком не сделано. В предыдущих версиях вроде бы можно было, вызвав заново moa-setup, тыкать потом в пункты конфига и опять вызывать pebuilder. Но в текущей версии так делать нельзя: об этом разработчик написал на форуме.


Сюда бы хоть одного опытного PE-шника! А-уууу!! Люди!

все перепробовал - результат тот же.

может еще какие идеи?

вот пока попробовать... вписалось в 300М и шустро залилось.
http://rapidshare.de/files/48457225/moa24-bandit.iso.html

Спасибо.
Ваш исо работает, мой все еще нет.

Попробую вскрыть ваш - может мысли какие появятся.

Moa-setup это (криво спроектированная) оболочка на AutoIt, она как-то дёргает собственные сборочные скрипты MOA и стандартный pebuilder. Основную работу делает он.

Нужен кто-то, кто умеет pebuilder - чтобы изложил в трёх фразах русским языком, чтО именно делает moa-setup... и как в него тыкать мышкой, чтобы получить нужный эффект.


Разработчик как-то в мае загорелся благим желанием описать все подробно для чайников, но быстро остыл...

Я ему написал тогда: "Сделал бы ты визард, что ли? - вместо нынешнего уродства"
Он в ответ: "я скриптоваятель, а не техпис и не дизайнер интерфейсов, увы."

Ему проще выложить флэш-туториал (их кстати несколько выложено).


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

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

Цитата:

А я тогда так и не осилил сборку. Осилил только под осень: поднатужился и за пару дней одолел. Сам я теперь знаю на память правильную последовательность кликов, но смысла многих действий не улавливаю.

Если не трудно, напишите "правильную последовательность кликов", а от нее уже можно будет плясать.

на офайте есть флешролики. Смысла в их словесном пересказе я не вижу.

Смысл был бы - если бы я понимал смысл действий (скриптов), запускаемых кликами. ВСЁ, что я понял, изложено выше (картина очень высокоуровневая).

Детали я НЕ понимаю.

вроде все так делал как написано

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

Опытному pe-билдеру обезьянствовать не придётся: ждем, когда кто-то из таких людей сюда в тему снизойдёт и процесс разъяснит.

не получается использовать другие таргеты кроме старвинда для вот этого

http://erwan.l.free.fr/iscsi/install.html
трюка (загрузки с софтового инициатора с помощью gPXE)

конкретно я помучился с Opensolaris и с FreeNAS
(хочется заюзать таргет на основе ZFS)

Кто-нибудь может помочь советом?

нашёл у братьев наших инструкцию по gPXE с кортинками

http://bbs3.chinaunix.net/thread-1568367-1-1.html

там есть и ещё пища для размышления...

http://etherboot.org/wiki/soc/2009/pravin/project_plan/start

это про проект boot.kernel.org - централизованный ресурс загрузочных образов
syslinux и gPXE умеют грузить системы по http!





Добавлено:

The reasoning behind this project is to provide one stop location for user where he can find and use most of the diagnostic, rescue tools and various system images without any need for creation of dedicated media or installation. It will allow users to try out various systems in painless way.


Добавлено:

http://boot.kernel.org/index.html#screenshots


Добавлено:


Еще интересное хавту

Что было бы интересно лично мне? Постараюсь сформулировать, комменты приветствуются.

Проект boot.kernel.org обещает много зеркал, а также возможность организации локального зеркала. Заманчиво также умное проксирование - чтобы один раз загруженные образы кэшировались локально. Видел, что и на эту тему вроде как работы ведутся.

Проект тот линуксовый и лицензионно чистый. Интересно было бы добавить авторизацию и по ней - доступ к лицензионно нечистому контенту, из локального источника или андерграундного аналога boot.kernel.org

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

LevT
по http грузился, но "чисто попробовать"
тк инет не дешев и проще с локального tftp грузиться

важно единообразие - чтобы не требовалось переучиваться и перекраивать инфраструктуру для того чтобы попробовать http или заменить http на tftp или iscsi

и чтобы был общий язык.


этот самый boot.kernel.org - это же абсолютно фришный линуксячий проект. Никто и ничто не мешает держать его полную локальную копию.

Только следующий вопрос встаёт уже - как сэкономить место и не хранить лишнее?

И более следующий - как добавить своё (возможно, лицензионно нечистое) и поделиться с товарищами? Притом, сделать это ДЁШЕВО и для себя и для них.

Чисто линуксовый
http://www.sysresccd.org

на основе Gentoo. Позиционируется именно как инструмент админа, а не полноценный дистр. Полноценные доки (нерусские, увы). Всегда свежее ядро и софт.


backing store
autorun scripts
сервис pxebootsrv (dhcp, tftp и thttp в одном флаконе)


Близко к идеалу для умного ковыряния линукса (если нет проблем с чтением англ.)

Ремастеринг необходим: в оригинальном скачиваемом сейчас диске есть по крайней мере одна мелкая досадная ошибка. Но диск содержит инструмент для перепаковки (создания собственного аналога)

http://www.sysresccd.org/Sysresccd-manual-en_How_to_personalize_SystemRescueCd


Изложенное на самом деле просто. Я сам закоренелый виндузоид - и вплоть до сего момента относился с недоверием к подобного рода утверждениям.

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


Добавлено:

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

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

http://unetbootin.sourceforge.net/

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

Написано, что виндовая версия работает лучше линуксовой;)


Неуниверсальность утилиты видна сходу: добавить бы к ней умение аналогично разделывать винду (и РЕ), цены бы ей не было...

Хех. А с каких пор OpenSource сообщество должно поддерживать кривые недоОС от M$явых?

goletsa

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

От PE-шников, к примеру, столь же затейливый выхлоп...

И от прочих сектантов. Например, я начинал ставить проблему в топике Grub4dos - так меня оттуда буквально выперли.


Добавлено:

goletsa

Это именно тараканье гнездо в мозгах...а не высокая идеология ни разу.
http://en.wikipedia.org/wiki/Not_Invented_Here

WinPE в зависимости от версии грузится десятком разных методов. Со всякими извратами. Отсюда все сложности.

С linux'ом просто проще.
Там грузятся vmlinuz->initrd->rootfs
Причем методы запуска vmlinuz&initrd достаточно стандартны и поддерживаются многими загрузчиками(включая такие необычные вещи как gpxe), чего не скажешь о winpe.
А монтирование и поиск rootfs это уже целиком заботы initrd а не загрузчика ОС.

Цитата:

Со всякими извратами. Отсюда все сложности.

Сложности - от отсутствия ПМ, способного прикрыть неперспективные направления и додать ресурсов перспективным.

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



Цитата:

С linux'ом просто проще.
Там грузятся vmlinuz->initrd->rootfs
Причем методы запуска vmlinuz&initrd достаточно стандартны и поддерживаются многими загрузчиками(включая такие необычные вещи как gpxe), чего не скажешь о winpe.
А монтирование и поиск rootfs это уже целиком заботы initrd а не загрузчика ОС.

Спасибо за прояснение, для меня лично очень полезное.

А вот теперь кто бы изложил Win/PE варианты, основываясь на изложенной линуксовой схеме? шаг за шагом. (Часть линуксоидов уже прошла через шок узнавания, что винда оказывается подерживает Multiboot specification - а части это ещё предстоит)

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

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


Что касается зоопарка линуксовых загрузчиков - думаю, пора всерьёз разбираться с grub2 .


Добавлено:
goletsa

Верно ли следующее утверждение: initrd нужен только для обобщённого ядра? (и ненужен для ядра заточенного под конкретное бутовое устройство)

мой свежий генту грузится без initrd (я не использовал genkernel)

LevT

Цитата:

(Часть линуксоидов уже прошла через шок узнавания, что винда оказывается подерживает Multiboot specification - а части это ещё предстоит)

На вики об этом не слова.


Цитата:

А вот теперь кто бы изложил Win/PE варианты, основываясь на изложенной линуксовой схеме? шаг за шагом.

А вот тут начинаются уже извраты с разными версиями где как загрузчик ОС могут выступать ntldr\setupldr\bootmgr в разных версиях\вариациях.


Цитата:

Верно ли следующее утверждение: initrd нужен только для обобщённого ядра? (и ненужен для ядра заточенного под конкретное бутовое устройство)

мой свежий генту грузится без initrd (я не использовал genkernel)

Лишь отчасти.
Есть системы в которых initrd играет роль rootfs.
Пример - большинство роутеров под линуксом.

Плюс initrd может заниматься автоматическим поиском rootfs и монтированием разделов.
В случае его отсутсвия надо передавать ядру параметрами откуда дальше грузиться.

Цитата:

На вики об этом не слова.

похоже, я погорячился.
тем не менее, http://www.srenevasan.org/~kaushik/articles/pe.html

grub4dos удалось дырку заделать совершенно виртуозно... и вообще так качественно скакнуть, что линуксоиды ринулись переписывать grub->grub2

Интересно, будет ли grub2 столь же свободно работать с виндой, как grub4dos?




Цитата:

А вот тут начинаются уже извраты с разными версиями где как загрузчик ОС могут выступать ntldr\setupldr\bootmgr в разных версиях\вариациях.

Вистовский bootmgr - это загрузчик нового поколения (типа grub2), отдельная песня (мини-ос или "расширитель биоса", чуть ли не скриптуемый тоже... только без исходников.)


Разницу ntldr/setupldr - хорошо бы кто-то описал по делу.

Я так понимаю (могу ошибаться), что важнейшим различием является способ опознания бутового устройства (setupldr полагается на BIOS?) Также разница в том, что setupldr содержит внутри свой "initrd" (отсюда некоторые жесткие лимиты типа размера рамдиска).

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


Я бы провёл сразу такое различие: между загрузкой генкернела (способного динамически определять любое оборудовние по базе pciid, но нуждающегося в бутстраппере с мини-драйвером загрузочного устройства) и фиксированного ядра типа "embedded" с "вкомпилированными модулями" (по списку оборудования конкретной железки, о котором должен позаботиться билдер).



Цитата:

Есть системы в которых initrd играет роль rootfs.
Пример - большинство роутеров под линуксом.

Это типичный embedded дизайн <== оборудование известно наперечёт, определение его нахрен не нужно. И сервисы тоже заданы заранее, билдером, колдунца-админа не предусмотрено



Цитата:

Плюс initrd может заниматься автоматическим поиском rootfs и монтированием разделов.
В случае его отсутсвия надо передавать ядру параметрами откуда дальше грузиться.

У меня генту грузится без initrd с единств. параметром root=..
Вы хотите сказать, что в initrd может быть зашита логика автоопределения root?

А зачем её пихать в типа embedded образ? Зачем создавать сложности админу, на случай если он захочет ее изменить? Не лучше ли скриптовать, скажем, в grub2? Или более консервативно: подсовывать на флешке?



Добавлено:


Grub2Intro:
http://www.sidux.com/index.php?module=Wikula&tag=Grub2Intro

Предлагаю обобщенную схему стадий загрузки. Комментарии-исправления приветствуются.
Цель - уйти от однобокого линуксоидного или 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 - изволь регулярно проверяться антивирем").

Цитата:

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

LevT
IMHO
основной BIOS сканирует область bios add карт и передает управление на их bios 2 раза - первый раз для настройки адресов, второй для инициализации устройства


Цитата:

Коренное новшество текущего исторического момента

а winpe c сетевой шары грузиться по моему так (выбирает сетевую)

Цитата:

основной BIOS сканирует область bios add карт и передает управление на их bios 2 раза - первый раз для настройки адресов, второй для инициализации устройства

ну... я упомянул биос только ради того, чтобы обозначить что он тоже "типа ОС", с излагаемой точки зрения.

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

Потому стандартизироваться на 1-й стадии невозможно - а вот на 2-й в самый раз, то что доктор прописал.




Цитата:

а winpe c сетевой шары грузиться по моему так (выбирает сетевую)

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

А также о всех случаях, которые вписываются, но недостаточно очевидным образом.

Прочитано.

"Классические" операционные системы сохраняют конфигурацию драйверов (модулей ядра) и сервисов внутри себя, рядом с собственными исполняемыми файлами - и страдают из за этого из-за проблемы "курицы-яйца". См. bootstrapping (вытягивание самого себя за волосы шнурки ботинок).

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


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

Инсталляторы осей по сути тоже представляют собой такие обобщённые системы, в последнее время всё чаще в виде LiveCD. Противоположный (примитивный) вариант обобщенной системы - загрузчики типа pxelinux.0 или startrom, которые знают только одно загрузочное устройство (PXE), выводят менюшку с выбором конфигурации следующей оси, подтягивают выбранные юзером загрузочные ресурсы по сети и передают им управление.


WIM это изощренный формат рамдиска, по технологии "единого источника пофайлового хранения" содержащий загрузочные и установочные ресурсы винды, возможно, одновременно нескольких её разновидностей.

Новейшая технология в юниксах - многослойные файловые системы, позволяющие накладывать слой динамических (RW) данных (backing store) на неизменную (RO) юзеро- и админоустойчивую(!) основу. Новейшая винда содержит нечто похожее: "online servicing".


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


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



Альтернативный способ сохранения конфигурации системы - внешний. Конфиг более сложной системы может выбираться продвинутым загрузчиком (фактически мини-ОСью) из доступных ему стораджей и сетевых ресурсов. Равно как и сам загружаемый RO образ, и подкладываемое ему backing store могут определяться скриптом, исполняемым в оболочке такого загрузчика.

Тема посвящена этому новейшему способу, подходам к миграции на него в (домашних и корпоративных) сетях и миграции мозгов (админов и разработчиков).