Про те, як я збираю свої ядра версій 2.6.
Майже повністю застосовно до ядер 3.х в Slackware 14 і наступних.
Я виконую команди з терміналу X, в відповідний момент використовую графічну версію конфігуратора ядра. Я входжу в систему від свого імені, але збираю ядра від імені суперкористувача root. Щоб дозволити root використовувати мій дисплей X, я роблю наступне в терміналі X: отримую права root; поєдную свій (alien) файл Xauthority c однойменною файлом користувача root і встановлюю змінну оточення DISPLAY. Це дає можливість запускати додатки X з терміналу «su».
Замість цього можна виконати наступні 2 команди, які дадуть той же результат:
Завантаження і конфігурація
Тепер, коли складальне оточення налаштоване, перейдемо до отримання вихідного коду.
Тепер візьміть конфігураційний файл ядра Slackware як основу для вашої конфігурації. Файли Патріка є досить загальними. Можливо, коли ви читаєте ці рядки, доступна конфігурація для нового випуску 2.6:
Замість цього можна скористатися конфігурацією поточного працюючого ядра:
Зараз у вас налаштоване досить загальне ядро (ймовірно тому Патрік називає їх «kernel-generic») і ви захочете змінити деякі з замовчувань під свої потреби. Запустіть графічний конфігуратор (якщо ви замість X використовуєте текстовий термінал, запустіть «make menuconfig» щоб запустити засновану на curses диалоговую програму)
Пройдіться по лісі налаштувань. Що зазвичай міняю я (в Slackware 13.37 і пізніше), це:
Збірку в ядро ext3 і ext4 (також вимагає драйвер jbd) і драйверів файлових систем reiser / xfs / jfs замість збірки модулями - це позбавляє від необхідності в «initrd».
(Дивіться розділ «Filesystems» в конфігураторі).
Підтримку 64Гб ОЗУ.
( «Processor type and features»> «High Memory Support (64GB)»). Використовуйте для систем з 4 ГБ ОЗУ або більше.
Підтримку чуйності ( «low-latency») ядра якщо комп'ютер настільний / переносний - мультимедійні додатки працюють набагато плавніше.
( «Processor type and features»> «Preemption model»> «Preemptible kernel»). Для настільної системи з великою кількістю мультимедійних додатків це корисна опція, оскільки зберігає чуйність системи навіть при високому навантаженні.
Встановлюю таймер в 1000 Гц ( «Processor type and features»> «Timer Frequency»> «1000 Hz»). Підвищена частота може бути корисною для мультимедійних # 'Настільних #' систем.
Або включаю тактонезавісімий таймер ( «Processor type and features»> «Tickless System (Dynamic Ticks)»).
Якщо ви (пере-) збираєте ядро Slackware, потрібно переконатися що установка нового ядра залишить оригінальні модулі недоторканими. Для цього вкажіть унікальну рядок в поле локальна версія ядра ( «General setup»> «Local version - append to kernel release»). Цей параметр ядра відповідає CONFIG_LOCALVERSION в файлі .config. В Slackware для SMP ядер цей параметр встановлений в значення «-smp».
Підсумковий номер версії ядра (що повертається «umake -r») для ядра версії «2.6.37.6» з локальною версією «-alien» буде «2.6.37.6-alien».
... і ще щось, про що прямо зараз не згадаю. Ви можете вирішити відключити більшість зібраних в конфігурації за замовчуванням модулів для зменшення часу компіляції, якщо таке обладнання відсутнє в вашому комп'ютері. Якщо у вас лептоп, також можете звернути увагу на параметри software suspend і CPU frequency scaling (розділ «Processor type and features»).
І, нарешті, збережіть конфігурацію, якщо вона вас влаштовує.
збірка ядра
Тепер запустіть збірку ядра, модулів і їх установку на належне місце.
Для ядер 2.6.x має бути досить виконати «make» або «make all» замість «make bzImage modules». В цьому випадку будуть зібрані цілі за замовчуванням: vmlinux (нестиснене ядро), bzImage (стислий ядро, яке ми і будемо використовувати) і modules (всі модулі ядра). Оскільки нестиснене ядро нам не потрібно, я зазвичай використовую команду «make bzImage modules».
Якщо захочете більше дізнатися про доступні цілях make. можете виконати «make help» і вивчити висновок. Цілі складання за замовчуванням відзначені зірочкою (*).
Виправлення lilo.conf
Відредагуйте /etc/lilo.conf і додайте новий розділ для нового ядра. Пам'ятайте, якщо десь була допущена помилка, ваше нове ядро може навіть не завантажитися, тому існуючі розділи поточних ядер краще залишити як є. У вашому /etc/lilo.conf ближче до кінця є розділ на зразок:
Додайте слідом інший розділ (додавання його нижче гарантує, що ваше поточне - робоче - ядро залишиться для завантаження за замовчуванням):
Після додавання розділу з новим ядром в /etc/lilo.conf потрібно зберегти файл і потім виконати lilo для активації змін:
Тепер пора перезавантажитися і перевірити нове ядро! Коли з'явиться завантажувальний екран lilo, виберіть «newkernel» замість «linux» за замовчуванням.
Якщо ваше нове ядро завантажується як годиться, можна зробити його завантажуваних за замовчуванням, додавши наступний рядок в початок /etc/lilo.conf і перезапустивши «lilo»:
Пакет Slackware kernel-headers
Ви вирішили зібрати і використовувати нове ядро. У вас може з'явитися питання, що робити з пакетом Slackware kernel-headers.
Відповідь: не видаляйте цей пакет!
Заголовки ядра можна виявити в двох місцях; одне - всередині каталогу вихідного коду ядра (в нашому випадку - каталог /usr/src/linux-2.6.37.6), інше - / usr / include / linux. Пакет kernel-headers зазвичай містить заголовні файли, взяті з вихідного коду ядра Slackware за замовчуванням. Саме ці заголовки були використані при складанні пакету glibc. Той факт, що пакет kernel-headers встановлює ці файли в / usr / include / linux робить їх незалежними від заголовних файлів в каталозі вихідного коду ядра.
Ще не оновлений пакет glibc ви не повинні оновлювати або видаляти відповідний йому пакет kernel-headers.
Як пов'язані пакети kernel-headers і glibc?
У якийсь момент часу ви побажаєте оновити (перекомпіліровать!) Частини програмного забезпечення вашої системи. Якщо це ПО пов'язано (слінковано) з glibc (як більшість основного ПО), його успішна компіляція залежить від наявності відповідних заголовків файлів ядра в / usr / include / linux. Використання зовсім іншого ядра замість поставляються за замовчуванням в Slackware не має значення. Пакет kernel-headers відображає стан системи в процесі побудови glibc. Якщо видалити пакет kernel-headers. на роботі системи це жодним чином не позначиться, але ви не зможете (пере-) компілювати більшість ПО.
Чи потрібен вихідний код ядра для чого-небудь після того, як ядро вже зібрано?
У попередньому абзаці я говорив, що для компіляції системного ПО використовуються заголовки, розташовані в / usr / include / linux. Однак, дерево вихідного коду ядра потрібно для збірки сторонніх модулів ядра (madwifi, linux-uvc, ndiswrapper, ... цей список кінця не має). Ви не обмежені в компіляції драйвера тільки для завантаженого в поточний момент ядра. Ви можете збирати драйвери для будь-яких ядер до тих пір, поки на місці їх дерево модулів (нижче / lib / modules) і вихідний код.
Припустимо, ви збираєтеся зібрати модуль для ядра, версію якого вказали в змінної оточення $ KVER. Наприклад, виконавши
Інші пакети, що містять модулі ядра
Напевно у вас будуть встановлені один або кілька пакетів, які містять модулі, які не входять до складу використовуваного за замовчуванням ядра. Наприклад, Slackware встановлює «svgalib-helper»; якщо ви встановили драйвери бездротової мережі, то вони, як правило, теж є модулями ядра.
Майте на увазі, що після установки і завантаження нового ядра ці не входять до складу ядра модулі стануть недоступні. Вам доведеться перекомпілювати їх вихідний код для отримання модулів, відповідних версії нового ядра.
Отримати список всіх пакетів, що містять модулі для поточного ядра, можна за допомогою команди (її потрібно виконувати при завантаженому старому ядрі):
Всі перераховані пакети зажадають перекомпіляції, якщо ви хочете, щоб їх модулі були придатні і для нового ядра.
Якщо ви пересобран пакет, що містить модуль ядра, використовуйте для його встановлення не upgradepkg. а installpkg. який не стане видаляти оригінальну версію модуля.
upgradepkg видалить модуль старого ядра, який ще може вам знадобитися для перезавантаження зі старим ядром. Цей трюк заснований на припущенні, що версія ядра є частиною поля ВЕРСІЯ імені пакета, як тут: svgalib_helper-1.9.25_2.6.37.6 -i486-1.txz (Знаю, що приклад ущербний, оскільки такого пакета більше немає).
Описаний вище метод не має відношення до модулів ядра, які ви скомпілювали і встановили вручну замість створення пакетів для них. Іноді пропрієтарні графічні драйвери, такі як від Nvidia або Ati. можуть стати причиною для занепокоєння, якщо забути перекомпіліровать їх для нового ядра до запуску X Window ... особливо якщо ваш комп'ютер за замовчуванням завантажується в графічний рівень виконання (runlevel) 4.
В цьому випадку перезавантажитеся в рівень виконання 3. скачайте останню доступну версію графічного драйвера і скомпілюйте / встановіть драйвер. Це дозволить вам перезавантажитися в графічний екран входу в систему. Для тих, хто забув, завантажитися в інший рівень виконання просто: коли відобразиться екран LILO, наберіть мітку вашого ядра (в нашому прикладі вище це newkernel) і номер рівня виконання: Newkernel Пропуск 3 Введення.
створення initrd
Якщо в ядро не включені драйвер для вашої кореневої файлової системи, або драйвер для шини SATA, або щось ще, зібране модулем, то ядро запанікує при завантаженні, не маючи можливості отримати доступ до необхідних дискам, розділів і / або файлів. Зазвичай це виглядає так
і означає, що вам необхідно зібрати initrd (скорочення від «Initial Ram Disk») - диск в оперативній пам'яті для початкової ініціалізації, що містить необхідні модулі. Потім шлях до initrd додається до відповідного розділу /etc/lilo.conf. щоб ядро при завантаженні змогло його знайти і завантажити драйвери для доступу до ваших дисків. Створити initrd досить просто, нижче я покажу 2 варіанти, один для випадку, коли для кореневого розділу використовує файлову систему Рейзер, інший - для ext3. Нижче я привожу команди для ядра версії 2.6.37.6, якщо версія вашого нового ядра відрізняється, змініть номер версії в командах відповідним чином.
Перейдіть в каталог / boot.
Виконайте «mkinitrd» для створення файлу /boot/initrd.gz. що містить стислу файлову систему з модулями, заданими в командному рядку:
для файлової системи Рейзер або
якщо для кореневого розділу ви використовуєте файлову систему ext3.
Додайте рядок «initrd = /boot/initrd.gz» в розділ newkernel файлу /etc/lilo.conf. збережіть зміни і запустіть lilo; я буду використовувати раніше наведений приклад розділу lilo.conf.
При наступному завантаженні ваше нове ядро панікувати перестане.
Якщо ви вже використовуєте образ initrd з вашим поточним ядром, у вас є два варіанти:
Створити інший образ initrd за допомогою показаної вище команди, вказавши ім'я створюваного файлу initrd (яке повинно відрізнятися від використовуваного за замовчуванням, щоб вже існуючий файл не був перезаписан):
і потім змінити розділ в lilo.conf подібним чином:
Додати модулі для вашого нового ядра в існуючий файл initrd. Таким чином у вас вийде один образ initrd, що містить модулі для декількох ядер. Все, що вам для цього буде потрібно зробити - це прибрати параметр «-c», який призначений для попереднього очищення каталогу / boot / initrd-tree.
Я написав сценарій оболонки (mkinitrd_command_generator.sh).
Скрипт нічого не робить з системою. Він проаналізує вашу працюючу систему Slackware і покаже приклад команди mkinitrd. Якщо ви виконаєте цю команду, буде створений образ initrd, який буде містити всі модулі ядра і бібліотеки, необхідні для завантаження системи з generic ядром Slackware.
Ось приклад запуску команди і її виведення:
Ви можете відзначити, що мій зашифрований по LUKS кореневий розділ був пізнаний.
Цей сценарій включений в пакет mkinitrd починаючи з випуску Slackware 12.2.
Вантаження модулів при завантаженні
До Slackware 11.0 модулі для вашого ядра завантажувалися або підсистемою гарячого підключення (hotplug), або командами modprobe в файлі /etc/rc.d/rc.modules. Наявність загального файлу rc.modules для ядер версій 2.4.x і 2.6.x не було оптимальним рішенням.
В Slackware 12.0 і наступних більш недоступні ядра 2.4. Завантаження модулів ядра забезпечується udev і командами modprobe. модулі, які не завантажуються udev, як і раніше можуть бути прописані у файлі rc.modules. Тільки тепер цих файлів може бути більше одного. Slackware перевіряє існування нижченаведених виконуваних файлів в такому порядку:
Якщо існує /etc/rc.d/rc.modules.local. він буде запущений
Інакше, якщо існує /etc/rc.d/rc.modules-$(uname -r). він буде запущений
Інакше, якщо існує /etc/rc.d/rc.modules. він буде запущений
$ (Uname -r) - це версія поточного ядра. Якщо версія вашого ядра 2.6.37.6-smp. то Slackware перевірятиме наявність файлу /etc/rc.d/rc.modules-2.6.37.6-smp. Таким чином, можлива наявність спеціальних файлів rc для різних ядер, що дозволяє налаштовувати вашу систему оптимальним чином.
В Slackware 13.37 пакет /slackware/a/kernel-modules-smp-2.6.37.6_smp-i686-1.txz встановлює файл /etc/rc.d/rc.modules-2.6.37.6-smp. Ви можете використовувати його в якості прикладу на випадок, якщо захочете зібрати своє ядро, яке потребує завантаження окремих модулів за допомогою команд modprobe.
Файл /etc/rc.d/rc.modules-2.6.38.2.alien буде використаний при завантаженні вашого нового ядра 2.6.38.2.alien.
підпис GPG
Архіви вихідного коду ядра підписані ключем OpenPGP «Linux Kernel Archives Verification Key» (перевірки ключ архівів ядра Лінукс). Це дозволяє упевнитися, що завантажений вами вихідний код є оригінальним архівом і не був підроблений. У цьому розділі описано спосіб такої перевірки.
Спочатку імпортуйте ключ OpenPGP в GnuPG або скопіювавши ключ зі сторінки підпису або імпортувавши його з сервера ключів. Ідентифікатор ключа ядра 0x517D0F0E. Приклад виглядає наступним чином:
Висновок буде на зразок такого:
Потім завантажте файл підпису для завантаженого архіву ядра:
і переконайтеся, що він знаходиться в тому ж каталозі, що і архів ядра.
На останньому кроці запустіть gpg на цьому файлі підпису і перевірте, що він виведе:
Висновок буде як тут:
Якби ви вказали gnupg довіряти цьому ключу, завершальна частина виглядала б інакше. Як на мене, додавання цього ключа в список довірених не має практичного сисла, якщо тільки ви не зустрілися з одним з розробників ядра, у якого при собі був ключ і який міг пред'явити заслуговують на довіру повноваження.
Проте, архів з вихідним кодом дійсно підписаний ключем, який ви тільки що імпортували. А це хороша новина.
Справжній переклад на російську: Serg Bormant