OpenVZ Forum


Home » International » Russian » не собирается пропатченное fbsplash ядро
Re: не собирается пропатченное fbsplash ядро [message #14824 is a reply to message #14713] Wed, 11 July 2007 10:48 Go to previous message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

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

 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Проблемы с производительностью контроллера Intel SRCS16
Next Topic: *SOLVED* Пакет не на том интерфейсе!
Goto Forum:
  


Current Time: Fri Jun 27 05:33:43 GMT 2025

Total time taken to generate the page: 0.02400 seconds