Форум Slackware Linux

Слакбилд достаточно умен, чтобы проверить "/usr/src/linux-$VERSION/arch/i386/boot/bzImage":

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

Нет. Цель "make bzImage" только собирает ядро и жмет его. Ставит и зовет lilo цель по умолчанию, то есть "make".

Не чините то, что не ломалось Рецепт рабочий, комментарии к нему -- нет. Вместо /путь/до/kernel-generic нужно подставить то, куда был загружен
wget -r -nH --cut-dirs=4 ftp://ftp.osuosl.org/pub/slackware/slac ... /source/k/

Внутри packaging-* будут необходимые SlackBuild и slack-desc сообразно желаемым пакетам:


make bzImage к вашим услугам.

В doinst.sh пакет переставляет симлмнки /boot/vmlinuz, /boot/System.map, /boot/config на установленные из этого пакета файлы. В /etc/lilo.conf в качестве image по умолчанию прописан /boot/vmlinuz. Для -huge-* ядра уже можно звать lilo. А для -generic-* -- ещё рано, надо сперва initrd пересоздать. Ну и смысл lilo без толку дергать лишний раз? Дежа вю ;-) viewtopic.php?f=28&t=782&start=10#p6020

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

А вот этого вредного совета никогда не слушайте, если только не пересобираете glibc.

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

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

_________________
slackware-current(32/64)

вы модератор, хоть в посте примечание поставьте.
спасибо.

_________________
slackware-current(32/64)

Ух ты, дал я маху :) Ваши советы всегда и в первую очередь учитываются, спасибо большое.

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

Уважаемый Bormant, если вас не затруднит, не могли бы вы написать пошаговую инструкцию по сборке ядра для slackware аналогичную этой: https://eax.me/linux-kernel-build/
В интернете много статей с компиляцией ядра из исходников без применения слакбилдов из http://bear.alienbase.nl/mirrors/slackw ... /source/k/


Насколько актуальна последовательность этих действий для slackware-current?

cd /usr/src/
tar xf /путь/до/linux-x.y.z.tar.xz
cd linux-x.y.z

cat config-huge > .config
make olddefconfig
make bzImage
(cd /путь/до/kernel-huge; VERSION=x.y.z ./kernel-huge.SlackBuild)
make clean

cat config-generic > .config
make olddefconfig
make bzImage modules modules_install
(cd /путь/до/kernel-generic; VERSION=x.y.z ./kernel-generic.SlackBuild)
(cd /путь/до/kernel-modules; VERSION=x.y.z ./kernel-modules.SlackBuild)
make clean

make prepare
rm .version
makepkg /tmp/kernel-source-x.y.z-noarch.txz

Или сейчас порядок пакетирования ядра изменился?

Думаю такое howto будет полезно не только мне.

В общем, тут в ходе эксперментов и еще в момент выхода 14.2 установил(и),
что моя железка / мой ноутбук, при kernel-4 на 32, не умеет уходить в спячку, вместо этого идет kernel-panic.
Попробовал 32:

Slackware-14.1 с ядром 3.10.107, 14.2 - 4.4.157, current 4.14.72
LinuxMint-19 vmlinuz-4.15.0-20-generic

С последними версиями ядер же, все стало хоть и без panic, но на pm-hibernate - ноутбук вроде и пытается уснуть на диск, но когда все заканчивается - он перезагружается. Попробовал 64 current и mint там все нормально.
Думал уже на 14.1 вернуться, но не готов жертвовать безопасностью, примочками от 14.2 в том числе pulse, версиями ПО... Пытаюсь собрать 3.x.y на 14.2.

Пока что пара вопросов, пытаюсь для теста экспермента на 14.2_64 собрать, потом на 32 буду. В 14.2 - gcc5, в ходе поиска узнал что данную поддержку в 3.1x.y завезли на какой-то версии. И не долго думая решил собрать то ядро, которое у меня в 14.1 работало. Будем пытаться собрать linux-3.10.108 (05-Nov-2017) - что бы взять готовый .config из 14.1 для 3.10.x и что бы в ходе make oldconfig ряда доп вопросов не было.

1.1 В 14.1 Патрик обновлял ядро до 3.10.107, SlackBuild и конфиг не нашел http://slackware.osuosl.org/slackware-14.1/FILELIST.TXT
для 107 если конфиг не положил значит старый использовал, как и билды для сборки в пакет?
(можно конечно и сам пакет скачать и оттуда извлечь, но просто интересно как принятно)

1.2 вот есть репозитории slackware64-14.1 и slackware-14.1

http://slackware.osuosl.org/slackware-14.1/source/k/
http://slackware.osuosl.org/slackware64-14.1/source/k/

и в них config-x86_64/ и config-x86/ по сути без разницы откуда config брать?
(я в плане то что в slackware-14.1/source/k/ - config-x86_64/ и наоборот)

1.3 И пока что ход действий прогоняю на 64, 32 пока что нет под рукой
сделал make oldconfig при .config из http://slackware.osuosl.org/slackware-1 ... .10.17.x64 , получил:Все ли нормально? Смущает только слово arch/x86/, почему на системе64 - написано arch/x86/
т.е. это вызвано поддержка 32, я правильно понял?

1.4 Когда все соберется, соберется в пакеты и мы их установим, зачем делать - ведь ничего подобного не делаем же при обновлении (slackpkg upgrade-all),
когда устанавливается новое ядро, новая версия из slackware-14.1/patches/?

_________________
• Dell Inspiron 3721-0179 @ i3-3217U 1,8Ghz • DDR3 1600 MHz 8Gb • Intel 4000 HD • WiFi AR9485
• Slackware-stable @ WM: Openbox • Web: Firefox • Jabber: Gajim

1.4. Это обновление initrd. Тот, кто использует -generic- ядро делает это всегда при обновлении ядра, иначе у него не будет модуля для корневой ФС и будет kernel-panic при загрузке с новым ядром.
Просто иногда делает иным способом, например, прямым вызовом mkinitrd -k версия -F.

1.3.
x86-64 -- конфиг для 64-разрядной версия ядра, поддержка 32 битов включена, это позволяет просто доставить мультилиб для работы 32-разрядных бинарников не пересобирая ядро.
x86 -- конфиг для 32-разрядной версии ядра.
В ядре для обоих платформа x86, поэтому в arch/x86 все нормально.

1.2. /source/ -- общий для 64 и 32 бит, не хватало еще два комплекта исходников поддерживать... А поскольку конфиги ядер для 32 и 64 отличаются, они внутри /source/k/ лежат в разных каталогах с соответствующим своим именем.

1.1.
http://slackware.osuosl.org/slackware-1 ... -3.10.107/
http://slackware.osuosl.org/slackware64 ... -3.10.107/
Загрузить пакеты с нужным ядром (именно с ядром: kernel-huge* kernel-generic*, они мелкие), взять конфиг из пакета. На худой конец просто сравнить, чтобы понять, одинаковы или нет (скорее нет, чем да, но на отсечение ничего не дам ).

Что держит на 32? Ведь поддержка со временем будет только хуже или не будет вообще...


PS. Может есть смысл побагрепортить на незасыпание? Поискать похожие ситуации у других? Может какой-то модуль виноват и при его выгрузке все нормализуется?

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

да просто тут различными эксперементами 14.2_64 мне кажется убил, amarok например уже не запускается и много чего лишнего установлено, что может даже между собой конфликтует, я решил самым простым методом просто переустановить систему (и снять архив, сделать резервную копию), и вот про 32 вспомнил, что у меня там что-то не так было, решил посмотреть мало ли исправили. Ну и просто, да конечно, я уже встречал софт который на 32 просто уже сегфолится (н-р: psi+-qt4_git2016, они потом на qt5 вроде ушли, но с 32 ситуация не изменилась) или софт который под 32 не собирается (docker, н-р, да и даже среди бинарников: opera, для 32 последняя stable-версия: 45.0.2552.898). 32 для desktop меня устраивает, не надо либ32 ставить, да и я не вспомню то время когда на 32 надо было либ16 ставить. По всякой безопасноти 32 еще не заброшено и местами обновляется, а ПО, ну я наверно лучше стабильно буду крутить, чем последнее-распоследнее.

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

Что примечательно, данный ноутбук Dell inspiron-17-3721 шел с ubuntu-12.04 там 3.x.какое-то и прям как-то даже печаль, что вроде и DELL+Linux, а тут такое вот вылезло.

За ответы спасибо, все учту, если время будет постарюсь не забросить задуманное. Еще вот вопрос:

2.1 Есть config-huge и generic, а в чем отличие, точнее что эти обозначения означают?
(если не трудо, напомните, пожалуйста, можно даже ссылкой, наверняка не раз приходилось отвечать)

2.2 Я просто спрашиваю с намеком, можно без

kernel-source
kernel-headers
kernel-modules-smp
kernel-generic-smp
kernel-huge-smp

обойтись и все это в один пакет запихнуть, или нежелательно и важен порядок установки?

2.3 В 14.2 есть пакет kernel-firmware-20180913_44d4fca,
по сути все что в нем никак не окажет влияния, на то что я делаю downgrade ядра или все таки kernel-firmware желательно посвежее ядро?

2.4 Сборка вот есть каталог /usr/src/ обязательно в нем собирать ядро или можно в другом каталоге?
я уже получил, при make bzImage modules modules_install
Т.е. тут не все так просто, как в случае с простым ПО для сборки его в пакет через Slackbuild или все так же просто, просто не делать modules_install? Или modules_install здесь обязателен?


~upd
т.е. у меня вот в lilo прописано: image = /boot/vmlinuz
а оно: vmlinuz -> vmlinuz-huge-4.4.157. Пакет kernel-generic-4.4.157 я могу удалить без последствий?

_________________
• Dell Inspiron 3721-0179 @ i3-3217U 1,8Ghz • DDR3 1600 MHz 8Gb • Intel 4000 HD • WiFi AR9485
• Slackware-stable @ WM: Openbox • Web: Firefox • Jabber: Gajim

2.1. viewtopic.php?f=8&t=668&hilit=generic#p4136
huge -- огромное -- ядро, которое предназначено для установки системы и поэтому должно знать как можно больше контроллеров, к которым могут быть подключены носители будущей целевой системы, поэтому вкомпилировано (=y) как можно больше драйверов такого оборудования.

generic -- обычное -- ядро, которое предназначено для эксплуатации системы. Здесь вкомпилировано в само ядро (=y) как можно меньше, всё, что возможно, собрано модулями (=m), такой аналог "make allmodconfig". С этим конфигом собираются ядро (kernel-generic) и модули (kernel-modules). В это ядро не вкомпилировано ни одного драйвера ФС, поэтому без initrd с драйверами оно смонтировать корень не сможет, будет паниковать.

2.2.
kernel-headers -- это заголовочные файлы ядра, с которыми была собрана glibc. Их замнять не надо, если не пересобираете glibc.
kernel-source -- это подготовленные исходники ядра для /usr/src/linux-версия/.
Про остальное вроде выше упомянуто.
Если собираете по конфигу -generic- проще сразу вкомпилить в ядро драйвер корневой ФС -- ядро останется легким, но перестанет требовать initrd. Правда initrd обеспечивает не только драйверы для корня, но и некоторые другие плюшки, например, возможность указать корень ядру по UUID.
generic и huge "дерутся" за один симлинк /boot/vmlinuz (а он по умолчанию в /etc/lilo.conf прописан), кто последний поставился, тот и папа ;-)
Соответственно, собирая для себя, достаточно kernel-generic, kernel-modules, kernel-source (чтобы иметь возможность собирать драйверы для своего нового ядра).

Кроме того, если вам нужно просто ядро на одну систему, то можно и не опакечивать (по крайней мере модули).
Ядрёные слакбилды чутка по другому устроены -- они упаковывают уже имеющиеся в системе ядро (про bzImage в arch/x86/ после "make bzImage" он в курсе) и модули (в /lib/modules/версия после "make modules; make modules_install").

2.3. Это прошивки, заливаемые драйверами в устройства. Они от производителей устройств. Желательно свежие.

2.4. Желательно в /usr/src/linux-версия от root-а. Тогда досборка драйверов будет проходить гладко. В /lib/modules/версия/ в том числе хранится симлинк на исходники ядра, из которых производилась сборка.
Про особенности ядрёных слакбилдов уже говорил выше, здесь не сделать:
make DESTDIR=/tmp/pkg install

make modules_install -- обязателен, он поставит модули в /lib/modules/версия, а kernel-modules.SlackBuild именно их и будет упаковывать в пакет. Если посмотреть внутрь, то он делает именно и только это.

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

Почти. Если не собираетесь использовать -generic- вот совсем-совсем, то да. А последствия -- не все всегда работает с -huge-, можете встретить ситуацию, когда хочется выгрузить или перезагрузить модуль с другими параметрами -- ан нет, он в теле (=y) и никак; какой-то модуль может не загрузиться с ошибкой (конфликт с чем-то, что =y). На что-то такое сам наступал, но точно модули не вспомню.
Поэтому стоит подумать насчет -generic-, возможно для удобства в котором перед сборкой включен (=y) драйвер корня, например, ext4.

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

Про kernel-headers вы меня что-то аж напугали (Как связаны пакеты kernel-headers и glibc?)
Т.е. смотрите, допустим в системе стоит kernel-4 + kernel-headers-4.4.157, я собираю kernel-3 и устанавливаю пакеты его без kernel-headers-3, оставляю kernel-headers-4 (что бы glibc не пересобирать и много чего зависящего от него).
3.1 При kernel-3 и kernel-headers-4 я смогу устанавливать-собирать различный софт из _SBo без ошибок?
3.2 Да и, если понадобится модули какие-то собрать, скажем virtualbox-kernel_версияVBOX_версияKERNEL?
3.3 Сам вопрос в том, если я поставлю kernel-3 и kernel-headers-3, мне обязательно для сборки какого-нибудь пакета или модуля нужно ПРЕЖДЕ пересобрать glibc?

Если так исходить и я посмотрел, Патрик ядро обновляет, как и kernel-headers, но glibc, которое как оказалось связано с kernel-headers при этом обновлении не трогает. Это все к тому что
> Пока не обновлён пакет glibc вы не должны обновлять или удалять соответствующий ему пакет kernel-headers
- или эта информация устарела?
3.4 точнее правильно поставим вопрос: я устанавлю kernel-3 и kernel-headers-3, но glibc я не намерен трогать и пересобирать, но мне нужен другой софт который связан с glibc - этот софт без вообще kernel-headers может быть собран?

_________________
• Dell Inspiron 3721-0179 @ i3-3217U 1,8Ghz • DDR3 1600 MHz 8Gb • Intel 4000 HD • WiFi AR9485
• Slackware-stable @ WM: Openbox • Web: Firefox • Jabber: Gajim

Для сборки ядерных драйверов используется дерево исходников ядра, файлы из kernel-headers в этом не участвуют. Но они могут участвовать при сборке прочего софта. Поэтому пакет kernel-headers оставьте на месте.
Ядра 2.6.х, 3.х, 4.х по сути одна и та же ветка, не так как это было с 2.4 и 2.6.
glibc пересобирать не надо.

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

я тут кое-что интересное увидал! build-all-kernels.sh (2018-03-15) http://slackware.osuosl.org/slackware-c ... kernels.sh
не знаю когда именно данное чудо там успело появиться, я даже счастлив) но пока глубоко не изучал,
что вот теперь думаю, по-старинке собрать, как Вы мне когда-то советовали https://www.linux.org.ru/news/slackware ... t-12720707
или же при помощи этого скрипта

_________________
• Dell Inspiron 3721-0179 @ i3-3217U 1,8Ghz • DDR3 1600 MHz 8Gb • Intel 4000 HD • WiFi AR9485
• Slackware-stable @ WM: Openbox • Web: Firefox • Jabber: Gajim

В 15.0 есть интересные изменения :)
Но этот сценарий — хорошая помощь в подготовке набора пакетов для 64 и 32 систем, прежде всего из-за 32-битной с ее дополнительным не-smp комплектом и nosmp-sdk.
Есть ли смысл в его использовании для сборки своего рабочего ядра? Ответ уже не такой однозначный.

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

В предыдущем сообщение, извиняюсь, я по ходу зачитался, что kernel-source с kernel-headers начал путать/объединять...
Итак, сдвиги есть какие-то и причем положительные, позже просмотрю еще тему и отпишусь как все прошло.
Скрипт по ядрам из http://slackware.osuosl.org/slackware-current/source/k/ очень понравился. Собрал как до него собирал(ось), да и как здесь расписано, так и с ним, штука мощная даже патчи, если закинуть в соответствующий каталог ($CWD/patches-${VERSION} см.kernel-source.SlackBuild) на исходниках ядра может применить.

Но вот покоя только не дает kernel-headers
приписка: порой, но действительно если посмотрим ChangeLog.txt_slack14.1, будем сверху-вниз идтии даже в ChangeLog.txt_current: http://slackware.osuosl.org/slackware-c ... ngeLog.txtмне понравилось как вы здесь ответили:и по ходу данное можно отнести и к kernel-headers, если глянем FILELIST.TXT_slack14.2
- kernel-headers.SlackBuild тоже нет и видимо не спроста.

В общем, все к чему, по сути получается kernel-headers такой пакет, который только Патрик поднимает (как и все остальное =)),
а уж как он его поддерживает это его дело и лучше не трогать, если не хочется с glibc возиться, так?

_________________
• Dell Inspiron 3721-0179 @ i3-3217U 1,8Ghz • DDR3 1600 MHz 8Gb • Intel 4000 HD • WiFi AR9485
• Slackware-stable @ WM: Openbox • Web: Firefox • Jabber: Gajim

Можно подумать, выше по этой теме или у Эрика было написано что-то другое ;-)

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

тут про пакет kernel-source-x.y.z-noarch.txz спрашивали, но наверно не все заметили
1) viewtopic.php?p=7174#p7174 + 2) viewtopic.php?p=5973#p5973 , подытожу:

после действий с .config, получением bzImage, сборки kernel-huge, kernel-generic, kernel-modules выполняем:

_________________
• Dell Inspiron 3721-0179 @ i3-3217U 1,8Ghz • DDR3 1600 MHz 8Gb • Intel 4000 HD • WiFi AR9485
• Slackware-stable @ WM: Openbox • Web: Firefox • Jabber: Gajim

Ну копирование тут если только от безысходности ;)
Дешевле в пределах одной ФС подготовить дерево пакета (да хоть в /usr/src/tmp), каталог с исходниками туда переместить (mv), потом вернуть на место, либо сделать хардлинк (ln), потом удалить...
Просто копирование полугигабайта файлов только лишь для того, чтобы упаковать их в пакет (архив) — так себе удовольствие... Но настаивать не буду, копирование — прямой и безопасный путь.

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