Ядра для gentoo

или как прикрутить ведро от арчика в ламповую гентушечку, вместе с mkinitcpio ?

cp?

Никто не заставляет использовать конфиги ядра из пакета genkernel.
У меня свой конфиг. Новые ядра собираю так:

# cd /usr/src/linux
# zcat /proc/config.gz >.config
# genkernel --kernel-config=/usr/src/linux/.config --no-mrproper --oldconfig --menuconfig --symlink --mountboot --makeopts=-j1 --e2fsprogs --compress-initramfs-type=xz --busybox --bootloader=grub --splash=natural_gentoo --splash-res=1280x1024 --install all

переехал на dracut полтора года назад, и возвратятся, как то, совсем не охота.

cp?

А то у генты и арча всё одинаковое, чтоб можно было просто скопировать mkinitcpio?

И сомневаюсь, что образ initrd, собранный под арч, взлетит на генте.

В связи с этим такой вопрос: как отучить genkernel от постоянного scanning, или как прикрутить ведро от арчика в ламповую гентушечку, вместе с mkinitcpio ?

Initrd отключи, ага. В генкернеле.
А еще нету смысла в генте использовать генкернел, да. Он для лохов :)

переехал на dracut

Ну я тоже initrd собирал через dracut.

Но хочется вообще не заморачиваться с ядром.

тогда глянь как это делается в Calculate, там они это как то автоматизировали.

Мало того что для лохов, так ещё и ядро собирает через раз.

А еще нету смысла в генте использовать генкернел, да. Он для лохов :)

Ну да, меня генкернел не устраивает.

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

Там же просто бинарное ядро используется.

Вот есть в gentoo genkernel

genkernel бесполезен

Собирать ядро руками

Только это путь истинного самурая. И init{rd/ramfs} тоже ручками ага.

Между тем, пользователи арчика имеют ништяковое ведро, и клёвую тулзу mkinitcpio.

Между тем некоторые пользователи gentoo пилят себе свои собственные ядра с блек-джеком и продажными женщинами… да такие о которых этому твоему арчику только мечтать. А mkinitcpio, dracut если чо есть и в генте.

У них самописная тулза, cl-kernel, ЕМНИП.

По факту - тот же самый генкернел, просто упростили некоторые параметры (оно само пускает генкернел).

И да, на 42 или 46% калька стоит секунд 10, и как раз в это время идёт этот чёртов scanning...

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

При чем здесь патчьсеты? В арчике полтора патча примерно как и в gentoo-sources. Главное вовсе не патчики. Главное то, что в арче все стараются вынести в модули а потому что они затем генерируют инитрамфс при помощи своего mkinitcpio… Т.е. если тебе нужно то же самое то и делать нужно так же как и там.

Initrd отключи, ага. В генкернеле.

genkernel умеет не собирать initrd, если его попросить.

А еще нету смысла в генте использовать генкернел, да.

Есть, genkernel уменьшает объем ручной работы. Например, сам прописывает новое ядро в grub.conf. LFS-ники пусть делают все руками, а у нас есть genkernel.

Только это путь истинного самурая. И init{rd/ramfs} тоже ручками ага.

Ага, а надо что-то подключить и сразу «щаща, подождите 15 минут, ядро пересоберётся». А потом «блин, забыл ещё один модуль, ща, ещё 15 минут». Ну это если утрировано. Конечно досборка 1-2 модулей займёт пару минут, но возится лень.

А еще нету смысла в генте использовать генкернел, да. Он для лохов :)

Он не просто для лохов… Больше пользы было бы если б разрабы прикрутили к USE флагу build для *-sources все ту же тупую последовательность сборки ведра и модулей - боло бы больше пользы.

Между тем, пользователи арчика имеют ништяковое ведро, и клёвую тулзу mkinitcpio.

На самом деле, не очень клёвую. В дебиане более продвинутый аналог mkinitcpio, которому можно говорить как «сделай мне initramfs для текущего железа, йоу», так и «сделай мне такой initramfs, который имеет хорошие шансы взлететь и при неожиданной смене железки, чувак!»

Кстати да, ТС, зачем тебе initrd/initramfs? Впиливай модули для своего чипсета и корневой ФС намертво, остальное можно собрать модулями.

Главное то, что в арче все стараются вынести в модули а потому что они затем генерируют инитрамфс при помощи своего mkinitcpio… Т.е. если тебе нужно то же самое то и делать нужно так же как и там.

Да, но за счёт чего в арчике не идёт перебор всех возможных модулей? На данный момент стартовый арчик запускается быстрее стартовой генты (и там и там система почти голая, хламом пока не обрастал). И я бы во всём сделал выбор в сторону генты, но меня удручает только ситуация с ядром. Собираю руками ядро я криво как-то.

LFS-ники пусть делают все руками, а у нас есть genkernel.

Не путай lfs-ников с идиотами которые будут тупо вбивать одну и ту же последовательность и не оформят её в виде скрипта. К примеру вот такого install_kernel

В дебиане более продвинутый аналог mkinitcpio

Это который?

С дебианом я так и не смог подружиться, сколько пробовал.

genkernel умеет не собирать initrd, если его попросить.

Я об этом и писал.

Есть, genkernel уменьшает объем ручной работы. Например, сам прописывает новое ядро в grub.conf. LFS-ники пусть делают все руками, а у нас есть genkernel.

В теории да, на практике - нунафиг.

Кажется, initramfs-tools называется.

Ага, а надо что-то подключить и сразу «щаща, подождите 15 минут, ядро пересоберётся».

Надо что то подключить? Что именно? И опять же у portage или у make мозгов нету. Чтобы гарантированно не возникла описанная тобою ситуация собирай ядро с вообще всеми модулями… Но помоему подобный подход тоже еще тот бред. Для дистибутивного ядра которое на live-{cd/dvd/usb/и т.п} это самое оно.

К примеру вот такого install_kernel

Это для меня пока недоступно.

На данный момент стартовый арчик запускается быстрее стартовой генты

Так ты определить что тебе нужно: арчик, гента или чтобы быстрее? Потому как если «чтобы быстрее» то ядро монолит и init=/bin/bash будет стартовать гораздо быстрее этих твоих арчиков.

Надо что то подключить? Что именно?

Хм. Подумал и прикинул: вебкамера итак встроена в ноут, клава/тачпад - тоже. Так что из подключаемого остаются только принтеры/сканеры, но это уже вроде не область ядра.

Тогда да, получается, что нету необходимости дёргаться.

initrd/initramfs юзаю для раннего KMS на ATi. Если есть другие более-годные способы - готов выслушать.

Зачем велосипедить скрипты, если уже есть готовый генкернел?

Зачем? Собираешь всю периферию модулями и всё ок.

Это для меня пока недоступно.

make bzImage && make modules && make modules_install && make install 

Это так непостижимо трудно? И конечно же Advanced Bash-Scripting Guide ты тоже никогда не видел.

Так ты определить что тебе нужно: арчик, гента или чтобы быстрее?

Что мне хочется: ранний KMS, запуск ядра без scanning. Видеокарта ATi.

Я уже упомнил об этом: если вшиваю в ядро драйвер radeon и фреймбуффер radeon - у меня на загрузке видео система стоит 40-50 секунд (надпись probing rv710 microcode, ЕМНИП), после чего срабатывает KMS и загрузка продолжается своим ходом. Это если без initrd и зашито в ядро.

Если собирать модулем - KMS срабатывает после /dev в openRC. И тут уже без разницы, есть initrd или нету. (Или я что-то не так делаю).

make bzImage && make modules && make modules_install && make install

Так и собираю.

И конечно же Advanced Bash-Scripting Guide ты тоже никогда не видел.

Видел, но прочитать так и не удосужился до сих пор.

Зачем велосипедить скрипты, если уже есть готовый генкернел?

Пробовал недели 1,5 назад собирать генкернел. На 4-ый фейл я уже просто устал перебирать модули в нём.

Тогда да, получается, что нету необходимости дёргаться.

Включил то что нужно остальное в чем нет вообще никакого смысла отключил изабыл о нем.

Зачем велосипедить скрипты, если уже есть готовый генкернел?

Затем, что генкернел не нужен.

Что мне хочется: ранний KMS, запуск ядра без scanning. Видеокарта ATi.

Я счастливый пользователь nouveau. Все в ядре. Переключение происходит моментально и непосредственно сразу после груба. С ати дел не имел.

Между тем, пользователи арчика имеют ништяковое ведро, и клёвую тулзу mkinitcpio. В генте есть какой-то mkinitcpio, но жутко древней версии (ЕМНИП 0.5х, когда в арчике 0.9х).

Что-то вы врёте.

eix mkinitcpio
* sys-kernel/mkinitcpio
     Available versions:  ~0.9.2-r1 {{cryptsetup device-mapper dmraid mdadm pcmcia udev}}
     Homepage:            http://www.archlinux.org/
     Description:         Modular initramfs image creation utility ported from Arch Linux

Всё в нём хорошо, только бесит, что при каждой загрузке он запускает scanning... и перебирает все возможные модули

Выходов несколько:
1. Собирать ядро только с нужными опциями, модули ФС и контроллера hdd собрать монолитно, остальные отключить, тогда genkernel не поместит вообще ни одного модуля в initrd
2. Сказать genkernel при генерации initrd не помещать модули

genkernel ramdisk --no-ramdisk-modules

Вывод отсюда, в общем, один: вы не хотите читать документацию.

Что мне хочется: ранний KMS, запуск ядра без scanning. Видеокарта ATi.

Я уже упомнил об этом: если вшиваю в ядро драйвер radeon и фреймбуффер radeon - у меня на загрузке видео система стоит 40-50 секунд (надпись probing rv710 microcode, ЕМНИП), после чего срабатывает KMS и загрузка продолжается своим ходом. Это если без initrd и зашито в ядро.

Вы, видимо, не читаете документацию: http://www.gentoo.org/doc/en/xorg-config.xml

... For newer AMD/ATI cards (RadeonHD 2000 and up), you will need to emerge radeon-ucode or linux-firmware. Once you have installed one of these packages, configure your kernel as shown:

Code Listing 2.5: AMD/ATI settings (Setup the kernel to use the radeon-ucode firmware)

Device Drivers --->
  Generic Driver Options --->
  [*]  Include in-kernel firmware blobs in kernel binary
  # RadeonHD 2000, 3000, and 4000 series cards:
  (radeon/R600_rlc.bin radeon/R700_rlc.bin) External firmware blobs
  # RadeonHD 5000, a.k.a Evergreen:
  (radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
   radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/CYPRESS_rlc.bin
   radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin
   radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin 
   radeon/REDWOOD_rlc.bin) External firmware blobs
  # Radeon HD 6000/7300 series Fusion APUs:
  (radeon/PALM_me.bin radeon/PALM_pfp.bin radeon/SUMO2_me.bin
   radeon/SUMO2_pfp.bin radeon/SUMO_me.bin radeon/SUMO_pfp.bin
   radeon/SUMO_rlc.bin) External firmware blobs
  # Radeon HD 6400-7600 aka. Northern Islands:
  (radeon/BARTS_mc.bin radeon/BARTS_me.bin radeon/BARTS_pfp.bin
   radeon/BTC_rlc.bin radeon/CAICOS_mc.bin radeon/CAICOS_me.bin
   radeon/CAICOS_pfp.bin radeon/CAYMAN_mc.bin radeon/CAYMAN_me.bin
   radeon/CAYMAN_pfp.bin radeon/CAYMAN_rlc.bin radeon/TURKS_mc.bin
   radeon/TURKS_me.bin radeon/TURKS_pfp.bin) External firmware blobs
  # Radeon HD 7500/7600 series Fusion APUs:
  (radeon/ARUBA_me.bin radeon/ARUBA_pfp.bin radeon/ARUBA_rlc.bin)
   External firmware blobs
  # Radeon HD 7700-7900 aka. Southern Islands:
  (radeon/PITCAIRN_ce.bin radeon/PITCAIRN_mc.bin radeon/PITCAIRN_me.bin
   radeon/PITCAIRN_pfp.bin radeon/PITCAIRN_rlc.bin radeon/TAHITI_ce.bin
   radeon/TAHITI_mc.bin radeon/TAHITI_me.bin radeon/TAHITI_pfp.bin
   radeon/TAHITI_rlc.bin radeon/VERDE_ce.bin radeon/VERDE_mc.bin
   radeon/VERDE_me.bin radeon/VERDE_pfp.bin radeon/VERDE_rlc.bin)
   External firmware blobs
  # all:
   (/lib/firmware/) Firmware blobs root directory

(Enable Radeon KMS support)
Device Drivers --->
  Graphics support --->
  <*>  Direct Rendering Manager --->
  <*>    ATI Radeon
  [*]      Enable modesetting on radeon by default

Note: Old Radeon cards (X1900 series and older) don't need the radeon-ucode package or any firmware configuration. Just enable the Direct Rendering Manager and ATI Radeon modesetting. Now that you're done setting up KMS, continue with preparing /etc/portage/make.conf in the next section.

Как видно для новых карт от ATI (AMD) нужны прошивки, которые должны быть доступны в момент загрузки модуля или если модуль собран монолитно почти сразу при определении карты, как следствие их нужно указать в соответствующем пункте в конфиге ядра и поместить в initramfs, в /lib/firmware, если вы его используете.

Сделать это можно только перепаковав initrsmfs вручную:

mkdir /tmp/initrd
cd /tmp/initrd
gunzip -c -9 /boot/initramfs-*.*.*.img | cpio -i -d -H newc
mkdir lib/firmware
cp -R /lib/firmware/radeon lib/firmware
find . | cpio -o -H newc | gzip -9 > /boot/initramfs-*.*.*.img2

Указать новый initrd в конфиге загрузчика.

Так же можете убрать из initrd лишние модули, если до сих пор не собрали ядро правильно.

UPD: Не прав, можно указать опцию '--firmware' для помещения firmware в initrd при генерации initrd с помощью genkernel:

genkernel ramdisk --firmware

Э, фундаментально.

Моя вина, я обычно шарюсь по gentoo-wiki, почему-то считал, что информация на gentoo.org мало обновляется, и что более свежая информация будет в wiki.

Спасибо, проверю. Может теперь будет всё окей.

На самом деле в этом руководстве есть не точности, к примеру драйвер nouveau в новых ядрах теперь располагается в

Device Drivers --->
      Staging drivers --->
      Nouveau (nVidia) cards

Device Drivers
  Graphics support --->
    Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->
    <*>    Nouveau (nVidia) cards

А вот русскоязычную версию лучше не использовать, он уже 6 лет не обновлялась

Я от этого отталкивался. Часть технической информации на английском мне трудно понять.

Собираю ядро с патчами от geek-sources на ubuntu.

Следующие патчи ломают сборку.

../geek-sources/files/3.6.6/mageia/smack-unionfs-deadlock-fix.patch
../geek-sources/files/3.6.6/suse/patches.suse/SUSE-bootsplash
../geek-sources/files/3.6.6/suse/patches.suse/stack-unwind

+ ошибка связанная с reach acl, я просто убрал все патчи reach acl от suse.

Это пока.. мб ещё что выявится.

P.S. ой удалят модераторы коммент за личную переписку.

Патчи применял так:

krab@notebook:~/temp/kernel/linux-3.6.6$ cat ../while 
#!/bin/bash
/home/krab/temp/kernel/geek-sources/files/3.6.6/

for i in "$@"
do
        cat /home/krab/temp/kernel/geek-sources/files/3.6.6/${i}/patch_list | while read str
        do
                patch -p1 < /home/krab/temp/kernel/geek-sources/files/3.6.6/${i}/$str
        done
done

bash ../while bfq debian fedora genpatches mageia suse ukms

+ патч убунты.

grep -e smack-unionfs-deadlock-fix.patch  -e SUSE-bootsplash -e stack-unwind sys-kernel:geek-sources-3.6.6:20121108-155556.log 
 * Applying smack-unionfs-deadlock-fix.patch ...
 * Applying patches.suse/SUSE-bootsplash ...
 * Applying patches.suse/stack-unwind ...
 * Skipping patch --> stack-unwind
 * Applying patches.arch/stack-unwind-cfi_ignore-takes-more-arguments ...

stack-unwind и не накладывается, patches.suse/0016-ext4-Implement-richacl-support-in-ext4.patch замаскан именно потому что ты и сказал… остальное умвр

умнр, + ещё и aufs из debian/all/aufs3 :)

А вообще bhfq не городи велосипеды. Смотри в сторону eclass/kernel-geek.eclass фактически там тот же bash так что… все уже изобретено ;)

Какие велосипеды, я считал что в твоем гите всё нормально отлажено и не рабочие патчи комментированные в списке, оказывается нет.

Какие велосипеды, я считал что в твоем гите всё нормально отлажено и не рабочие патчи комментированные в списке, оказывается нет.

Зачем мне нужно городить велосипеды если даже мельком взглянув на eclass/kernel-geek.eclass можно заметить что патчи которые не осиливают patch -p1 --dry-run идут лесом.

Вобщем как не хочется признаваться согласен с post-factum, свалка какая-то (с).

Зачем мне нужно городить велосипеды

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

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

С чего ты взял что патчь patches.suse/stack-unwind нерабочий? patches.suse/stack-unwind взят из git suse и там он вполне себе рабочий иначе его бы давно удалили или замаскали. Сам я маскаю только те патчи которые реально ломают… как к примеру patches.suse/0016-ext4-Implement-richacl-support-in-ext4.patch

А по всему остальному так там все что неосиливает patch -p1 --dry-run идет лесом… и маскать я его не собираюсь.

yes || make oldconfig