Спробувати ANT

Шо очікувати назараз?

Перш за все, перевіряйте оновлення, вони наповнюватимуть змістом. Щоразу як оновлення з'являтиметься, його номер і дата будуть вказані в відповідному параграфі, дивіться розділ завантаження долі. Покишо спробувати можна небагато. Наявні образи дозволяють запустити вантажник Либіді в середовищі UEFI на справжньому залізі й на віртуальних машинах для x64, ia32 та arm64 архітектур. Станом на оновлення 3 (06.03.2025), antload передасть контроль ANT, яке, в свою чергу, надрукує вітання і заведе процесор в простоювання. Тепер це доступно для всіх трьох архітектур. Покишо, весь набір — це кілька образів ANT та інших компонентів. Acpi.sys "драйвер" є не зовсім тим, за кого себе видає, це перейменована копія antload.efi, покладена грати роль корисного навантеження, шоб цикл завантаження драйверів був непустим. Не прибирайте його, оскільки SYSTEM "вулик" (покишо просто текстовий файл) сконфіґурований шукати цей драйвер. Ми додамо справжній Acpi.sys драйвер в свій час. В тестах antload завантаже образи, виконуючи необхідні підготовчі роботи над ними, такі як прикладання базових переміщень (релокацій) та зв'язування образів, також завантажуючи конфігурацію і ресурси і роблячи інші вантажні справи, а тоді застрибне в ANT. Візуально, antload показує Пусковий Екран Либіді на відео вихід, якшо доступний, використовуючи UEFI-шний GOP і виводе трасувальний друк на послідовний порт, використовуючи UEFI-шний STOP (Simple Text Output Protocol). Для віртуальних середовищ, знадобиться виставити відповідні опції, шоб мати ці пристрої виведення. Для бачення трасувального друку на справжньому залізі, треба під'єднати тестову машину до послідовного терміналу. Станом на оновлення 3, яке приносе стрибок в ANT, Пусковий Екран ледве помітний, оскільки покишо фаза вантажника майже миттєва, а ANT, перебравши контроль, одразу запалює Трасувальний Екран.

Інсталяційний носій

Пакет розповсюдження (далі "набір"), іде в формі .zip архіву, який містить піддерево файлових даних, шо складає інсталяційний набір Либіді. Після завантаження, розпакуйте його так, шоб його вміст (2 директорії) ішов в кореневу директорію вашого, відформатованого як FAT, інсталяційного носія. Зверніть увагу, ніяких проміжних директорій не має виникнути (деякі архіватори розпаковують вміст архіву в нову папку з іменем архіву). Не потрібно форматувати носій або спорожнювати його, його первинний вміст залишиться на місці. Єдине, переконайтеся, шо нема конфлікту імен з тими двома папками в корені партиції вашого носія, дивіться нижче.

.iso образу для записування CD, DVD або BluRay дисків немає, того шо це було б потужне марнування — викинути 700 МБ, 4 ГБ або навіть більше місця оптичного диску на дані, які ледве дотягують до півмегабайта, особливо коли UEFI дає завантажитись з USB флешки набагато простіше. Тож, який інсталяційний носій можна використовувати і шо було б найкращим вибором, зважаючи на сказане? Хоча він може бути будь чим, шо дозволяє UEFI: USB флешка чи зовнішній ЖД або SATA ЖД (зовнішній чи внутрішній), приєднаний грати роль інсталяційного носія, і навіть відформатовані в El Torito оптичні диски, з вмістом архіву, записаному на них, рекомендується використання USB флешки для справжніх машин і її емуляції для машин віртуальних. Для останніх, залежно від емулятора, можна брати й справжню флешку. Наприклад Virtual Box дає таке. Особисто, для ВМ, вибором було емулювати носій або як USB пристрій сховища або як "запасний" SATA ЖД, вставлений для інсталяції. Для обох цих варіантів, використовується віртуальний диск якогось формату (.vhd, .vdi, .vmdk, .qcow тощо). Автор використовував .vhd. USB і SATA сценарії відрізняються лише в тому, як ви під'єднуєте ВД до емулятора, а це залежить від емулятора, звичайно.

Як сказано, Либідь не вимагає виділення всього носія для себе, треба лише дати їй покласти 2 папки в кореневу папку сховища. Нема також якихсь вимог щодо мінімального обсягу, крім очевидного, шо розпакований архів має влізти. Зараз це близько 500 КБ, більша частина чого — .bmp смаколики для Пускового Екрану. Згадані папки:

• efi — де сидить вантажник, його ресурси та clo утиліта, в підпапці Upptech.
• Lybid — Це "System Root" директорія Либіді.

Носій має бути в форматі ФС FAT, згідно з специфікацією UEFI (шоб ППЗ могло його доступитися). Неварто нагадувати, шо якшо розділ вже має папку efi в цьому місці, треба безпечно з'єднати її вміст з новим, в разі, якшо попередній вміст ще потрібен. Все, шо Либідь кладе в папку efi, вона кладе в її підпапку Upptech, не чіпаючи нічого поза. Але існує виняток. Нажаль, деякі імплементації ППЗ, хронічно не розуміючи специфікацію, думають, шо єдина річ, яку вони можуть запускати з знімних сховищ, це efi\boot\boot<ARCH>.efi, де <ARCH> це одне з цих: x64, ia32, aa64, aa32, залежно від архітектури ЦП. В цьому разі, вам доведеться скопіювати efi\Upptech\antload.efi в efi\boot\bootx64.efi, для x64, в efi\boot\bootia32.efi, для ia32 або в efi\boot\bootaa64.efi, для arm64, не забуваючи за резервне збереження попередніх файлів, якшо потрібно.

Пуск Либіді

Для ВМ, дивіться трохи далі, на справжніх машинах, вставляєте підготовлений носій, натискаєте кнопку живлення і заходите в інтерфейс ППЗ. Як, залежить від машини, ви мабуть знаєте як, якшо читаєте це. Частіше за все, це множинне натискання <F2>, <F12>, <Del> тощо на самому старті. Коли зайшли в графічний інтерфейс користувача (ГІК) Пускового Менеджера ППЗ, треба знайти Меню Пускових Опцій, якшо воно там є. Нажаль, річ, яка за всіх умов мала б бути простою і зручною, часто зроблена виробниками ані простою, ані зручною, але буває й гірше, — шукати нічого, те меню просто відсутнє. Недивно, шо можна зрештою, так і не найти, як запустити вантажник, але сподіватимемося. Зазвичай, там має бути Меню Пускових Опцій, і зазвичай, воно має опцію "Завантажити з файла"; вона дає фукнціональність файлового навігатора — сходити по виявлених FAT томах і вибрати файл вантажника. Якшо вам пощастило знайти таку опцію, це те, шо треба. Ваша USB флешка якось називається, скажімо, "Corsair Flash Voyager", це дасть вам підказку. Коли знайшли пристрій, ідіть від його кореня в efi\Upptech і вибирайте файл antload.efi, тисніть <Enter>. Це запусте вантажник Либіді.

На прикладі машин автора: з трьох x64 ноутбуків для тестування, кожен поводився по своєму:

І я впевнений, щобільше тестів пройде, то більше чудних розумінь того, шо саме має вміти Пусковий Менеджер, ми побачимо. Специфікація UEFI умисно залишає Пусковий Менеджер більшою мірою "на розсуд" імплементатора. Якби ж той "розсуд" ще був земного походження... Тобто тестування навіть цього "голого" набору є не без вигід. Мати ваші відгуки з приводу, було б дуже добре, щонайменше, бо, як бачите, цей "простий в досягненні" крок, може бути не таким простим як хотілося.

Як можливий вихід з ситуації відсутности засобу пуску вантажника з ППЗ-шного графічного інтерфейсу, може бути ще ось такий варіант, якшо, звичайно, він доступний — інтерфейс командного рядка UEFI, ІКР, або, як його обізвали творці — "оболонка UEFI". Нажаль, вона не йде в комплекті машинного ППЗ в більшості випадків і втулити її в проблемні платформи так же важко як втулити вантажник. Адже, зрештою, ця оболонка, теж UEFI програма і їй треба пускова опція, шоб її можна було запускати. Але, якшо раптом ваша машина має оболонку, ви можете просто зайти в неї і набрати:

"N" це номер, який ППЗ призначило тому на USB флешці, його можна легко вияснити, бо коли UEFI ІКР стартує, він видруковує виявлені пристрої сховища. Флешка має легко розпізнаватися через "USB" вузол в своєму шляху пристрою (який видруковується). Можете також перевірити видруковані "fs" на наявність в них директорії efi\Upptech, "лістингуючи" її (командами dir або ls) тощо.

І ще. Якшо ваша машина має увімкнений Secure Boot, мабуть треба буде його тимчасово вимкнути. Я мав такий випадок з Галлієм, вимкнув його і тримаю вимкненим. Ви можете ввімкнути його назад після тестів. Брак тестових машин не дає мені сказати багато з цього приводу. Наскільки в реальності Secure Boot заважає тестам. Ваші відгуки з цього приводу теж, допомогли б.

arm64 специфіка

Все сказане вгорі в цій секції, прикладається до машин з добре розробленою імплементацією UEFI (не рахуючи згаданої марсіанської логіки в створенні Пускового Менеджера). І назараз, це переважно звичайні x64 ПК. На arm полі, все ще досі в жалюгідному стані. Якшо ви все ж маєте крутий arm64-івський ноутбук чи розробницьку машину як ECS LIVA Mini Box QC710 Desktop з Qualcomm Snapdragon 7c SoC або схоже і хочете поганяти тести Либіді на них, тоді просто дотримуйтесь інструкцій вгорі, бо цей випадок не повинен відрізнятися від своїх x64-х напарників, дякуючи Microsoft-івським вимогам до виробників заліза підтримувати стандарти UEFI і ACPI, якшо вони хочуть мати Windows на своєму залізі. Якшо ж ви зібралися пробувати на одному з arm64-івських ОПК, шо набагато реалістичніше, тоді це якийсь з двох варіантів для вашої машини:

• вона має EDK2 порт
• вона має лише той рівень підтримки UEFI, який іде в доступному для неї uboot-і

Для першого випадку, це все, шо треба, це повністю сумісна, референтна імплементація від UEFI Форуму. Єдина проблема, це та, шо майже не існує плат, на які було портовано EDK2. Я чув лише за пару таких: для rk3566 від Jared McNeill і для rk3588 від Renegade Project. Якшо маєте такий майданчик, то запускаєте вантажник або через "Завантажити з файла" в меню Пускового Менеджера або через оболонку, як вже розказано, залежно від шо доступно і вашого вподобання. Не маю зараз arm-івських плат, лишилися назавжди дома в зруйнованому росіянами Бахмуті. Перед війною, тестував варіант справжнього arm64-івського заліза на Ксеноні, Rock Pi 4B від Radxa з rk3399. Ця платформа мала солідну підтримку UEFI на стороні uboot-а (навіть GOP). І це підводе нас до цього другого варіанту. Якшо ви маєте ОПК з солідною підтримкою UEFI в uboot-і, можете спробувати потестувати. Нижче, дана специфіка як це робити на таких платформах.

По перше, поки, мабуть краще беріть SD картку замість USB флешки (це може також стосуватися параграфа вище, якшо порт EDK2 ще не підтримує USB як треба). Це того, шо підтримка інтерфейсу SD тут більш гарантована, зважаючи на його особливу роль в ОПК як одного з основних джерел вантаження. Можете використовувати й USB, якшо на 100% переконані, шо він підтримується як належить. Зверніть увагу, шо хоча uboot приносе підтримку ФС ext4 до свого UEFI, не використовуйте цю ФС в тестах. Беріть носій у форматі FAT. Існує принаймні 2 причини для цього: пізніше, коли Либідь перебере контроль від вантажника, їй буде треба доступатися свого Пускового Тому самій, а вона не розуміє ext4 і, якшо цього не досить, SD Асоціація вимагає, шо шоб SD картки робили правильно, вони мають бути форматовані в визначений спосіб, в якому нема опції мання ext4.

В будь якому разі, розпакуйте архів так само та вставте носій в плату. Приєднайте монітор до HDMI порту плати та з'єднайте USB-TTL адаптер з UART-овими пінами на платі і USB портом вашої робочої машини, яка служитиме як термінал. В робочій машині, запустіть програму, яка читатиме цей послідовний порт, наприклад Putty, ввімкніть плату і зайдіть в uboot-івський ІКР, повторно тиснучи клавішу, з терміналу, частіше за все це <Space> або "q", вони постійно їх міняли через відомі лише їм причини. Приєднувати клавіатуру до тестової машини поки нема потреби. Після входу в ІКР, введіть цю команду:

де X:Y це uboot-івське нумерування для пристроїв на їхніх шинах. X це номер кишені SD картки на SD-MMC інтерфейсі, а Y це номер партиції на вказаному пристрої сховища. Я так думаю. Тож, найімовірніше, це буде або 0:1 або 1:1. Він дасть знати, чи він знайшов, шо його питали, тож зможете переробити в разі неуспіху. <address> — це адреса, куди вантажити образ. Вона залежить від сімейства SoC, наприклад для Rockchip-ових чипів, 0x02080000 це шо я використовував, бо бачив, заглядаючи в uboot-івські змінні середовища, шо він вантаже туди своє навантаження за замовчуванням (Armbian). Це кілька сотень КБ від доступної фізичної стартової адреси. Для Rockchip-у, старт це — 0x02000000, для Allwinner-а, — 0x40000000, якшо правильно пам'ятаю. Тож, ми застрибуємо 512 КБ вперед і просимо uboot вантажити нас туди. Знову, якшо ця адреса не може бути взята, uboot скаже. Ще, ставте слеші, бо uboot не дуже розуміє бекслеші як розділювач шляху. І не забувайте за .efi розширення, це не UEFI оболонка, яка дає. Після того, як ви зчитали вантажник, нарешті вводите цю команду, яка його запусте:

<address> той самий, шо в першій команді. Сходіть на цю сторінку, під кнопкою "Ксенон ганяє демо Пускового Екрану", можете подивитись відео демонстрацію описаного вище процесу, зроблену ще в незруйнованому домі, якраз для arm64-івського ОПК випадку, на Ксеноні.

Віртуальні середовища

Платформне ПЗ

Як таке, ми беремо OVMF, EDK2 порт для віртуальних машин. Його вигляд та спосіб налаштування й використання майже однакові для всіх архітектур. Використовувались емулятори Qemu та Virtual Box. Останній доступний лише для x86. Інші емулятори, які надають UEFI, теж можна брати, але ви маєте знати як з ними працювати. Обидва емулятори ідуть з файлами постійного (флеш) сховища OVMF, проте Virtual Box автоматично створює помашинні копії для ППЗ-шного сховища даних, щоразу, як створюється нова ВМ (файл .nvram). Це сховище, це емуляція тієї частини флеш пам'яти ППЗ, де зберігаються її дані, які можуть змінится. Воно пишеться під час використання ВМ, це місце зберігання пускових опцій наприклад. З Qemu, вам доведеться подбати про створення таких копій самим. Власне, ви маєте скопіювати файли змінного ППЗ сховища для ВМ Либіді в якусь директорію і вказати на них в налаштуваннях ВМ. Приклади даються нижче.

Інсталяційний носій

Як вже сказано, рекомендований шлях, це створення віртуального диску в улюбленому форматі і приєднання його до ВМ або як пристрою сховища USB або як SATA ЖД/ТТД. Створюєте ВД, хай це буде .vhd, зручний, розпізнається всіма емуляторами, легко використовувати на хостовій ОС. Шоб зекономити місце на диску хосту, не робіть преалокацію повного обсягу (за замовчуванням, Virtual Box робе диски з динамічною алокацією). Щодо розміру ВД, то для інсталяційного носія, 32 МБ буде досить, для інстальованого випадку, можна взяти більше. Схема партиціонування може бути або MBR або GPT. Створіть партицію на диску. Нема потреби позначати її як "ESP" (EFI System Partition), UEFI працює з звично типізованими FAT партиціями так же добре. Форматуйте партицію або як FAT16 або FAT32, неважливо яка саме і розпакуйте в її корінь вміст архіву, точно так як вже описано. Диск готовий. Як саме зробити ці кроки, сильно залежить від утиліт, з якими вам подобається працювати. Я робив .vhd з Virtual Box-ом а форматував і прикручував їх до хосту за допомогою diskpart. Впевнений, ви знаєте як це робити з вашими утилітами. Читайте тут для послідовності дій на прикладі diskpart.

Конфігурування віртуальної машини Virtual Box

Можете грати з налаштуваннями, які цей емулятор дає, створюючи ВМ на ваше вподобання. Либідь розрахована бігати на будь якій 64 бітній x86 платформі з UEFI. Нижче, основне з конфігурації, яку я виставив для моєї Virtual Box-ової ВМ для Либіді:

За послідовний порт. Шоб бачити трасувальний друк antload, були виставлені налаштування порту вище. На нашому Windows хості, ми направили Virtual Box брати іменований канал (назвали його antvboxuart) для емуляції порту. Virtual Box створює цей канал на старті ВМ і тоді ви під'єднуєтесь до нього, скажімо, через Putty і так бачите, шо antload виводе підчас своєї роботи. Якшо ви на іншій ОС, використовуйте її засоби створення послідовного порту для Virtual Box і вашу улюблену програму для доступу до нього.

Під'єднуєте віртуальний диск носія у вкладці "Сховище" або до AHCI контроллера або до USB, залежно від вподобань (уже обговорено).

Конфігурування віртуальної машини Qemu

Для Qemu, найпростішим способом сказати, шо потрібно, це виписати опції створення ВМ. Можна також створити скрипт для простішого запуску в вашому улюбленому ІКР.

Де взяти файли ППЗ, коду й даних (змінних)? Принаймні, в піддиректорії share Qemu інсталяції. .fd файл для x64 коду називається edk2-x86_64-code.fd, для ia32, це edk2-i386-code.fd Сховище для даних, однакове для обох бітностей, це edk2-i386-vars.fd. В разі тестування і на ia32, не забувайте, шо обидві бітності вимагають своєї власної копії сховища для даних, насправді, копія має бути на кожну окрему ВМ. Для arm64, код і дані, відповідно, edk2-aarch64-code.fd та edk2-arm-vars.fd. Можете скопіювати файли деінде, назвати як хочете, потім вкажіть на них як в прикладах вище.

Запуск Либіді

Як з будь якою EDK2 імплементацією: або через графічне меню Пускового Менеджера, з опції "Завантажити з файла" або з UEFI ІКР, описаного вище. Коли ви вмикаєте ВМ, вона запускає якусь опцію за замовчуванням. Це може бути оболонка UEFI, а може бути й шось інше. Якшо це вона, запускаєте вантажник прямо там, або командою exit виходите в Пусковий Менеджер і запускаєте звідти. Опція "Завантажити з файлу" Пускового Менеджера EDK2 — це нормальний файловий навігатор, який дозволяє вибрати файл вантажника й запустити його.

Іноді, як з новішіми версіями Virtual Box, на першому пуску ВМ, можна наштовхнутися на неприємне зависання, яке насправді є очікуванням, того шо за замовчуванням, мережні пускові опції опинились вище за опцію пуску UEFI оболонки, і якшо ви не прибрали мережу з порядку пристроїв вантаження, воно може вилится в довге чекання. Вирішити проблему можна або видаливши мережу з порядку пристроїв вантаження в налаштуваннях ВМ або, натискаючи <F2>, підчас наступного старту ВМ, зайти в Пусковий Менеджер і там, пішовши в Менеджер Підтримки Вантаження ("Boot Maintenance Manager"), поміняти порядок пускових опцій так, шоб UEFI оболонка була першою. Не забудьте зберегти це. Тоді або прямо тут запускайте Либідь з "Завантажити з файла" або запускайте оболонку в меню пускових опцій і запускайте Либідь звідти, на ваш смак.

Додаткові тестування

Мати можливість запускати Либідь через її пускову опцію — необхідність для розробки, а також це може бути цікаво для ранніх тестувальників. Оскільки зазвичай, створення пускової опції стається під час інсталяційного процесу і оскільки Либідь ще не має такого, було зроблено тимчасове рішення для цього — утиліта clo. Всі необхідні вступні пояснення, теорія, і як її використовувати розрослися достатньо для своєї окремої сторінки. Читайте її тут, шоб взнати деталі і чи ви хочете брати участь в цьому додатковому тестуванні, але якшо ви вирішете брати, знову, будь ласка, розгляньте можливість розказати за свій досвід, це важливо. Шліть звіти або на vlrzprgts на гуглопошті або на upptech на outlook.

Завантаження

Оновлення 3 приносе історичне передавання контролю в ANT. Внаслідок чого, ви побачите Трасувальний Екран з щойно народженого середовища ОС. Покишо, цей екран показує лише вітання від ANT та трохи інформації за наявну оперативну пам'ять. Після друку, ANT шле процесор простоювати, "загальтивши" його, каже йому виконувати інструкцію hlt тобто (wfe для arm64). Середовище ще дуже голе, — нема обробки винятків, обробки натискання клавіш. Тож будь ласка, не міняйте вмісту в папці Lybid. Крім образів ядра, там лежать шрифти, конфігурація. Змінення цих ресурсів може спричинити винятки (які ще не обробляються). Після тесту, вимкніть машину через меню емулятора. Якшо ви досить сміливі тестувати це оновлення на справжньому залізі, тоді вимкніть машину кнопкою живлення. Тестування на справжньому залізі не є небезпечним, але воно може закінчитися необробленими винятками, а це ніколи не приємно, ані з психологічної т.з. ані з гастроентерологічної. Якшо, все ж, душа лежить потестувати, розгляньте можливість сфотографувати результат і надіслати його на якусь з пошт, вказаних на цій сторінці.

x64, оновлення 3, 06.03.2025

Станом на оновлення 06.03.2025, antload перевіряє підтримку NX та позначає усі невиконувані сутності як такі за допомогою цієї можливости. Тепер це вимога. Вантажник зупинить завантаження, якшо ця можливість не підтримується (погодьтесь, це справді потрібна можливість, вона зрізає пріснопам'ятну експлуатацію переповнення стекового буфера). ANT запрограмована використовувати 4-х рівневу трансляцію в повному обсязі, шо дає мати до 256 ТБ процесного адресного простору.

arm64, оновлення 3, 06.03.2025

Нарешті, після тижня боротьби з своїми ж дурними помилками та величезним, намудрованим arm-івським мануалом, arm64 досяг точки оновлення 3, і тепер він теж має стрибок в ANT, так же як і його x86 напарники, з якими стрибок був так набагато простішим. Поведінка ANT така сама: вітання, трохи інформації з карти пам'яти і далі простоювання. На arm64, ANT використовує 3-х рівневу трансляцію в повному обсязі для обох регіонів: TTBR0 і TTBR1, шо дає сумарно 1 ТБ процесного адресного простору. Це бачиться добрим балансом між розміром простору і швидкістю трансляції. arm-івська можливість "Ніколи не виконувати" ("Execute never"), аналог NX теж використовується. Як і сторінкові кластери (великі сторінки) на великих сутностях для пришвидчення трансляції.

Ваша участь в тестуванні на справжньому залізі для arm64 особливо бажана, оскільки, як сказано, я не маю, покишо, такого. Але зверніть увагу, на оновлення 3, antload ще не надбав переходу з EL2, тож якшо ППЗ вашої машини бігає на цьому рівні, як є наприклад з uboot-ом на rk3399, тоді antload просто вийде спокійно з кодом помилки 2d:44, яка означає "поточний рівень винятків є не EL1, ще не підтримується". Це в списку найближчих додавань, тож, antload скоро вмітиме робити цей перехід. Цей брак не впливатиме на машини, чиє ППЗ бігає на EL1, шо є, наприклад, принаймні в випадку певних Qualcomm-івських чипів. Також, EDK2 порти, доступні для деяких arm-івських СнЧ, можуть бігати на EL1. Кандидати суть rk3566, rk3568, rk3588 плати, де такі порти наявні й навіть новіші Raspberry Pi, тож якшо ви маєте такі, будь ласка, розгляньте можливість потестувати й позвітувати.

ia32, оновлення 3, 06.03.2025

Все як і для x64, але з більшими зусиллями в досягненні стрибка через більше помилок, всеодно не можна навіть порівняти з битвою на arm64. :D Фаза трампліну на x64 і ia32 пройшла як легкий бриз. Тепер тут antload також стрибає в ANT, а та, в свою чергу, друкує вітання, а тоді Менеджер Пам'яти пише трохи інформації за наявну пам'ять з UEFI-шної карти пам'яти. І потім система іде в простоювання в очікуванні на бурну діяльність шо додаватиме до подальшої ініціалізації.

PAE не виставлено, на відміну від PSE, шо означає доступність 4 МБ-них "великих" сторінок (які ми називаємо кластерами) й змогу адресувати до 1 ТБ фізичної пам'яти (40 бітів). Шкода, шо крім емуляторів, майже немає платформ для UEFI-шного ia32. Майже всі лише 32 бітні x86 машини мають BIOS на борту як ППЗ. І жодна з них не мала б більше, ніж 4 ГБ ОЗП. Саме того PAE не ввімкнене. PSE, з іншого боку, використовується для кластерного відображення образів ядра, наприклад, та інших великих сутностей, шо дає оптимізувати те саме відображення. NX можливість, в "старому", 32 бітному режимі трансляції, очевидно, недоступна.

Шрифти

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