Дополнительные опции ядра

Предлагаю включить в конфиг ядра две-три опции:

Первая - CONFIG_PRINTK_TIME, расположение:

Kernel hacking  --->
    [*] Show timing information on printks

заставляет добавлять тайминги в лог событий ядра, пример:

 # dmesg |tail
[   22.374958] lo: Disabled Privacy Extensions
[   23.114078] fbcondecor: console 0 using theme 'tty1'
[   23.139182] fbcondecor: switched decor state to 'on' on console 0
[   33.278013] eth0: no IPv6 routers present
[27882.493528] aufs test_add:213:mount[17102]: unsupported filesystem, / (aufs)
[28414.139135] aufs test_add:207:mount[17224]: / must be outside
[28593.933713] aufs test_add:213:mount[17446]: unsupported filesystem, / (aufs)
[29888.840657] aufs may_rename_srcdir:487:mv[18089]: renaming dir who has child(ren) on multiple branches, is not supported
[30529.538281] aufs test_add:207:mount[18205]: / must be outside
[39268.136409] aufs test_add:213:mount[21611]: unsupported filesystem, / (aufs)

Кстати, об этом я уже писал тут

Второе: однажды столкнулся с такой ситуацией - кривой драйвер WiFi своими событиями сразу же забивал все тот же лог ядра.
С тех пор я всегда поднимаю размер буфера лога ядра до максимума:
вместо CONFIG_LOG_BUF_SHIFT=15 (что равняется 32KB)
CONFIG_LOG_BUF_SHIFT=21 (что соответственно 2MB)

General setup  --->
    (21) Kernel log buffer size (16 => 64KB, 17 => 128KB)

2 MB - это максимум что разрешает конфиг ядра, возможно можно и больше, но надо лазить в сорц, у меня пока такой необходимости не возникало. Но думаю 2 МБ памяти для dmesg не жалко, если это может помочь локализовать проблему.

И третья опция которую я бы добавил в ядро, это CONFIG_CC_STACKPROTECTOR=y расположение:

Processor type and features  --->
    [*] Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)

Не смотря на статус (EXPERIMENTAL) - у меня с этим пунктом проблем никогда не возникало. А жить с этим ключиком немного спокойнее.
Если верить документации - этот ключ указывает GCC собирать ядро с ключем -fstack-protector
Предлагаю желающим самостоятельно почитать про этот ключ в конфигураторе ядра, а также в документации к gcc
man gcc
Из того что я понял (а по английски я понимаю не так хорошо) - получается, что защита от buffer overflow реализуется добавлением ключа в стек. И при атаке переполнением этот ключ затирается другим значением, чем вызывает kernel panic

Конечно кернел паник - ситуация неприятная.
НО вопервых - можно среди опций ядра передать параметр:
panic=<время_в_секундах_через_которое_послеkernel_panic_система_ребутнется>.
А во вторых - это лучше чем скомпрометировать систему

Кстати, это же время можно задать/изменить и в уже запущенной системе записав значение в /proc/sys/kernel/panic

Первые две опции скорей подойдут для разработчиков. В реальной системе они только добавят нагрузку, хотя и небольшую. С третьей нужно экспериментировать. Теория это хорошо, важно создать реальные условия и проверить (на это понадобится время). Только после этого я рискну играть с кернел-паником на удаленном сервере :slight_smile:

В документации говорится:

Для сборки ядра выполните:

cl-kernel

Программа выполнит следующие действия: [выберет необходимую конфигурацию ядра]{style=“color:red;”} (в зависимости от версии и архитектуры), скомпилирует ядро с модулями, сформирует initramfs, произведет установку ядра в /boot раздел. При этом предыдущему ядру и initramfs файлу будет добавлен суффикс “old”.

А можно ли добавить такую фичу, чтобы в зависимости от выводов cat /proc/cpuinfo, lspci, lspcmci и т.п. (не знаю, есть ли ещё подобные полезняшки) в конфиг ядра записывались соотв. опции? По сути ведь, make menuconfig сводится именно к этому, если не лезть в дебри NAT, которые, имхо, простой юзер может оставить на совести разработчиков. Таким образом, на выходе получится ядро, заточенное под конкретную машину, и не придётся по несколько часов сидеть, мучительно разбирая крайне скупой хелп ядра.

“полезняшки” есть. Одна из доп. “полезняшек” с которой на днях встретился - это включить PAE на 32-х битном ядре, на машине с 4G RAM.(ну не нужна мне возможность каждому потоку выделять >4G, так что и x64 мне не к чему)

но пока такого инструмента нет. там где это критично вручную делай cl-kernel -mo --no-clean и оставляй только нужное.

если хочешь собрать ядро в package и быстро его раскидать на уже установленные компы. можешь сделать

# cd /usr/src/linux
 # make menuconfig
 # cp -a /usr/src/linux/.config /var/lib/layman/calculate/profiles/kernel/config-<твой профиль>
 # emerge -avt1 sys-kernel/calculate-sources

Но это грубый и некрасивый костыль, и он не решит проблему тонкой настройки ядра под конкретный комп. Правда большой необходимости в этом я не вижу.

Александр Варшавский wrote:

В документации говорится:

Для сборки ядра выполните:

cl-kernel

Программа выполнит следующие действия: [выберет необходимую конфигурацию ядра]{style=“color:red;”} (в зависимости от версии и архитектуры), скомпилирует ядро с модулями, сформирует initramfs, произведет установку ядра в /boot раздел. При этом предыдущему ядру и initramfs файлу будет добавлен суффикс “old”.

А можно ли добавить такую фичу, чтобы в зависимости от выводов cat /proc/cpuinfo, lspci, lspcmci и т.п. (не знаю, есть ли ещё подобные полезняшки) в конфиг ядра записывались соотв. опции? По сути ведь, make menuconfig сводится именно к этому, если не лезть в дебри NAT, которые, имхо, простой юзер может оставить на совести разработчиков. Таким образом, на выходе получится ядро, заточенное под конкретную машину, и не придётся по несколько часов сидеть, мучительно разбирая крайне скупой хелп ядра.

Есть встроенные в ядро скрипты которые сканирует подгруженные модули, добавляют их в ядро а не подгруженные наоборот убирает. т.к. ядра Calculate-source делаются по принципу модульность во всем! Вещь выходит не заменимая при облегчении ядра. С Initrd - make localmodconfig, без Initrd - make localyesconfig. После скрипта обязательно нужно все просмотреть “make nconfig” например -> File systems > Native language support. Там будет пусто после скрипта и т.д.