LINUX.ORG.RU

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

 , , , ,


1

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
что я делаю не так? где допустил ошибку? что за сертификаты и с чем их едят?

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

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

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

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

(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
я думал пусто между [ ] это и есть excluded ибо <N> excludes не жмакается

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

Тыц

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

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

вот как это выглядит в .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
как поступить? закоментить все 3 строки или удалить
CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/benh@debian.org.cert.pem"
вчера удалял не помогло - ну попытка не пытка попробую еще

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

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

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

поздно 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
и когда вовремя сборки опять спросило про сертификаты - просто нажал enter и сборка продолжилась, если не получится - попробую через make deb-pkg, скажите а сколько вся эта канитель будет продолжаться - уже час с лишним собирает, понимаю зависит от проца - но он загружен не полностью, 2 ядра однопоточных ядра по 3500 мгц

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

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

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

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

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

amd_amd ()

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

amd_amd ()

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

amd_amd ()
Ответ на: комментарий от amd_amd
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, так что ядро пока сильно сыроватое.

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

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

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

./arch ./include ./scripts ./.config ./Module.symvers
остальное можно сносить.

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

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

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

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
нет данных по SMP, можно на таком кастрате продолжать собирать другие ядра или не желательно?

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

Выхлоп нормальный, но модули для ядра (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 походу ещё не завезли.

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

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

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

cp /boot/config-4.10.1* .config
использовался .config не такой как вчера?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эта такая фигня с 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

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

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

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

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

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

Да, не дает ставить одно ядро два раза, перезагрузиться в 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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

Какая? 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
Или какие сейчас пути актуальны для собранного ядра.

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

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

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

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

Если при установке куча ошибок при сборке модулей на отсутствие 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.
есть какая команда - для прверки работоспособности headers, а то все догадки на основании неработоспособности virtualbox который их просит...

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

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

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

run-parts: executing /etc/kernel/header_postinst.d/dkms 4.10.1 /boot/vmlinuz-4.10.1
какой тут может быть run если он неизвестен системе

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

Выше же писалось, что 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:
Получаем версию 0.8
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 только.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous
 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 - все равно пашет

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

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

sudo modinfo nvidia-current | grep version:

что выдаёт?

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

в /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

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

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

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

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

error: virtualbox kernel module
но virtualbox все равно работает, помоему принудительный запуск '/sbin/vboxconfig' и многократный ввод паролей дал такой результат, только как избавиться от ошибки с модулем, где он вообще лежит ???/usr/share/virtualbox??? - надо поколдовать над ним

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

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

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

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

sudo dkms install virtualbox/5.1.14

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

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

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

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

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

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

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