LINUX.ORG.RU

Своё ядро в не source based дистрах

 


0

1

Привет. Только что поставил арч, и кое-чего не понял:
Во время установки в /boot лежало моё старое ядро ручной сборки, установщик решил, что ядро актуально и ничего не добавил (кроме initramfs). Я не против собирать своё ядро со своим конфигом (ну удобно ведь - дрова добавить и т.д), но возникает вопрос: софт в репозитории скомпилирован для конкретного ядра (glibc, например), какую версию ядра собирать? Брать тот же мажорный номер (ну это логично, но как это принято в приличных местах, какие официальные рекомендации)? Или сборка ядра приветствуется только в source-based (gentoo).
Не, ну в целом я догадываюсь как делать - тупо собирать последнее ядро перед перед каждым обновлением системы. Интересно - как вы делаете?

но возникает вопрос: софт в репозитории скомпилирован для конкретного ядра (glibc, например)

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

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от pavlick

Тогда кмк проще так:

Если ядро не обязательно должно быть mainline, то просто берёшь сборочные сценарии из своего дистрибутива и накладываешь свои патчи поверх.

Если mainline, то лучше написать свой сценарий сборки пакета. Один раз напишешь — а дальше можно уже просто патчи добавлять.

Более того, я думаю, что для каждого дистрибутива найдётся уже сделанный кем-то сценарий сборки mainline ядра, поэтому даже самому с нуля писать ничего не придётся.

Deleted ()

Каким образом софт завязан на ядре? Архитектура такая, что ядро полностью самостоятельное и софт полностью самостоятельный, их связывает набор системных вызовов, жестко прописанных в posix.

sparks ()

Софт в репозитории не собран для конкретного ядра. Ты всегда можешь обновить ядро системы на несколько версий. Иногда - на несколько версий назад.

Ты наверное путаешь с драйверами (файлы *.ko) - вот они привязаны к конкртеной версии ядра Linux. Ни версией выше, ни версией ниже

ZenitharChampion ★★★★★ ()

софт в репозитории скомпилирован для конкретного ядра (glibc, например), какую версию ядра собирать?

glibc действительно зависит от версии ядра, так как для сборки нужны заголовочные файлы api ядра
https://www.archlinux.org/packages/core/x86_64/glibc/
linux-api-headers>=4.10
то есть версию ядра 4.10 нужно, как минимум

liberty1 ()
Ответ на: комментарий от liberty1

Жесткой зависимости нет

The headers from the most recent Linux kernel should be used. The headers used while compiling the GNU C library and the kernel binary used when using the library do not need to match.
https://sourceware.org/glibc/wiki/FAQ

Если в двух словах, не стоит использовать glibc собраную с header'ами нового ядра, на старом ядре. В другую сторону пофиг, если будет большой разрыв в версиях, не сможешь использовать последнии фичи ядра, но опять же их софт должен уметь использовать.

sparks ()
Ответ на: комментарий от anonymous

Ну systemf можно и переименовать и сделать лицо раком будто это не оно, но работает без него, батарея правда не понимается то ли заряжается, а толи не разряжается

anonymous ()
Ответ на: комментарий от sparks

набор системных вызовов, жестко прописанных в posix.

Вряд ли там диктуются системные вызовы. Они даже в Linux на 32- и 64-битных версиях несколько отличаются, не говоря уже о других ОС. Тем не менее, это не мешает тем ОС являться POSIX-совместимыми.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

О, ещё один аргумент против systemd.

можете составить коллекцию аргументов. Но все они будут несостоятельными.

На вопрос автора темы, как я это делаю, отвечаю: никак. Мне кажется, подходящий ответ. Мне Linux (Ubuntu) нужна, чтобы пользоваться, а кому-нибудь Linux (Arch Linux) - чтобы собирать ядро.

Partisan ★★ ()
Ответ на: комментарий от pavlick

Значит как и думал - перед каждым обновление ставить свежее ядро.

Вообще-то, наоборот. Перед каждым крупным обновлением ядра обновлять пакеты.

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

Partisan ★★ ()
Ответ на: комментарий от anonymous

О, ещё один аргумент против systemd.

Я недавно собирал всю систему из исходников с sysvinit (LFS), впечатление от системы инициализации самое положительное - всё прозрачно, понятно, легко допилить на коленках (не то что этот монстр системд).

Написал свой менеджер пакетов (отслеживание файлов пакета, удаление), поставил xserver. Но сдался при сборке обозревателя - это ад из зависимостей, хотя мне нужно всего лишь две графических софтины - gnulot и интернет обозреватель. Но большого выбора не остаётся - systemd пролез почти во все дистры, и я не понимаю почему.

pavlick ()
Ответ на: комментарий от Partisan

Мне Linux (Ubuntu) нужна, чтобы пользоваться,

Ну и пользуйся. Браузи интернет, редактируй документы в OpenOffice, слушай музыку в любимом плейере.
Чего ты суёшь своё юзерское рыло в калашный ряд, где обсуждают ядро, а?

anonymous ()
Ответ на: комментарий от Nastishka

https://www.kernel.org/doc/Documentation/kbuild/headers_install.txt

Kernel headers are backwards compatible, but not forwards compatible. This means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel.

pavlick ()

В любом бинарном линуксе есть пакет kernel-source (RPM-based) именно для того, чтобы ты его пересобрал. Это пошло со времён Red Hat 7.3, в котором, чтобы включить твой софт-модем, надо было пересобрать ядро.

В Дебиане - берёшь конфиг ядра из любого пакета с ядром Debian, скачиваешь ядро с kernel.org, подставляешь туда свой конфиг, выполняешь «make menuconfig», вносишь туда свои изменения, и выполняешь «make deb»

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от lu4nik

Сложно всё, я в арч влюбился - минималистчная система на старте (без всяких профилей), адекватный пакетный менеджер (может я уже закалился и поэтому с лёгкостью разобрался с ним, но вспоминаю apt-get/aptitude без восторга). Пока склоняюсь к - если systemd совсем уж терпеть не смогу, то выкорчую systemd/udev и воткну sysvinit/eudev, ссылки на готовые стартовые скрипты есть в LFS/BLFS, поэтому не думаю, что это будет сильно больно.

pavlick ()
Ответ на: комментарий от liberty1

Не то чтобы с потолка - но если вы накатите например 4.4 иои даже 3.16, то что-то конечно у вас сломается, но в целом система вполне себе будет доступна - будет откликаться по сети, systemd будет работать, нжинкс будет нжинксить, самба будет самбить и т.д. (если, конечно вы не успели насоздавать файловых систем с несовместимыми фичами).

Nastishka ★★★★ ()

собираю своё ядро на арче каждый раз (почти) перед обновлением системы. nvidia-utils из официальных реп, поэтому при сборке ядра скачиваю ту же версию драйверов, что и в репах. скачивается и собирается всё обычным скриптом.

пару раз было, из-за багов нвидии, приходилось искать патчи в интернетах.

если у тебя в конфиге нет каких-то жизненно важных отличий от ядра из реп, то, наверное, не стоит заморачиваться

anonymous ()
Ответ на: комментарий от Thetan

А за что его любить то? Это монстр с кучей зависимостей, а это, на минуточку, базовый элемент системы. Вот чего стоит системд со всеми зависимостями на голой системе:

[root@pc ~]# pacman -Sr /tmp/t systemd
разрешение зависимостей...
проверка конфликтов...

Пакеты (61) acl-2.2.53-1  argon2-20171227-3  attr-2.4.48-1  audit-2.8.4-2  bash-4.4.023-1  bzip2-1.0.6-8  coreutils-8.30-1
            cracklib-2.9.6-1  cryptsetup-2.0.4-1  db-5.3.28-4  dbus-1.12.10-2  device-mapper-2.02.181-1  e2fsprogs-1.44.4-1
            expat-2.2.6-1  filesystem-2018.8-1  gcc-libs-8.2.1+20180831-1  gdbm-1.18-1  glibc-2.28-5  gmp-6.1.2-1  hwids-20180518-1
            iana-etc-20180913-1  iptables-1:1.6.2-3  json-c-0.13.1-2  kbd-2.0.4-1  keyutils-1.5.11-1  kmod-25-1  krb5-1.16.1-1
            libcap-2.25-1  libcap-ng-0.7.9-1  libelf-0.174-1  libgcrypt-1.8.3-1  libgpg-error-1.32-1  libidn2-2.0.5-1  libldap-2.4.46-2
            libmnl-1.0.4-1  libnftnl-1.1.1-1  libnl-3.4.0-1  libpcap-1.9.0-1  libsasl-2.1.26-13  libseccomp-2.3.3-1  libsystemd-239.2-1
            libtirpc-1.1.4-1  libunistring-0.9.10-1  libusb-1.0.22-1  libutil-linux-2.32.1-2  linux-api-headers-4.17.11-1
            lz4-1:1.8.3-1  ncurses-6.1-4  openssl-1.1.1-1  pam-1.3.1-1  pambase-20171006-1  pcre2-10.32-1  perl-5.28.0-1  popt-1.16-9
            readline-7.0.005-1  shadow-4.6-1  tzdata-2018f-2  util-linux-2.32.1-2  xz-5.2.4-1  zlib-1:1.2.11-3  systemd-239.2-1

Будет загружено:    0,35 MiB
Будет установлено:  340,19 MiB
Это более половины пакетов свежеустановленного арча (да, многие пакеты и так были бы установлены, но очевидно, что это штука слишком много на себя берёт). Для сравнения, зависимости bash (и то, при желании можно взять какой нибудь микроскопический ash):
[root@pc ~]# pacman -Sr /tmp/t bash
разрешение зависимостей...
проверка конфликтов...

Пакеты (9) filesystem-2018.8-1  gcc-libs-8.2.1+20180831-1  glibc-2.28-5  iana-etc-20180913-1  linux-api-headers-4.17.11-1
           ncurses-6.1-4  readline-7.0.005-1  tzdata-2018f-2  bash-4.4.023-1

Будет загружено:    0,35 MiB
Будет установлено:  173,40 MiB
Это явно перебор, ну не винда же это в конце то концов.

pavlick ()

Ребята, я нашёл жемчужину - Void Linux, о котором, по-моему, далеко не все знают. Очень похож на Arch. но в отличии от него не ссучился не наступил в systemd. Такая же минималистичная система после базовой установки, тебе не мешают всякими профилями с набором софта, приличный пакетный менеджер. Система инициализации Runit - почти тот же sysvinit, но немного более продвинутый (сервисы так же на шел скриптах). Приятно удивило время загрузки/выключения - много быстрее systemd, который на каждом углу козыряет параллельным запуском сервисов (от начала загрузки ядра до login у меня занимает 6 сек против > 10 на systemd). Очень рекомендую.

ЗЫ: во время установки инсталятор никак не мог настроить мое WEP соединение с сетью, писал свой конфиг для wpa_supplicant, запускал dhcpcd. После установки - chrot'нуться в новую среду и задать пароль для рута (установщик почему-то не делает это правильно). Ну и дефолтно у рута dash вместо bash. Ну арчеводы и сами разберутся, конечно.

pavlick ()
Последнее исправление: pavlick (всего исправлений: 1)