Для повнофукнціональної ОС, існує поняття двох типів сесій виконання: ті, шо відбуваються до інсталяції (ще відомі як "live"), далі просто "встановчі" або "інсталяційні" і ті, шо відбуваються після інсталяції, далі просто "встановлені" або "інстальовані". Завантажений набір, це встановчий набір. Зараз, майже немає різниці між цими двома, але це зміниться і цей посібник пишеться з урахуванням цього, майте на увазі, коли бачитимете ніби роздутий об'єм тематичного покриття. Хоча "живі" сесії можуть бути корисними самі по собі, для деяких сценаріїв використання, — основний сценарій всеодно, встановлений. Отже, звичайний хід мається на увазі такий: завантаження набору, підготування інсталяційного носія, запускання ОС, швидке ознайомлення з нею в установчій сесії і далі запускання встановчої програми, яка створе інсталяцію Либіді на машині. Усі подальші сесії будуть установленими.
Либідь ще не надбала встановчої програми і таким чином, встановчої процедури теж. Але вже зараз є можливість створити інсталяцію руками. Неважливо який кривий це може мати вигляд на перший погляд, воно цілком підходе для розробки (насправді навіть треба) і також це може бути цікавим для ранніх зовнішніх тестувань. І того шо набір файлів невеликий і ще немає багато конфігурування також, перетворення встановчого набору в установлений тривіальне. З одним помітним винятком: на UEFI, інстальований випадок очікує мати Пускову (Вантажну) Опцію для своєї інсталяції, тобто треба її створити, і в реальності, це не обов'язково "тривіально".
Либідь не покладається на вантажних посередників, вона має свій вантажник, який є UEFI-шним Вантажником ОС, чия єдина мета є запускати Либідь, згідно з її пусковим протоколом, і нічого більше. Це означає, шо якщо ми хочемо створити інсталяцію, нам треба створити пускову опцію для нього. UEFI дає створити таку і якшо імплементація ППЗ на машині не цілком зіпсована марсіанською логікою або "покращеннями" від виробника, це можна зробити відносно легко. Для цієї мети, помогти в ручній інсталяції Либіді, була створена утиліта clo. Її ім'я означає "Створити Пускову Опцію" (англ. "Create Load Option"). Це проста, інтерактивна UEFI програма для використання в ІКР UEFI і вона робе, в полі взаємодії з ППЗ, те, шо пізніше робитиме встановча програма. Тут знову йде необхідне попередження: треба бути уважним підчас її використання. Хоча вона не шкідлива сама по собі, помилки та відхилення в ППЗ можуть, потенційно давати ризик. Коротко, утиліта пише в постійне (флеш) сховище ППЗ, але лише використовуючи сервіс SetVariable() і лише для встановлення своєї свіжоствореної змінної BootN та додавання її індексу в (край) змінної-списку BootOrder. Як правильно робляться відповідні маніпуляції всередині сховища ППЗ і чи ці додавання будуть видні, залежить повністю від того, наскільки відповідає специфікаціїі й наскільки правильно робе ППЗ машини. За деталі про використання clo, читайте далі.
Щодо авторського власного досвіду використання clo, для OVMF і Галлія, її робота
була досить успішна: пускова опція не лише створювалась, але також додавалась правильно до
BootOrder і була видна в меню пускових опцій Менеджера. Щодо меню, то це для OVMF,
бо Галлій не має такого меню, а точніше, те, шо він має, не робе як меню для вибору опції для запуску: ви можете лише
міняти їхній порядок там. Це власне меню редаґування порядка опцій,
самого ж меню опцій нема і якшо ви виставите таймер, наприклад 10 секунд, то ППЗ 10 секунд показуватиме
чорний екран перед тим як запустити першу опцію. Для Іридія ПО створювалась "успішно" лише в тому значенні,
шо SetVariable() звітував успіх, але ПО не була створена напостійно і не була показана в меню опцій
Менеджера чи додана в BootOrder. Може й була, але ці зміни не були на постійній основі, вони
не були видні наступного пуску машини, хоча мали б. ППЗ Іридія взагалі показує клієнтам фальшиву
BootOrder. Як Windows спромігся виставити ПО для bootmgfw.efi в цій каші, залишається
загадкою. Але це ноутбук 2011-го року, коли UEFI лише робила свої перші кроки в користувацькі ПК і HP
чесно попереджав, на перемиканні з BIOS-у в UEFI, шо це може не робити як очікується експериментальна
можливість.
Назараз, крім створення пускової опції, треба трохи реаранжувати те, куди вміст набору піде згідно з тим, куди б його файли клалися підчас інсталяції. Є дві одиниці сховища, куди Либідь кладе свої файли:
Домашній Том, це маленька партиція, як сказано, зазвичай, в "випусковому" сценарії, це ESP, але необов'язково, покишо не рекомендується класти antload туди, просто шоб полегшити процес. Пусковий Том, це нормальна "основна" партиція для ОС, наприклад, чим у Windows є диск C:
У віртуальних середовищах, ми робимо трохи більший, ніж для встановчого випадка, .vhd, і розкроюємо його на невеличку FAT партицією для Домашнього Тому, більшу для Пускового Тому і, на майбутнє, на Пускові Томи з JFS і BFS партиціями. Назараз, дві останні робилися на ОС, які мають інструменти для цього (Debian та Haiku відповідно). Непотрібно мабуть і казати, шо якшо ви вирішете робити такий або схожий розкрій, треба буде скопіювати директорію Lybid в усі партиції Пускових Томів, які ви зробили. Бо кожна така партиція буде окремою інсталяцією і вимагатиме своєї пускової опції. Вантажник, з іншого боку, залишається той самий, в одному екземлярі, його не треба розмножувати (всі ці ПО вказуватимуть на той самий файл antload на ДТ, але матимуть різні Дескриптори Пускового Тому, дивіться нижче).
В тестах на справжньому залізі, як описано раніше й на іншій сторінці, успіх не був однозначним на Галлії й Іридії, через різні причини. Галлій можна використовувати для ручного інстальованого варіанту, хоча це було б вельми незручно, дивіться відповідну секцію для деталей. Щодо Родія, то оскільки цей ноутбук був куплений у вересні 2024-го, всього 2 місяці тому, покишо, лише тести в інсталяційному варіанті були прогнані там. Звіти за успішність тестів інстальованого випадку будуть викладені тут за наявности. На Родії ми плануємо покласти antload в ESP партицію машини, вона вже там є й на ЖД ноутбука досить місця для цього, а Либідь піде на USB флешку, тобто це буде варіант "інсталяція на знімне сховище", який технічно не відрізняється від звичайного.
На випадок тестування на справжньому arm64 залізі, де єдиною опцією для сховища є SD картка, не треба розбивати картку на 2 партиції, пам'ятайте, SD Асоціація каже "ні" на це: лише 1 FAT партиція (тип FAT залежить від розміру картки) з MBR схемою. Для цього випадку, ДТ і ПТ поєднуються в одне і різниця між встановчим і встановленим варіантами поки буде та, шо останній матиме свою ПО. Покишо не рекомендується пробувати інстальований варіант для випадку uboot-у як ППЗ. uboot вимагає ESP (шоб зберегти BootN), партиція на SD картці не повинна бути позначена як ESP, тож якшо ви не маєте ESP партиції на наплатному модулі eMMC, краще просто тестуйте в установчому варіанті покишо. Насправді, зважаючи на ранній стан підтримки EDK2 портів на армівських ОПК, краще пробувати інстальований варіант в першу чергу на x86-тих ПК з некапризним ППЗ на борту.
Іноді також Дескриптор Пускового Тому і Кореня Системи (ДПТКС), Boot Volume System Root Descriptor (BVSRD).
Це структура, яка тримає необхідну інформацію для вантажника, шоб йому найти з якого сховища зчитувати Либідь.
Вона містить самий мінімум даних, і, таким чином, не бере багато місця на флешпам'яті ППЗ.
А саме, вона містить відносний Пристроєвий Шлях Пускового Тому, який починається з
вузла HD() (тип 4, підтип 1), а за ним іде Файловий вузол (тип 4, підтип 4).
Перший описує партицію, другий — шлях до директорії на ній, яка є Системним Коренем (System Root)
Либіді. В текстовій нотації UEFI Пристроєвого Шляху, ДПТ мав би такий вигляд, як цей приклад:
HD(4, GPT, ec384e7e-0d93-4bd3-9740-e889eb00b3e5, 50080, 2f000)\Lybid
Також, 2 байти флажків вантажної конфігурації йдуть за цим шляхом. Ця структура бере коло 64-х байтів.
Вона йде в так звані Опціональні Дані (Optional Data), це частина Дескриптора Пускової Опції UEFI-шного
Вантажного Менеджера, ДПО, а весь цей ДПО й складає вміст змінної середовища BootN, шо репрезентує Пускову Опцію,
за допомогою якої й ППЗ взнає, як стартувати відповідного клієнта (antload в випадку Либіді).
Як бачите, antload використовує ПО в тому ж дусі, шо й ППЗ, але вже для взнавання, шо йому запускати.
Неважко здогадатися, шо це й була ідея Пускових Опцій, закладена в стандарт.
Це те, шо clo створе й запише в сховище ППЗ, поки встановча програма не готова. Знову, використовуйте її обережно, уважно читаючи, шо вона питає й лише переконавшись, шо ви все зрозуміли, продовжуйте.
Якшо вирішили створити інсталяцію Либіді вручну, треба створити її Пускову Опцію. Як сказано, для віртуальних середовищ, все робе як має. Можна призвичаїтися до clo там. Звичайно, основна мета, це пробування на справжньому залізі. Шоб зібрати знання за нюанси цього процесу на різноманітті машин від різних виробників і часів. Просто будьте уважними. Утиліта не є "небезпечною", але ви, мабуть, не хотіли б створити "биті" змінні середовища ППЗ в флеш пам'яті машини, навіть якші ті змінні не впливають на решту системи, беруть десь коло двісті байтів місця і навіть якшо все це на машині, виділеній для тестів. Також, clo не дає фукції видалення. Навіть не намагалися це робити, знаючи всю кашу в ППЗ. Якшо остання дає таку опцію "видалити пускову опцію" в своєму меню, використовуйте її, якшо треба.
Запускаєте clo так само як antload, або через "Завантажити з файла" або через ІКР UEFI. Шлях до файла: efi\Upptech\clo.efi. Знову, це розробницький інструмент, простий і таким чином трохи грубий. Якшо наберете очевидно хибне введення, вона просто вийде, друкуючи червоним за помилку. Нічого не буде записано в сховище доки ви не підтвердите цю дію. Тільки в самому кінці, після того, як всі кроки зроблено й перевірено, вона скаже, шо готова записати змінну в сховище і тільки якшо ви підтвердите це, вона пробуватиме записати, використовуючи наданий ППЗ стандартизований механізм.
Картинка показує описаний вище процес.
В порядку вгорі, на кроці 5, clo питає за тип ФС Пускового Тому. Там був варіант з FAT. Якшо ви виберете іншу ФС, введенням "n" на те питання, тоді clo
Дальші кроки ті самі як попередньо. Нижче, картинка скриншот візуалізує цей випадок
Якшо ППЗ зробило все правильно, пускова опція (ПО) з'явиться в меню пускових опцій Вантажного Менеджера. clo додає ПО в край змінної-списку BootOrder, тож ОС, яка була першою, такою й залишиться. Можете поміняти вантажний порядок самі, якшо схочете і якшо Менеджер дасть. Тепер, коли вмикатимете машину, або натискаєте клавішу, шоб зупинити старт першої опції і зайти в меню опцій Менеджера цієї, очікувано, багатовантажної конфігурації, або можна виставити таймер, в налаштуваннях того ж Менеджера, шоб мати можливість одразу в це меню попадати без потреби гатити щоразу по клавіші. Іноді виставити час очікування не вдається, наприклад в OVMF це не робе, таймер скидається до нуля на новому старті. Справжнє залізо часто дає виставити такий час. Досвід взаємодії з Менеджером ППЗ варіює, як ви й самі знаєте. В будь якому разі, знаходите меню вантажних опцій і запускаєте Либідь вибиранням її пункту і натисканням <Enter>. Виставляння опції Либіді в саму гору, зробе її старт автоматичним, якшо не втручатися.
Тепер, коли Либідь встановлена і має свою пускову опцію на машині, якшо ви підете в ІКР UEFI і введете:
де fsN це Домашній Том вашого встановленого зразка ОС (а не встановчого носія, який ви вже мали б витягти на цей момент), то отримаєте помилку від antload про те, шо не вдалося знайти SystemRoot директорію Либіді. Це того, шо з інстальованим випадком, треба запускати Либідь (будь яку ОС) через її пускову опцію. Бо в цьому випадку, вантажнику невідомо, просто так, на який саме диск (том) ОС встановлена. У встановчому випадку, том виводиться з очевидного принципу, шо ОС сидить там же, де й вантажник — на встановчому носії. У випадку ж встановленої Либіді, партицію, на якій знаходиться Пусковий Том та ім'я SystemRoot, вантажнику треба вказати. Шо Дескриптор Пускового Тому й робе. Однак, встановлений зразок Либіді все ж можна запустити без її оригінальної пускової опції. Як особливий, відновлювальний випадок, наприклад якшо якимсь чином ПО була видалена, але інсталяція гожа. Це можна зробити в ІКР UEFI або, в деяких випадках, з Пускового Менеджера.
Для цього треба надати текстову форму ДПТ (BVD) як аргумент для antload підчас його запуску з ІКР, як в цьому прикладі з GPT Пусковим Томом:
або, якшо ПТ є MBR:
Синтаксис цього рядка для GPT схеми:
а для MBR:
де:
Увесь рядок має йти без пробілів між елементами та без лапок навколо. Усі числа, крім <PARLBA> фіксованої довжини; не має бути ніяких шіснадцяткових специфікаторів. Щодо GUID-ової Data4 частини. Як ви знаєте, цей елемент є масивом 8 байтів, це не 64 бітне ціле, нажаль, гірше, через якісь причини, в текстових поданнях, його показують розділеним на 2 частини: перші два байти ідуть окремо від решти шести, між ними стоїть ще один дефіс. І не дивлячись на це, ці два байти неможна вважати 16 бітним цілим, чим, наприклад суть <Data2> та <Data3>; ці два байти це окремі один від одного байти, тож неможна міняти їх місцями в тексті, думаючи, шо молодший розрядом байт має йти другим. Ми дотримуємося цього не надто зручного подання GUID-ів для узгодження між інструментами, наприклад ІКР UEFI подає їх так само. Просто трактуйте Data4 як масив восьми байтів, забувши за релікти big-endian-ности тут і в нашому способі подавати числа в тексті.
Цей альтернативний пуск через передавання текстової форми ДПТ робитиме в середовищах, які вміють передавати цю інформацію вантажнику, як аргумент пуску, такі як наприклад UEFI-шна оболонка або через створену вручну пускову опцію в Пусковому Менеджері ППЗ, якшо останній дає таке і якшо дає призначити "Опціональні Дані", ("Optional Data"), шо, наприклад, робе EDK2-шний Менеджер Підтримки Вантаження (Boot Maintenance Manager). І навпаки, це не робитиме з опцією "Завантажити з файла" очевидно, бо так нема можливости передати аргументи вантажнику.
З оболонкою UEFI та іншими, які імплементують специфікацію оболонки UEFI, робіть як описано вгорі. Також є шанс, шо якшо імплементація ППЗ дає створити пускову опцію в своєму меню вручну, з "Опціональними Даними" включно, тоді такий варіант теж робитиме. Ясно, шо лише текстові дані можна вставити в "Опціональні Дані" в цей спосіб, тож це буде ще один варіант передавання текстової форми ДПТ вантажнику, як і в випадку з ІКР. Як створити таку пускову опцію? Дотримуйтесь інструкцій, наданих Пусковим Менеджером у відповідному меню. У випадку EDK2, це було протестовано, воно дає ввести, як "Опціональні Дані", текст, впишіть туди текстову форму ДПТ, точно як в ІКР. Чи працюватиме це для інших середовищ, лишається виясняти. Наприклад в uboot-і, чи робитиме це:
як очікується або чи робитиме взагалі, треба ще взнавати. Зараз у мене немає відповідних тестових майданчиків. Ваша участь вітається.
Створення таких опцій візьме трохи більше місця в сховищі ППЗ, ніж рідна, двійкова форма ДПТ, тож користуйтесь цим випадком лише за необхідности, для відновлення чи пом'якшення, у випадку, якшо оригінальна пускова опція недоступна, але інсталяція цілком гожа. В майбутньому, Либідь надбає механізм відновлення ПО, тож знадобиться лише одноразовий відновлювальний пуск через оболонку, якшо взагалі знадобиться. clo робе пускові опції, де ДПТ є в "рідній", найкомпактнішій, двійковій формі. У випадку альтернативного запуску через оболонку, нічого не зберігається в сховищі ППЗ взагалі, але треба буде щоразу вводити доволі незграбний рядок. Однак, можна зробити простий скрипт для уникнення цього постійного введення (цей скрипт зберігатиметься на Домашньому Томі).
Де взяти цей текст ДПТ? Для ручної інсталяції, ви маєте подбати за це самі, виписавши необхідні дані кудись і зберігши їх. Підчас ручного створення ПО за допомогою clo, вам всеодно б треба було знати ці дані. Бо це як ви розпізнавали ваші партиції, файлову систему ПТ, і тепер це як ви даєте цю саму потрібну інформацію вантажнику. Оболонка UEFI, яка видруковує ці дані на своєму старті, утиліти партиціонування та інші, з якими ви робили в процесі створення чи вибору партицій допоможуть. Для пізніших, не таких "суворих" розробницьких фаз, встановлювальна програма надасть цей текст для користувача.
До речі, цим методом можна запустити й установчу сесію (якшо так хочеться вводити додаткові дані і додавати ще роботи вантажнику). Ми ділимо сесії на встановчі й встановлені і балакаємо за ці різні випадки, а як вантажник їх розрізняє? Він іде за алгоритмом, який спочатку виясняє чи передали йому інформацію за пусковий том і якшо так, використовує її. Якшо ні, він вважає пусковим томом той самий том, звідки його зчитало ППЗ. Цей алгоритм націлений на основний, встановлений сценарій, але якогось розрізнення сесій він не робе. Згадана вище інформація за пусковий том буде або ДПТ в бінарній формі, якшо запуск іде через оригінальну пускову опцію Либіді, це основний сценарій або це буде ДПТ в текстовій формі, це "альтернативний" метод пуску Либіді або взагалі ДПТ не буде вказаний, це, зазвичай, встановча сесія, наприклад "Завантажити з файла" Пускового Менеджера EDK2 логічно не передає нічого, а ІКР, в разі "голого" пуску antload, без параметрів, передає самий шлях до вантажника (Argv[0] в термінах параметрів ІКР). Якшо вантажник отримує ДПТ, він шукає вказаний том і якшо знаходе такий в машині, відкриває в ньому вказану директорію, і зчитує компоненти ANT звідти. Якшо ж ДПТ передано не було, він вважає пусковим томом той самий том, звідки його зчитало ППЗ, а SystemRoot директорією, вважає директорію Lybid в корені цього ж тому. Саме так складений "встановчий" набір, але необов'язково лише він, наприклад, якшо ваша машина — arm-івський ОПК, де єдине постійне сховище це SD картка, то в цьому випадку домашній і пусковий томи теж збігатимуться. Якшо подумати, для цього випадку можна навіть не створювати пускової опції, правда лише за умови, шо на інсталяції ОС, ви не вибрали якесь інше за Lybid ім'я для SystemRoot директорії і шо вам зручніше стартувати ОС через UEFI оболонку. І саме того, шо без передавання ДПТ, алгоритм вантажника бере розкрій за замовчуванням, який збігається з розкроєм встановчого випадку, найлогічніше, було б не передавати ДПТ в цьому випадку, але якшо дуже захотіти і на запуску встановчої сесії в ІКР, вказати текстову форму ДПТ для тому встановчого носія, це робитиме теж. Як бачите, розрізнення йде більше за тим чи був наданий дескриптор пускового тому чи ні.