Ключові слова: linux, livecd, (знайти схожі документи)
Я зробив уже другий livecd, правда цей - вже зовсім спеціального
призначення - для розгортання системи з образу. Так що у мене
виробилася певна технологія виготовлення таких мікро-дистрибутивів.
Пакети я беру зі свого debian etch (а шо? Багато вже скомпільованого
софта). Але я вважаю, що на liveCD система управління пакетами на зразок
apt абсолютно ні до чого. Тому перед установкою в створювану
систему я конвертується deb-пакети в звичайні тарболли (.tar.gz), благо
це зовсім просто (ось скрипт).
Далі, з ідеї про мінімальний дистрибутиві відразу випливає, що на диску
має бути тільки те, що необхідно в даному випадку. Тому
починаємо створення livecd з установки найпотрібніших пакетів. Наприклад, в
останньому випадку у мене був скрипт-інсталятор, написаний на
bash + dialog. Значить, на диску потрібні: bash, dialog і їх (жорсткі)
залежності. Скрипт використовує cp з компанією - значить, потрібен пакет
coreutils.
Залежно треба якось відстежувати, чи не вручну ж? Як зовнішня
(По відношенню до створюваної системи) бази даних залежностей я
використовую базу apt-cache моєї робочої системи.
Все це робиться, природно, скриптами. Ось скрипт,
встановлює tar.gz в директорію зі створюваною системою. цей
скрипт знаходить deb-пакет, конвертує його в tar.gz (використовуючи
вищенаведений deb2targz), і встановлює його. Нарешті, цей
скрипт встановлює спочатку залежності пакета, а потім і сам пакет.
Таким чином, пакети ставляться в систему командою install-depends.
Зауваження 1: скрипт install-depends встановлює тільки
безпосередні залежності пакета. Тобто якщо пакет A залежить від B, а
B залежить від C, то команда install-depends A поставить пакети A і B, але
не поставить пакет C. Це поки доводиться відслідковувати вручну. Благо, в
маленьких системах таких випадків мало. А для великої системи можна і
скрипт поправити (а можна і нормальний пакетний менеджер поставити).
Зауваження 2: всім скриптів потрібна директорія, виділена під нову
систему, і в ній директорія з ім'ям packages. Там будуть складатися
встановлені пакети (deb і tar.gz), і там же буде зберігатися файл
installed.list зі списком встановлених пакетів - щоб не
встановлювати один і той же два рази.
Таким чином, по шматочках, в виділеної директорії виявляється
більш-менш робочий варіант системи (з питань, які пакети треба
ставити для того, щоб працювало те чи інше, наприклад login,
загляньте в LFS - корисна книжка). Після того, як поставлений bash з
залежностями, в створену систему можна chroot'нуться (chroot
/ Path / to / live / bin / bash), і працювати вже "зсередини".
Після установки пакетів знадобиться ще деяка доведення, щоб
система стала зовсім робочої - написання / etc / fstab, / etc / inittab і
ще чого знадобиться (в інсталяторі, наприклад, мені ні inittab, ні
fstab не знадобилися). Сюди ж відноситься написання startup сценаріїв
- тут у вас повна свобода, пишіть що вам треба. Для зовсім простих
систем можна взагалі не ставити sysvinit, а в якості init
використовувати самопісний скрипт на bash.
Таким чином виходить система, в якій можна працювати як в
chroot-середовищі. Тепер потрібно забезпечити її завантаження. Для цього, перш за
за все, потрібно ядро.
Можна взяти дистрибутивное ядро. Воно налаштоване так, щоб
завантажуватися на чому завгодно. Є у нього недолік - воно модульне, і
потрібність тих чи інших модулів визначається скриптами при кожній
завантаженні. Скрипти а) виконуються відносно довго і б) складні,
захочеш чогось зробити по-своєму - швидше за все зламаєш. Однак
пару "дистрибутивное ядро + скрипти з робочою системи" я пораджу
для тих livecd, які повинні завантажуватися на зовсім різних
конфігураціях заліза.
Якщо коло обладнання більш визначено, можна зібрати для нього своє
ядро. Це виявиться необхідно, якщо завантажуватися треба на самому
распоследній залозі - дистрибутивное ядро його не підтримує. це
також необхідно, якщо ви хочете застосувати до ядру патчі, яких немає в
дистрибутивному ядрі. Наприклад, в LiveIDE я використовую SquashFS, щоб
впихнути все більше.
Для маленьких систем можна зібрати монолітне ядро. Це добре тим,
що ядро саме визначить все обладнання, яке воно знає, тобто
скрипти для визначення обладнання не потрібні. Звичайно, ця ідея не
пройде, якщо підтримувати потрібно дуже широке коло обладнання. але,
наприклад, з ядра для інсталятора я викинув підтримку звукових карт,
мережі і ще багато чого - воно в момент установки не потрібно.
Для завантаження потрібен завантажувач. Я використовую isolinux. налаштувати його
зовсім нескладно, все описано в документації. В якості прикладу
настройки можете взяти вміст директорії isolinux / на установчому
CD вашого дистрибутива.
Завантажувач завантажить ядро. А ядро, по ідеї, повинно запустити / sbin / init.
Але для цього воно повинно примонтировать кореневу ФС. А де у нас буде
корінь? CD-ROM не підходить через те, що на різних машинах він
підключений по-різному - то він / dev / hdb, а то зовсім / dev / scd0. Тому
на LiveCD як кореневої ФС (по крайней мере, на першому етапі
завантаження) традиційно використовують initrd.
initrd - це файл образу будь-якої ФС, що розуміється ядром (підтримка цієї ФС
повинна бути вкомпільовані в ядро намертво, тобто НЕ модулем). Можна, можливо
цей образ потиснути за допомогою gzip, отримавши initrd.gz - ядро вміє
такі образи розпаковувати.
Що класти в initrd? У initrd може бути, як мінімум, три варіанти:
* Зовсім мінімальна система, яка тільки й робить, що знаходить
диск і монтує його в якості "справжньою" кореневої ФС;
* Частина системи, здатна завантажитися і подмонтировать інші
частини системи з cd.
Перший варіант зазвичай використовується в "настільних" системах. його можна
використовувати і для livecd, в тому випадку, якщо основна (live) система
займає якраз щось близько 500..700Мб. Якщо система займає більше
- потрібно використовувати стиснення окремих частин системи, для того, щоб
з ними працювати, потрібна вже не зовсім тривіальна система.
У LiveIDE у мене використовується третій варіант. Директорія / usr стиснута в
образ squashfs, а все інше знаходиться в initrd.
Для маленьких систем має сенс використовувати другий варіант -
приміщення системи в initrd цілком.
Файлова система, що знаходиться в пам'яті має такі переваги:
1) вона доступна на читання / запис (а cd і squashfs - тільки на читання);
2) якщо, окрім ядра і initrd, з диска нічого не вантажиться, диск можна
дістати з приводу відразу після завантаження. Ну а недолік великого
initrd очевидний - він займає багато місця в пам'яті.
Для завантаження ядра з initrd як кореневої ФС потрібна наступна
рядок в isolinux.cfg:
append initrd = initrd.gz load_ramdisk = 1 ramdisk_size = 50000 rw root = / dev / ram0
У параметрі ramdisk_size потрібно вказати число, кілька перевершує
розмір розпакованого initrd.
Якщо в системі не використовується sysvinit, а використовується свій
init-скрипт, потрібно дописати до цієї рядку щось на кшталт
"Init = / sbin / install-image".
Тепер створюємо образ initrd (наприклад, так: dd if = / dev / zero of = initrd
bs = 1024 count = 40x1024), форматіруем його (mkfs.ext2 initrd), монтуємо
як loop-пристрій (mount -o loop initrd / mnt / initrd), кладемо туди
все, що вирішили покласти, отмонтіруем і стискаємо (gzip initrd). створюємо
директорію (mkdir output /), з якої будемо збирати образ диска, в
неї кладемо директорію isolinux, створюємо директорію isolinux / kernel,
туди кладемо ядро і initrd. При необхідності кладемо файли / директорії
в кореневу директорію диска.
Для створення завантажувального iso-образу використовуємо команду на кшталт
наступного
mkisofs -o /path/to/live-image.iso -r -V "My Live CD" -v -no-emul-boot
-boot-load-size 4 -boot-info-table -b isolinux / isolinux.bin -c
isolinux / isolinux.boot / path / to / output
Звичайно, навряд чи все вийде з першого разу. Щоб не пороти купу
cd-болванок, образи можна тестувати під емулятором (qemu).
PS. Я в курсі, що це "не зовсім Дебіан-вей". Це, скоріше, Слак-вей.
Але цей спосіб набагато більш гнучкий.
ar x $ 1
rm control.tar.gz
mv data.tar.gz $ # 123; 1 / .deb / .tar.gz # 125;
Рецензія на Lost Chron. Ігри, зроблені без любові і старання, схожі на повітряну кулю - оболонка є, а всередині порожньо. Lo.
Рецензія на The Bridge «Верх» і «низ» в The Bridge - поняття відносні. Прогулюючись під аркою, можна запросто перей.
Рецензія на SimCity Коли місяць тому відбувся реліз SimCity, по Мережі прокотилося цунамі народного гніву - дурні ош.
Рецензія на Strategy . Назва Strategy Tactics: World War II навряд чи комусь знайоме. Зате одного погляду на її скри.
Рецензія на гру Scrib. За традицією, що склалася в інформаційній картці гри ми наводимо в приклад декілька схожих ігор.
Рецензія на гру Walki. Зомбі і продукція-по-ліцензії - які і самі по собі не найкращі представники ігрової біосфери -.