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

Ты не мэйтейнер, те это не нужно.

Выключи подпись модулей ядра и в настройках криптографии выключи самые нижние пункты, про подпись ядра. Оно ругается, что не может найти подпись твою, криптографическую

там так по дефолту

(debian/certs/benh@debian.org.cert.pem) Additional X.509 keys for default system keyring
[ ]   Reserve area for inserting a certificate without recompiling
[ ]   Provide a keyring to which extra trustable keys may be added

Тыц

Тыц

это я курил вчера - не помогло, ладно сейчас сделаю .config покажу как там это выглядит

вот как это выглядит в .config

# Certificates for signature checking
#
CONFIG_MODULE_SIG_KEY=""
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/benh@debian.org.cert.pem"
# CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set

CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/benh@debian.org.cert.pem"

В menuconfig выключи. Но чтоб выключить надо сначала выключить подпись модулей. И собирать не make-kpkg надо, а make deb-pkg ( первое лично у мя не работает нормально )

поздно make deb-pkg - я уже .config расковырял, вся проблема в двух строчках

CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/benh@debian.org.cert.pem"

# CONFIG_SYSTEM_TRUSTED_KEYRING=n
# CONFIG_SYSTEM_TRUSTED_KEYS is not set

Ты прост дурень - чего не выключил все ненужное из ядра? Даже мой соплерон мобильный о 1600МГц два ядра, и тот собирает полчаса всё... :D

Ты прост дурень - чего не выключил все ненужное из ядра

я и не собирался этого делать - хотел собрать по дефолту, просто отработать процесс - убедится что все работает, а потом уже ковырять menuconfig беспроблемно, каюсь сглупил - первый блин комом, ну и чего теперь - жопа? часов 8 или больше?

это капец - оно растет, уже более 8-и гигов - скоро лопнет, лягу спать - утро вечера мудренее - пусть собирает

все гора родила мышь - собралось, не смотря на то что исходная папка разрослась до 13-и гигов, конечный deb пакет весит всего 37 мб. [решено]

fakeroot make-kpkg --initrd --revision=1.0.custom kernel_image

linux-image то у тебя собралось, а linux-headers не собрались.

Чтобы собрать и с headers в 4.10 нужно сделать симлинк(хардлинк) «REPORTING-BUGS» в каталоге с исходниками ядра на "./Documentation/admin-guide/reporting-bugs.rst" ибо в 4.10 поменяли пути и дебиановский велосипед не может найти REPORTING-BUGS и вылетает с ошибкой при сборке headers.

P.S. Ещё в 4.10 поломали bbswitch, так что ядро пока сильно сыроватое.

исходная папка разрослась до 13-и гигов

Если собирал с headers и планируешь собирать модули ядра через dkms, то оставь только нужное:

./arch ./include ./scripts ./.config ./Module.symvers

ну и ./Makefile тоже конечно нужен )))

linux-image то у тебя собралось, а linux-headers не собрались

вот и я смотрю - выхлоп по uname -a какой то кастрированый

Linux debian 4.10.1 #1 SMP Sat Mar 4 01:09:52 MSK 2017 x86_64 GNU/Linux

Выхлоп нормальный, но модули для ядра (Virtualbox, проприетарный nvidia-driver и т.д.) через dkms не соберутся. Если планируется сидеть на новом ядре основательно, то можно пересобрать так:

cd linux-4.10.1
cp /boot/config-4.10.1* .config
ln ./Documentation/admin-guide/reporting-bugs.rst REPORTING-BUGS // иначе make-kpkg не соберёт headers
make-kpkg configure //иногда бывает полезно заранее проверить не вылезет ли ошибка компилятора
export CONCURRENCY_LEVEL=2 //сборка используя 2 ядра
time make-kpkg --rootcmd fakeroot --revision 1.0 --initrd kernel_image kernel_headers

Соберётся 2 пакета, заодно время сборки узнаешь. Но при установке модуль для Virtualbox всё равно не соберётся, т.к. AFAIK с поддержкой 4.10 походу ещё не завезли.

заодно время сборки узнаешь

собрало 2 пакета за 12 минут - вчера 3 часа 1 собирало, в чем секрет?

cp /boot/config-4.10.1* .config

Ну make-kpkg clean же не делал после предыдущей сборки? Теперь осталось проверить, а пакеты то все рабочие собрались? )))

Соберётся 2 пакета

kernel_headers установился, а kernel_image - сообщает что он старее установленой версии и предлагает прервать установку...

make-kpkg clean и по новой, 3 часа )))

config в boot - от прошлой сборки этого ядра, что и был до этого. Я предполагал, что дерево исходников с предыдущей сборки уже кануло в лету...

сообщает что он старее установленой версии и предлагает прервать установку

Ну ревижионы в параметрах сборки то отличаются - то, что собирал до этого 1.0.custom (кстати «косячная» версия, лучше добавить "--append-to-version -custom"), и «моя» 1.0... Можно подправить или заново все под чистую собрать.

Можно подправить или заново все под чистую собрать.

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

При переносе этих самосборных пакетов на другую машину (если это другая система, т.е. на другом диске!!!) есть маленький нюансик. Во-первых нужна та же версия gcc, во-вторых, при установке пакетов в /lib/modules/4.10.1* создаются симлинки build и source на каталог в хомяке в котором всё и собиралось. Так что придётся тащить туда ещё и этот каталог на 13Гб.

Хорошая новость: всё тащить не надо, для модулей понадобятся только оставшиеся после сборки каталоги arch, include и scripts, а также файлы .config, Makefile и Module.symvers

Если полное дерево исходников ещё для чего-нибудь нужно, то можно их (вышеперечисленное) временно куда-нибудь скопировать, сделать make-kpkg clean и обратно перенести.

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

если это другая система

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

Эта такая фигня с headers, что при сборке из хомяка симлинк в /lib/modules/*версия_самосборного_ядра* указывает на хомячий каталог, хотя в /usr/src/linux-headers-*версия_самосборного_ядра* всё это уже лежит.

Так что пакеты можно коллекционировать (но смысл?), только вот после установки, например, ядра 4.10.1-custom нужно будет создать (поменять) симлинки в /lib/modules/4.10.1-custom для build и source, чтобы они указывали на /usr/src/linux-headers-4.10.1-custom, а не на хомяк...

После чего пересобрать модули:

sudo dkms autoinstall -k 4.10.1-custom

Есть такой косяк.

Можно подправить или заново все под чистую собрать

собрал заново - все равно старье пишет и [ok] почему то неактивно, может нельзя одно и то же ядро по вех себя ставить - как бы они не назывались, сейчас откачусь на 4.9.0-2 и накачу по новой

Да, не дает ставить одно ядро два раза, перезагрузиться в 4.9, снести установленные linux-headers-4.10.1 и linux-image-4.10.1 и поставить заново.

Вообще весь процесс должен представлять из себя нечто подобное:

wget -O - https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.10.1.tar.xz | tar xJf -
cd linux-4.10.1
cp /boot/config-4.9.0-1-amd64 .config
make oldconfig

Новые опции ядра, жмем enter - по умолчанию, меняем только CONFIG_BLK_WBT=y и CONFIG_BLK_WBT_SQ=y

make menuconfig

отрубаем «Enable loadable module support/Module signature verification=not set», после чего «Cryptographic API/Certificates for signature checking/Provide system-wide ring of trusted keys=not set».

Проделать это придётся только один раз, в следующий раз при обновлении сразу берем из /boot/ config нашего ядра 4.10.1 без подписей и делаем ему make oldconfig

ln -s ./Documentation/admin-guide/reporting-bugs.rst REPORTING-BUGS

Выше - костыль для сборки headers, пока в debian не обновят свой сборочный велосипед под ядра 4.10+

make-kpkg configure && make-kpkg clean

make-kpkg configure - для проверки: если версия ядра и gcc не совместимы - сразу вылетит ошибка (пару месяцев назад была такая петрушка с некоторыми ядрами и gcc6)

export CONCURRENCY_LEVEL=2
time make-kpkg --rootcmd fakeroot --append-to-version -custom --revision 1.0 --initrd kernel_image kernel_headers 
cd
sudo dpkg -i linux-headers-4.10.1-custom_1.0_amd64.deb linux-image-4.10.1-custom_1.0_amd64.deb

Меняем симлинки для headers:

sudo ln -sfT /usr/src/linux-headers-4.10.1-custom/ /lib/modules/4.10.1-custom/build
sudo ln -sfT /usr/src/linux-headers-4.10.1-custom/ /lib/modules/4.10.1-custom/source

Удаляем linux-4.10.1 с мусором на 13Гб из home, больше он нам не нужен.

Перенос пакетов на другую машину:

При установке на другой машине, для корректной сборки модулей нужна та же мажорная версия gcc, на которой собиралось ядро, если собирали на gcc6, а там стоит gcc5 модули не соберутся, даже при более мелких изменениях версии может отказаться собирать.

Устанавливаем пакеты:

sudo dpkg -i linux-headers-4.10.1-custom_1.0_amd64.deb linux-image-4.10.1-custom_1.0_amd64.deb

Если при установке куча ошибок при сборке модулей на отсутствие headers, то меняем симлинки для headers:

sudo ln -sfT /usr/src/linux-headers-4.10.1-custom /lib/modules/4.10.1-custom/build
sudo ln -sfT /usr/src/linux-headers-4.10.1-custom /lib/modules/4.10.1-custom/source

После чего пересобираем модули:

sudo dkms autoinstall -k 4.10.1-custom

так что ядро пока сильно сыроватое

в boot файлы вида vmlinuz* определяются системой как исполняемые файлы и только vmlinuz-4.10.1 является файлом неизвестного типа, кроме того пришлось лечить ошибку вида

Error: Driver 'pcspkr' is already registered, aborting...

в boot файлы вида vmlinuz* определяются системой как исполняемые файлы и только vmlinuz-4.10.1 является файлом неизвестного типа

Это норма, ещё system.map-4.10.1 не plaintext и т.д. У всех такое - для дома, для семьи пойдёт, совершенно ничего критичного...

Они там у себя как-то по особому собирают.

виртуальная машина не работает - требует установить apt-get install linux-headers-4.10.1, при попытке установить - сообщает что уже установлен пакет linux-headers-4.10.1 самой новой версии (1.0).

виртуальная машина не работает

Какая? Virtualbox - да, не работает, модуль просто не собирается под 4.10.1. Надо ждать обновы.

Либо проверить пути с симлинками для headers. У меня выше в примере указаны для linux-headers-4.10.1-custom, а собирались как я понял для linux-headers.4.10.1

Т.е. нужно подправить:

sudo ln -sfT /usr/src/linux-headers-4.10.1 /lib/modules/4.10.1/build
sudo ln -sfT /usr/src/linux-headers-4.10.1 /lib/modules/4.10.1/source

собирались как я понял для linux-headers.4.10.1

так и есть - custom же не по феную...

Если при установке куча ошибок при сборке модулей на отсутствие headers, то меняем симлинки для headers

ошибок нет и все равно не работает, выполнил

sudo ln -sfT /usr/src/linux-headers-4.10.1 /lib/modules/4.10.1/build
sudo ln -sfT /usr/src/linux-headers-4.10.1 /lib/modules/4.10.1/source
sudo dkms autoinstall -k 4.10.1

Kernel driver not installed (rc=-1908)
The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing
'/sbin/vboxconfig'
as root.
where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT.

Они там у себя как-то по особому собираю

установка inux-headers.4.10.1 заканчивается строчкой

run-parts: executing /etc/kernel/header_postinst.d/dkms 4.10.1 /boot/vmlinuz-4.10.1

Выше же писалось, что Virtualbox не работает в 4.10.1, при сборке модуля dkms вылетает с ошибкой

Ну ещё можно проверить какие модули были собраны dkms для стокового ядра:

ls /lib/modules/4.9.0-2-amd64/updates/dkms/

ls /lib/modules/4.10.1/updates/dkms/

и какие из них успешно загрузились, грепнув lsmod

У меня не собралось для 4.10.1 ни одного модуля для Virtualbox, но есть к примеру модуль bbswitch, но он не загружается (такая проблема у всех как я понял на 4.10.1, даже у арчеводов).

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

Выбираем понравившийся модуль из ls /lib/modules/4.10.1/updates/dkms/

Например, для bbswitch:

1. Узнаем его версию:

sudo modinfo bbswitch | grep version:

version:        0.8
srcversion:     90CDB6EFB3C4142AB1E1E16

2. Удаляем модуль bbswitch версии 0.8 из ядра 4.10.1:

sudo dkms remove -m bbswitch -v 0.8 -k 4.10.1

3. Пересобираем автоматом недостающие модули (bbswitch в нашем случае будет пересобран, т.к. мы его только что удалили)

sudo dkms autoinstall -k 4.10.1

Если всё ок с headers, будет выхлоп в консоли про успешную сборку модуля и никаких ошибок по поводу bbswitch не будет (или другого модуля на выбор, т.к. bbswitch это у меня такой модуль для примера)

Будут ошибки про Virtualbox только.

Будут ошибки про Virtualbox только

при запуске созданой виртуальной машины - ошибка, удалось победить ошибку - самой ошибкой, в ошибке указано - '/sbin/vboxconfig' прешел дернул в терминале, просит пароль, ввел, опять просит, опять ввел - опять просит, запросы какие то однотипные - стало уже казаться что по кругу гоняет, но природная упертость заставила продолжить ввод паролей, примерно после 25-30 запросов\вводов паролей - терминал автоматом закрылся, дернул виртуальную машину и она запустиласть, отлично virtualbox пашет на ядре 4.10.1

sudo modinfo bbswitch | grep version

нет такой буквы

отлично virtualbox пашет на ядре 4.10.1

Сегодня как раз только что virtualbox в unstable обновился, а я на тестинге сижу... Так что всякое может быть )))

Если bbswitch нет в выхлопе: ls /lib/modules/4.10.1/updates/dkms/ то логично, а его скорее всего там и нет! Берешь любой модуль который лежит по этому пути и проверяешь.

а я на тестинге сижу

и я на тестинге - а virtualbox взял с офсайта deb пакет для stretch

А я протухший - из реп debian...

Если в /lib/modules/4.10.1/updates/dkms/ хоть что-то есть, то значит модули уже собрались при установке ядра, соответственно с headers и так всё нормально.

 ls /lib/modules/4.9.0-2-amd64/updates/dkms/
nvidia-current-drm.ko  nvidia-current-modeset.ko
nvidia-current.ko      nvidia-current-uvm.ko

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

А в /lib/modules/4.10.1/updates/dkms/ чё, совсем пусто?

sudo modinfo nvidia-current | grep version:

что выдаёт?

в /lib/modules/4.10.1/updates/dkms/ только

nvidia-current-drm.ko  nvidia-current-modeset.ko
nvidia-current.ko      nvidia-current-uvm.ko

sudo modinfo nvidia-current | grep version:

выдает

version:        375.39
srcversion:     BE86ED8143335420EA4191

Я мог бы конечно посоветовать рискнуть здоровьем и, переключившись в tty6 какой-нибудь, удалить и пересобрать через dkms nvidia-current, но не буду этого делать, т.к. само наличие уже собранных dkms модулей для 4.10.1 говорит о том, что всё и так пашет нормально (по крайней мере как в 4.9).

в стартовом логе

error: virtualbox kernel module

Собранные dkms модули должны лежать в /lib/modules/4.10.1/updates/dkms/, но их там нет, вот и ругается.

Исходники для них должны быть в /usr/src/virtualbox-5.1.14 (или какая там версия).

sudo dkms install virtualbox/5.1.14

А вообще [2016-12-10] virtualbox REMOVED from testing (Debian testing watch) - virtualbox выкинули из тестинга, видать и у них куча ошибок.

должны лежать в /lib/modules/4.10.1/updates/dkms/

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

А смысл? Модуль собранный для другой версии ядра один фиг не запустится. В 4.10 куча регрессий, надо сидеть ровно на попе с 4.9 и ждать пока в 4.10.x всё пофиксят. Это норма.