LINUX.ORG.RU

Ядерная гонка.

 , , ,


0

1

Изначально был установлен debian jessie x86-64. Постепенно начал обновлять ядра, а потом и все остальное из репозиториев stretch и sid. На

Linux debian 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 GNU/Linux
ядра в репозиториях кончились, но гонка есть гонка - скачал с https://www.kernel.org/ linux-4.10.1.tar.xz извлек содержимое в домашнюю директорию и выполнил команду
$ make menuconfig
ничего менять не стал - оставил все по дефолту и сохранил получившийся .config. Сбросил параметры командой
$ make-kpkg clean
и произвел сборку ядра в deb пакет командой
$ fakeroot make-kpkg --initrd --revision=1.0.custom kernel_image
получил во время сборки ошибку вида
make[2]: *** Нет правила для сборки цели «debian/certs/benh@debian.org.cert.pem», требуемой для «certs/x509_certificate_list».  Останов.
Makefile:988: ошибка выполнения рецепта для цели «certs»
make[1]: *** [certs] Ошибка 2
что я делаю не так? где допустил ошибку? что за сертификаты и с чем их едят?

★★★★★

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

Дебиан - не тот дистр, если тебе нужно постоянно иметь свежия ядра и тд. Дебиан - это стабильность. Обычно в стейбле используется ядро LTS. Реально, если всё оборудование работает, то смысла в самом новом ядре нет, если конечно там нет каких-то нужных вещей. В 99.9(9)% - это погоня за циферками. Не более. PS: если LTS ядро не устраивает, то бери ставь с бекпортов.

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

Модуль собранный для другой версии ядра один фиг не запустится

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

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

на попе с 4.9 и ждать пока в 4.10.x всё пофиксят

вот http://maurom.com/kernel/4.10.1/ уже кто то пофиксил - не моих рук дело, мне неудалось избавиться от ошибки при загрузке виртуального модуля - хотя сам virtualbox пашет, установил 4.10.1 по ссылке - офигенно ошибки нет виртуалка работает... ядерная гонка продолжается

amd_amd ★★★★★
() автор топика
17 апреля 2017 г.
Ответ на: комментарий от anonymous

Протестировать работоспособность headers можно просто: 1. Удалить через dkms модуль 2. Пересобрать его снова

Проверил ради интереса, работоспособность headers у себя. Система Linux Mint 18, из репозиториев Убунты установлено «убунтовское» ядро 4.10.0-19-generic (и хидеры к нему, конечно). Замечу, что в каталоге /lib/modules/4.10.0-19-generic/updates/ лежит единственный модуль ndiswrapper.ko, а каталога dkms нет вообще. Команда

sudo dkms remove -m ndiswrapper -v 1.60 -k 4.10.0-generic
Удалила модуль вместе с каталогом updates. Далее,
sudo dkms autoinstall -k 4.10.0-generic
Ничего не восстановила. Удалённого модуля ndiswrapper нет, как и каталога updates. Ошибок и ругани в консоли не было.

Что это значит? То, что headers — напоминаю — не самосборные хидеры, и не самосборного ядра, а установленные из репозитория — неработоспособны? Или это означает что-то иное?

telez
()

http://maurom.com/kernel/ по ссылке свежие ядра, сам третий день еду на 4.10.10 скомпилированому по шаблону от предыдущего ядра - полет нормальный, ядерная гонка продолжается...

amd_amd ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.