Форум Slackware Linux

Резюме:

Slackware-13.37, smp, корень ext4 на /dev/sda2:
В /etc/lilo.conf после строки, начинающейся с "image = " добавить строкув итоге получится что-то вроде:Затем выполнить:
Slackware-13.37, не-smp, корень ext4 на /dev/sda2:Правки в /etc/lilo.conf см. выше.
Затем выполнить:
Slackware64-13.37, smp, корень ext4 на /dev/sda2:Правки в /etc/lilo.conf см. выше.
Затем выполнить:

_________________
irc://freenode.net/##slackware-ru

Подробно:

В составе Slackware (32-битной) поставляются по 2 -huge- и -generic- ядра. По одному из каждой пары собраны с поддержкой мультипроцессорности и имеют суффикс -smp и в имени пакета, и в номере версии.
Оставшиеся два собраны без поддержки многопроцессорности. При их использовании для сборки сторонних модулей требуются дополнительные телодвижения, которые описаны в /extra/linux-*-nosmp-sdk/README.TXT и здесь не рассматриваются.

В составе Slackware64 поставляется по одному -huge- и -generic- ядру. Оба собраны с поддержкой мультипроцессорности, суффиксов -smp не имеют.

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

В -generic- (общее) ядро вкомпилировано только самое необходимое, всё остальное, включая поддержку файловых систем, вынесено в модули, которые подгружаются при необходимости из корневой файловой системы (/) или из диска начальной инициализации в оперативной памяти (Initial RAM disk, общепринятое сокращение initrd). initrd призван решить проблему курицы и яйца для модульного ядра: для монтирования файловой системы необходим модуль для работы с диском и файловой системой, а для чтения модуля необходима файловая система, с которой этот модуль читается. В версиях 2.6+, 3+ используется сжатый gzip'ом cpio-архив.

Модули ядра для каждой версии поставляются в отдельных пакетах kernel-modules-версия для -smp и не-smp ядер.

Кроме того, некоторое оборудование для полноценной работы требует наличие бинарных прошивок, которые поставляются в пакете kernel-firmware, общем для всех ядер и архитектур.

Пакеты с ядрами, модулями, прошивками входят в серию A. Если в /dvd смонтирован дистрибутивный носитель, для 13.37:

Если серия A устанавливалась целиком, то использовано huge-smp ядро. Объяснение довольно простое. В файле конфигурации загрузчика /etc/lilo.conf по умолчанию используется "image = /boot/vmlinuz". В стоковых пакетах с ядрами присутствует скрипт doinst.sh, устанавливающий символические ссылки /boot/vmlinuz, /boot/config, /boot/System.map на соответствующие файлы из пакета. setup ставит пакеты в алфавитном порядке, поэтому указанные ссылки будут установлены на файлы из последнего установленного пакета с ядром. В этом несложно убедиться:

Описание перехода на generic ядро приведено в /boot/README.initrd. Суть этой процедуры довольно проста: проверить установку необходимых пакетов, сгенерировать initrd и заставить загрузчик передать его ядру в параметре initrd=.

К необходимым пакетам относятся собственно -generic- ядро, соответствующие ему модули и mkinitrd -- утилита создания initrd. Поскольку пакетный менеджер Slackware хранит информацию об установленных пакетах в /var/log/packages, проверка наличия сводится к:

а проверка и установка в случае отсуствия к
Slackware, только smp:

Slackware, только не-smp:

Slackware, и smp, и не-smp:

Slackware64:

Как нетрудно заметить, различие только в пути и файловой маске.

Далее, создадим initrd.

-c -- создавать структуру дерева initrd заново, а не добавлять к существующей,
-k -- использовать указанную версию ядра. Если используется huge ядро той же версии (с учётом smp), можно не указывать, будет использована версия текущего ядра, то есть $(uname -r),
-r -- корневой раздел. Если не указать, mkinitrd попытается определить самостоятельно по /etc/mtab (списку смонтированных файловых систем). В одной из предыдущей версий была ошибка, заключавшаяся в некорректном определении имени корневого раздела, поскольку в /etc/mtab присутствовал /dev/root, а не реальное имя раздела, такое как /dev/sda2,
-f -- файловая система корневого раздела. Если не указать mkinitrd попытается определить самостоятельно. Иногда такая самостоятельность приводит к получению нерабочего initrd,
-m -- список модулей для включения в initrd. Необходимо указать модули, обслуживающий корневую файловую систему, список указывается через двоеточие. Помимо непосредственно указанных модулей, будут включены их зависимости.

Для помощи в формировании параметров команды mkinitrd в Slackware включён вспомогательный скрипт, пример выполнения:

Подробнее об использовании mkinitrd_command_generator.sh можно узнать, запустив его с ключом -h либо --longhelp, или проанализировав его текст.

Переключим ссылки в /boot на -generic- ядро. Проще всего это сделать при помощи doinst.sh из пакета соответствующего ядра. Поскольку эти скрипты хранятся менеджером пакетов в /var/log/scripts в файле с полным именем пакета, и предполагают, что текущим каталогом является корневой каталог (/), то

Slackware, smp:

Slackware, не-smp:

Slackware64:

Поправим параметры загрузчика. В /etc/lilo.conf после строки, начинающейся с "image = " добавим строку

в итоге получится что-то вроде:

Затем выполним


Зададимся вопросом, что случится при перезагрузке, если что-то было сделано неправильно? Нетрудно догадаться, что результатом будет паника ядра -- Kernel Panic и загрузка системы остановится ещё на этапе попытки смонтировать корневую файловую систему.

Страшно? Нисколько, если умеете использовать дистрибутивный диск Slackware для загрузки установленной системы (на стартовом экране SYSLINUX есть недвусмысленная инструкция на этот счёт), либо какой-либо другой диск для той же цели, либо используете в качестве загрузчика GRUB/GRUB2/иной, которые позволяют интерактивно указывать, что и как загружать.

Но почему бы заранее на всякий случай не "подстелить соломки", тем более, что затраты минимальны?

Добавим в /etc/lilo.conf отдельный пункт загрузки huge ядра по его имени:

и выполним

Обратите внимание, в image указано полное имя файла ядра (в данном случае Slackware, smp, для других вариантов скорректировать его не составит труда), в label уникальное имя пункта меню. Чтобы любое изменение /etc/lilo.conf вступило в силу, необходимо выполнить lilo. Хотя вы всё это и без меня знаете по man lilo.conf, поэтому не буду занудствовать.

Теперь есть возможность загрузить huge ядро, выбрав в меню загрузчика пункт LinuxHS.

Перезагружаемся.

И да, удачи.


ps. Отсутствие ошибок в тексте не исключаю, все манипуляции только на ваш риск.

PPS.
Начиная со Slackware 14.2 пакеты ядра теперь дополнительно устанавливают ссылки без номера версии ядра:

_________________
irc://freenode.net/##slackware-ru

В использовании "image = /boot/vmlinuz" есть определённые плюсы.
Установка обновлённого стокового ядра из пакета заменит ссылку, останется пересоздать initrd и выполнить lilo. Дополнительной правки /etc/lilo.conf не потребуется. Удобно.
Установка самосборного ядра заменит ссылку на файл ядра, останется пересоздать initrd и выполнить lilo. Дополнительной правки /etc/lilo.conf не потребуется. Тоже удобно.

Но использовать эти плюсы или нет, и есть от них какая-то польза или нет, да и плюсы ли это -- решать только вам.

_________________
irc://freenode.net/##slackware-ru

Всё сделал точно по инструкции.

В конце, после выполнения lilo, выпало следующие предупреждение:


Выполнил lilo -g


Чтобы все это могло значить?

P.S.
Несмотря на сказанное выше, lilo работает нормально, система загружается без проблем (как с ядром generic-smp, так и с ядром huge-smp).

1)
Warning: LBA32 addressing assumed
означает, что хотя опция lba32 явно не указана в /etc/lilo.conf, lilo действует так, как-будто она указана.

2)
Added LinuxGS *
Added LinuxHS
означает, что загрузчик lilo установлен, сформированы 2 пункта загрузочного меню.

3)
# lilo -g
означает явное указание на использование CHS адресации

Warning: Kernel & BIOS return differing head/sector geometries for device 0x80
означает, что BIOS и ядро видят геометрию диска в терминах CHS по разному, ниже приведено, кто как видит этот диск.

Warning: device 0x0803 exceeds 1024 cylinder limit.
Use of the 'lba32' option may help on newer (EDD-BIOS) systems.
означает, что раздел 803 (sda3) превышает 1024 цилиндра, далее 1023 цилиндра невозможно адресоваться методом CHS, использование lba32 может помочь.

Fatal: geo_comp_addr: Cylinder number is too big (19400 > 1023)
означает, что ядро действительно лежит за пределами 1024 цилиндров, адресовать его методом CHS невозможно. Fatal -- сбой, MBR/BR раздела остался не изменён.

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

_________________
irc://freenode.net/##slackware-ru

bormant, то есть, как я понял, никаких ремонтно-восстановительных работ в связи с "Warning: LBA32 addressing assumed" проводить не нужно?

вы всё правильно поняли. lilo -g тоже НЕ нужно. Это для старых дисков, которые уже лет 20 не делают, вряд-ли вы такой найдёте.

_________________
slackware-current(32/64)

Warning -- это предупреждение, не ошибка. Суть его -- проинформировать, что lilo действовал так, будто ему явно указали lba32. Если раздражает предупреждение, можете вписать строчку lba32 в /etc/lilo.conf, это убрёт вывод предупреждения, на что-либо ещё не повлияет.

_________________
irc://freenode.net/##slackware-ru

bormant, drBatty, благодарю за помощь.

Господа, такой вопрос (поправьте, если не прав):
Цель перехода на generic-ядро - экономия оперативной памяти. А я в этом заинтересован сильно, так как имею мало этой самой памяти. Достигается это за счёт того, что в generic-ядре содержится гораздо меньше "вкомпилированных" модулей, чем в huge. Таким образом, generic-ядро должно занимать меньший объём в памяти. Внимание, вопрос: как это проверить? Как убедиться в том, что именно так и происходит, и ядро занимает меньший объём?

Я провёл такой эксперимент: загрузился с ядром generic в консоль, примерно замерил время загрузки с сообщения "Loading Linux......" до приглашения login, далее

Тоже самое сделал с ядром huge, время загрузки практически не различается, вывод free:

Как можно заметить, столбец "used" различается не сильно, а именно примерно на 5 мегабайт. И это весь выигрыш? Весьма не большой, должен сказать...

Во время загрузки с ядром generic, система довольно интенсивно теребит винчестер (загружает модули?), думаю, разницы в скорости загрузки нет именно из-за этого.

Имею 512 МБ оперативной памяти DDR2.

_________________
Брось утку, когда берёшь ты в руки саксофон...

С -generic- доступно 449948 Кб, с -huge- -- 434572 Кб, разница чуть более 15 Мб.

В начале диска скорость чтения выше, есть смысл располагать там небольшой корневой раздел (несущий модули в /lib), смонтированный с noatime/nodiratime/relatime сообразно ситуации.

Некоторые BIOS-ы (точнее, загрузчик, используя средства BIOS) непростительно долго читают ядро с диска, опция compact в lilo.conf может сильно облегчить ситуацию.

Получение настроек сети по DHCP иногда может быть весьма небыстрой операцией.

_________________
irc://freenode.net/##slackware-ru

Я пробовал переходить на generic ядро, но на моей машине это приводит только к потере времени на загрузку. Для себя сделал вывод, что наибольшая производительность при наименьшем расходе оперативной памяти будет при использовании самосборного ядра.

_________________
Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.

Что-то не понимаю. Если huge-ядро, цитирую: "практически без дополнительных модулей", то почему у меня кажет по lsmod 64 модуля? Это если я установлю generic-ядро, то у меня этих модулей появится 264 чтоли, образно говоря? И они все будут висеть, или загружаться и выгружаться только по необходимости?

И где опцию compact прописать и в каком виде?

_________________
Slackware-14.1, 32-bit

Речь про "как можно большего количества оборудования, файловых систем и т.п.". Ни один из них не будет нужен дополнительно. Все они поучаствуют в инициализации ядром оборудования. С generic-ядром будет загружено только то, что нужно, Всё остальное между этими ядрами на равных.
Можно посмотреть diff-ы файлов конфигурации, чтобы увидеть различие на уровне параметров конфига ядра.
Была отдельно утилитка, показывающая в более удобном виде разницу для конфигов ядра, название запамятовал, кажется diffconfig в исходниках ядра (/usr/src/linux/scripts/diffconfig).

_________________
irc://freenode.net/##slackware-ru

Обьясните бестолковому, если я ошибся и хочу править лило.конф, мне нужно грузиться с загрузчика установочника и делать chroot , или можно так lilo скомандовать без монтирования и чрутования после правок?

Генерик памяти кушает 32 метра после перезагрузки, против около 60 у хуге. Я вшоке! Чудеса! Щас еще compact в лило раскомментирую для пущей загрузки Я не представляю, сколько ядро будет кушать после грамотной пересборки!

С опцией compact он еще к тому же моментально грузится(dhcp только долго мурыжит)! Раньше, после лого с меню выбора, шла надпись Loading и точки, которые с полминуты нудно грузились. Сейчас же, ни точек, ни надписи лоадинг просто нет! Точнее, надпись возникает на полсекунды!

Спасибо за статью!

_________________
Slackware-14.1, 32-bit

По всякому можно. В конце концов можно просто команде lilo всю необходимую информацию передать параметрами ;-)
Тем не менее, если хочется использовать имеющийся lilo.conf, можно:
1) использовать установочный носитель в качестве загрузчика для установленной системы (подсказка есть на его первом экране, где приглашение boot: )
2) загрузиться в установочное окружение или другую систему и использовать chroot в исправляемую.

Про обе стратегии на форуме писал подробно.

И хороший вариант: скопировать файл заведомо рабочего huge-ядра под другим именем (чтобы не было удалено при удалении/обновлении пакета) и прописать его загрузку в lilo.conf сразу в 3 уровень или в 1 (single) -- даже если оно останется без модулей, шанс на ремонт загрузчика в консольке останется.

_________________
irc://freenode.net/##slackware-ru

А без initrd вроде ж можно обойтись, вконпеляв в ядро ext4 или я что-то путаю?

Не совсем так. Например, использование UUID для задания корня не сработает без initrd.

_________________
irc://freenode.net/##slackware-ru

А скажите есть ли смысл собирать собственное
минимальное ядро если тут уже generic максимально облегчено и вряд ли у меня получается сделать ещё меньше? Теряется интрига и получается нет необходимости постигать сборку ядра. И ещё. Если все таки собирать собственное ядро где я могу посмотреть что гарантированно включать в ядро чтобы нечаянно не получить нерабочее?

Я б сказал, что в 90 случаях из 100 нет, если версия та же. А там кто ж знает, что у вас за хадачи/хотелки...
Если хочется другую версию, то "make oldconfig" предоставит возможность принять решения по новым параметрам

_________________
irc://freenode.net/##slackware-ru