| не собирается пропатченное fbsplash ядро [message #14713] |
Sat, 07 July 2007 14:43  |
cobaltt
Messages: 5
Registered: July 2007
|
Junior Member |
|
|
Здравствуйте всем!
Система Gentoo profile 2006.1
версия патча ovz-028.035
Накладываю патч fbsplash, vesafb-tng, vesafb-tng-mtrr
Ядро не собирается.
конфиг 2.6.18 enterprise
Пожалуйста скажите - эти вещи не совместимы?
С уважением Илья.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: не собирается пропатченное fbsplash ядро [message #14824 is a reply to message #14713] |
Wed, 11 July 2007 10:48  |
|
|
fbsplash от Gentoo накладывается без больших проблем, vesa-tng накладывать особо нужды нет. Ибо fbsplash работает с любым fb-драйвером, а вот Xen-монитор (который как бы в коробке с openvz-el5) не поддерживает любые опирающиеся на BIOS драйвера.
Могу куда-нибудь выложить гентушные ebuild последних openvz-el5 ядер (у меня они называются теперь fan_rh5_ovz-sources-8.1.6.036 и fan_rh5_ovz_xen-sources-8.1.6.036). Включают и fbsplash-patch (а также unionfs, aufs).
Недавно установил на шлюзе тоже openvz, поэтому не уверен, что apache2 будет работать. Но по идее все ebuild должны быть доступны по адресу http://89.19.167.91/fantoo/fantoo-new.tgz
PS: Сам я пока застрял на пробеме: как задать для загруженного с помощью udev видео-драйвера нужный режим? Каких-то опций универсальных, чтоб все видеодрайвера их хватали, я не нашел. Пока идея только такая: после загрузки драйверов устанавливать режим с помощью fbset. Но в таком случае очень много перед этим других видео режимов устанавливается. Что не есть красиво.
PS $2:
а размер памяти, занимаемого xen-монитором, зависит от общей памяти машины. Чем больше RAM на машине, тем больше памяти занимает и xen-монитор (версии 3.0.3 ... 3.1)
PS #3:
экспериментировал с initrd от RHEL5. Цель -- проверить, что с initrd от Gentoo все в порядке и он освобождает initrd-память (память, выделенную под initrd). Вопрос вызывало сообщение init-скриптов, что найдено доступной памяти на 6 мег меньше, чем есть на машинах.
Решил, что 6 Мег уходит скорее всего под ядро, ибо и с initrd от RHEL5 размер общей памяти (сообщаемой и по free) не увеличился (не проверял пока это по dmesg)
Кроме того, в RedHat init-скрипты умеют работать и при смонтированных уже /proc, /sys /dev. В Gentoo наличие смонтированных указанных каталогов вызывало панику (initrd от RedHat монтирует указанные каталоги и не размонтирует их при запуске init на корневом разделе). В Arch-linux в initrd, как и в RedHat, для загрузки драйверов используется udev. Но при передаче управления init на корневом разделе все смонтированные каталоги размонтируются и сам udev останавливается.
В общем, модификация основных rc от Gentoo на предмет анализа наличия смонтированных /proc /sys /dev не помешала бы. Как и использование в initrd udev для подгрузки драйверов. А то нынче, например, грузятся (пытаются подгрузиться) все скази-драйвера. Даже если у нас такого железа и нет.
[Updated on: Wed, 11 July 2007 11:00] Report message to a moderator |
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
