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

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

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

Лучше всего — пакетить самому.

Для какой цели используется самосборное ядро?

Да постоянно рихтую ядро, дрова/настройки всякие, удобно.

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

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

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

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

бинарные дистрибутивы обычно публикуют свои патчи для ядра. хотя некоторые используют ванильное. у рача есть своя википедия и там есть подробная статья про кернел: https://wiki.archlinux.org/index.php/Kernel

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

Ясно, значит своё ядро в бинарных дистрах - нормально. Буду собирать ванильное под себя, не сильно хочется заморачиваться с патчами.

Спасибо всем.

Я одно знаю: в /usr/include/ целый вагон (около 900) заголовочных файлов от ядра (*.h). Может там действительно всё «жестко прописанных в posix», но не в курсе.

Да, для сборки модулей ядра.

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

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

(файлы *.ko) - вот они привязаны к конкртеной версии ядра Linux

Нуууу, не всегда.

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

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

а вот там есть список пакетов, которые требуют для сборки linux-api-headers https://www.archlinux.org/packages/core/any/linux-api-headers/
systemd, например, прибит к ядру

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

Эх. Свободное время и желание изучить все уголки системы... Лови момент.

systemd, например, прибит к ядру

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

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

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'ами нового ядра, на старом ядре. В другую сторону пофиг, если будет большой разрыв в версиях, не сможешь использовать последнии фичи ядра, но опять же их софт должен уметь использовать.

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

Нуууу, не всегда.

Хм... Ну если в руках есть hex-редактор, то не всегда, да.

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

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

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

Кто-то же использует, стало быть работает...

https://aur.archlinux.org/packages/linux-lts49/

https://aur.archlinux.org/packages/linux-lts44/

и никаких глюков не заметно? ну это временно

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

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

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

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

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

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

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

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

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

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

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

Нет. Например, https://trapsink.com/wiki/Kernel_Module_Weak_Updates

Devuan, не? sysvinit на месте, пакетный менеджер тоже.

Брехня

то есть ты хочешь сказать, что в арче ограничение >=4.10 с потолка взялось?

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.

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

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

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

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

файлы *.ko - вот они привязаны к конкртеной версии ядра Linux

далеко не всегда. CONFIG_MODVERSIONS и всё такое. ну это я уже занудствую.

о как всё запущено! :-) вам RTFM очень сильно.;-)

С openrc арчеводы развлекаются...

Что ж вы так systemd не любите. Аллергия?

Традиция у них такая, не любить systemd.

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

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

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

какую версию ядра собирать?

любую, наверное. у меня никогда она не совпадает с версией, которая в репах.

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

[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

[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

Попробуйте Slackware, systemd выкорчевывать не придется.

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

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

Система инициализации Runit - почти тот же sysvinit

Ты сейчас плюнул в душу всем последователям djb

у арча есть приличный artix - с openrc вместо systemd.

void-src хорош до момента, пока приложение в зависимостях не потребует пересборку всей системы для какого-нибудь более свежего icu.

для обычного домашнего десктопа хороший выбор, но с плохой документацией

исходники ядра и сборка есть имхо во всех майнлайновых бинарных дистрибутивах. или я не прав ??

Да есть в арче все, но автор в процессе речи дальше пишет уже не о том, что добывается простой командой pacman -S linux linux-headers linux-docs