LINUX.ORG.RU

Сообщения esvstn

 

SELinux. Нерегистрируемые блокировки при загрузке.

Форум — Security

Прикрутил SELinux к Archlinux. Политики брал с https://github.com/TresysTechnology/refpolicy. Загрузился в permissive режиме, внес поправки в политики с учетом системы инициализации systemd. То есть сам systemd у меня загружается в домене init_t, а дальше я прописал для него цепочки переходов в новые домены для остальных сервисов. Вот список модулей политик, которые у меня на данный момент загружены:

  • base.pp
  • init.pp
  • libraries.pp
  • logging.pp
  • selinuxutil.pp
  • modutils.pp
  • userdomain.pp
  • miscfiles.pp
  • sysadm.pp
  • authlogin.pp
  • sysnetwork.pp
  • storage.pp
  • application.pp
  • locallogin.pp
  • getty.pp
  • xserver.pp
  • mount.pp
  • unconfined.pp
  • udev.pp
  • avahi.pp
  • cups.pp
  • dbus.pp
  • alsa.pp
  • dhcp.pp
  • networkmanager.pp
  • ssh.pp
  • policykit.pp
  • ntp.pp

Перезагрузился, пофиксил все блокировки, которые выводятся при «journalctl -b | grep -i avc». Все, теперь после перезагрузки лог чистый. Отменил правила dontaudit («semodule -DB»). Возникло еще несколько запрещений, которые я тоже разрешил. Прописал в конфиге режим «enforcing», перезагрузился. При загрузке выводятся несколько красных сообщений об ошибках, успеваю прочесть только, что «failed» и «journalctl». Грепнул лог:

$ journalctl -b | grep -i denied 
июл 28 12:19:44 localhost journalctl[191]: Failed to kill journal service: Access denied
июл 28 12:19:46 localhost systemd-update-utmp[263]: Failed to get timestamp: Access denied
июл 28 12:19:47 localhost systemd-logind[309]: Failed to enable subscription: Access denied
июл 28 12:19:47 localhost systemd-logind[309]: Failed to fully start up daemon: Permission denied
июл 28 12:19:47 localhost systemd-logind[324]: Failed to enable subscription: Access denied
июл 28 12:19:47 localhost systemd-logind[324]: Failed to fully start up daemon: Permission denied
И так далее, много подобных сообщений. При «permissive» режиме такого поведения не наблюдается, поэтому предполагаю, что виноват все-же SELinux. Нашел в логе такое интересное место:
июл 28 13:34:43 localhost unknown[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
июл 28 13:34:43 localhost kernel: audit: type=1130 audit(1438079683.186:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
июл 28 13:34:43 localhost journalctl[189]: Failed to kill journal service: Access denied
июл 28 13:34:43 localhost unknown[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
июл 28 13:34:43 localhost kernel: audit: type=1130 audit(1438079683.290:11): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
июл 28 13:34:43 localhost systemd[1]: systemd-journal-flush.service: main process exited, code=exited, status=1/FAILURE
июл 28 13:34:43 localhost systemd[1]: Failed to start Flush Journal to Persistent Storage.
июл 28 13:34:43 localhost systemd[1]: Unit systemd-journal-flush.service entered failed state.
июл 28 13:34:43 localhost systemd[1]: systemd-journal-flush.service failed.
июл 28 13:34:43 localhost unknown[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t msg='unit=systemd-journal-flush comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
июл 28 13:34:43 localhost unknown[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Из него сделал вывод, что косячит «systemd-journal-flush.service». Решил посмотреть, что же он делает. Делает вещь он весьма нехитрую:
[Service]
ExecStart=/usr/bin/journalctl --flush
Перевел свой shell в домен init_t, попытался сделать flush вручную:
/bin/journalctl --flush
Failed to kill journal service: Access denied
То же самое. Фигня. Полез в исходники journalctl, дабы понять, что конкретно он не смог. Нашел нужный кусок кода:
if (access("/run/systemd/journal/flushed", F_OK) >= 0)
                return 0;

        /* OK, let's actually do the full logic, send SIGUSR1 to the
         * daemon and set up inotify to wait for the flushed file to appear */
        r = bus_open_system_systemd(&bus);
        if (r < 0)
                return log_error_errno(r, "Failed to get D-Bus connection: %m");

        r = sd_bus_call_method(
                        bus,
                        "org.freedesktop.systemd1",
                        "/org/freedesktop/systemd1",
                        "org.freedesktop.systemd1.Manager",
                        "KillUnit",
                        &error,
                        NULL,
                        "ssi", "systemd-journald.service", "main", SIGUSR1);
        if (r < 0) {
                log_error("Failed to kill journal service: %s", bus_error_message(&error, r));
                return r;
        }
Ага, вот и до D-Bus добрался. Пробую достучаться вручную до этого метода:
$ qdbus-qt4 --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.KillUnit
Error: org.freedesktop.DBus.Error.InvalidArgs
Invalid arguments '' to call org.freedesktop.systemd1.Manager.KillUnit(), expecting 'ssi'.
Ошибка, не передал аргументы. А теперь фокус:
$ qdbus-qt4 --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.KillUnit "systemd-journald.service" "main" SIGUSR1
Cannot find 'org.freedesktop.systemd1.Manager.KillUnit' in object /org/freedesktop/systemd1 at org.freedesktop.systemd1
Вот. При переданных аргументах оно вообще этот метод не видит. Я не понимаю, как такое возможно. Замечу, что даже после всех вышеприведенных действий сообщений о блокировках SELinux в лог journalctl не поступало. /var/log/audit/audit.log тоже молчит. Может, подскажете, куда дальше копать можно? А то я уже демон dbus начал трассировать в надежде информацию какую-нибудь добыть. Да, и еще. dbus у меня собран с поддержкой SELinux, и systemd тоже. Потому как я прочел, что некоторые блокировки могут происходить в юзерспейсе. Но сообщений user_avc в логе так же нет. Помогите советом, пожалуйста.

 , ,

esvstn
()

SELinux. Не происходит перехода в новый домен.

Форум — Security

Здравствуйте. Пытаюсь прикрутить SELinux к своему Арчу. Ядро перекомпилировал с поддержкой, утилиты всякие нужные установил. Загвоздка в systemd оказалась. Решил посмотреть, как сделано в Федоре и попытаться сделать так же. Подсмотрел, что в Федоре файл /usr/lib/systemd/systemd имеет контекст «system_u:object_r:init_exec_t». Соответственно, сам процесс запустится в домене init_t. Поменял у себя контекст на такой же, перезагрузился, все работает, домен процесса systemd сменился на init_t. Отлично. Дальше нужно сделать, чтобы systemd-journald работал в домене syslogd_t. Подсмотрел, что в Федоре файл /usr/lib/systemd/systemd-journald имеет контекст «system_u:object_r:syslogd_exec_t». Поменял у себя контекст на аналогичный, но после перезагрузки перехода systemd-journald в домен syslogd_t не произошло. Решил посмотреть, какие точки входа в новые домены вообще доступны для init_t.

# sesearch -T -s init_t
Found 9 semantic te rules:
   type_transition init_t var_run_t : file init_var_run_t; 
   type_transition init_t device_t : fifo_file initctl_t; 
   type_transition init_t etc_t : file etc_runtime_t; 
   type_transition init_t xdm_exec_t : process xdm_t; 
   type_transition init_t initrc_exec_t : process initrc_t; 
   type_transition init_t getty_exec_t : process getty_t; 
   type_transition init_t sulogin_exec_t : process sulogin_t; 
   type_transition init_t shell_exec_t : process sysadm_t; 
   type_transition init_t shell_exec_t : process initrc_t;

Сделал вывод, что моя версия политик вообще не предусматривает перехода напрямую из init_t в syslogd_t. Зато в домен syslogd_t можно перейти из initrc_t.

# sesearch -T -t syslogd_exec_t
Found 1 semantic te rules:
   type_transition initrc_t syslogd_exec_t : process syslogd_t;

Но ведь в моей системе systemd-journald запускается напрямую после systemd. То есть нет промежуточного шага в виде initrc скрипта. Делаю вывод, что мне нужно написать модуль политики для systemd, где разрешу переход init_t->syslogd_t. Потому что в Федоре так и сделано. Полазил по спецификации языка политик, накодил нечто такое:

# systemd.te

policy_module(systemd,1.0.0)

########################################
#
# Declarations
#
gen_require(`type syslogd_t, syslogd_exec_t;')
domain_entry_file(syslogd_t, syslogd_exec_t)
# systemd.if

interface(`systemd_domtrans',`
        gen_require(`
                type init_t, syslogd_t, syslogd_exec_t;
        ')

        domtrans_pattern(init_t, syslogd_exec_t, syslogd_t)
')
Модуль отлично компилируется и даже загружается. Но почему-то после загрузки команда «sesearch -T -t syslogd_exec_t» все равно показывает, что переходить можно только из initrc_t. Что я делаю не так? Не ругайтесь особо, я SELinux только начал изучать, а создавать правила через audit2allow некузяво. Хочу разобраться.

 , ,

esvstn
()

Не могу заюзать функцию ядра Linux.

Форум — General

Здравствуйте. Возникла задача - прочесть параметры, с которыми запущено ядро из загружаемого модуля. Вернее, не ядро, запущенное из модуля, а в одном из модулей ядра мне ядерные параметры получить надо. В исходниках ядра нашел функцию, которая, возможно, умеет это делать. Вот она:

include/linux/mm.h: int get_cmdline(struct task_struct *task, char *buffer, int buflen);
Пытаюсь заюзать эту функцию в модуле. Вот код:
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mm.h>

MODULE_LICENSE( "GPL" );

static int __init getcmdline_init(void)
{
        char buf[128];
        get_cmdline(0,buf,128);
        printk("cmd: %s\n", buf);
        printk("cmd: Hello\n");
        return 0;
}

static void __exit getcmdline_exit(void)
{
}

module_init(getcmdline_init);
module_exit(getcmdline_exit);

Собираю таким Makefile-ом:

CURRENT = $(shell uname -r)
KDIR = /lib/modules/`uname -r`/build
PWD = $(shell pwd)
obj-m += getcmdline.o
default: 
        $(MAKE) -C $(KDIR) M=$(PWD) modules

При сборке получаю варнинг:

WARNING: "get_cmdline" [/root/fun/getcmdline/getcmdline.ko] undefined!
Само собой, модуль не грузится, выдает ошибку:
insmod: ERROR: could not insert module getcmdline.ko: Unknown symbol in module
При просмотре journalctl видно, что не находит именно символ get_cmdline. Но в загруженном ядре он есть и объявлен как экспортируемый:

$ grep get_cmdline /proc/kallsyms 
ffffffff81181790 T get_cmdline

В незапакованном ядре она тоже присутствует:

$ nm -n  /lib/modules/3.18.4-1-selinux/build/vmlinux | grep get_cmdline
ffffffff81181790 T get_cmdline

В чем здесь магия? Ведь printk, который объявлен в ядре точно так же, я использую безо всяких дополнительных определений. Подскажите пожалуйста, почему функцию увидеть не могу?

 , ,

esvstn
()

Подмена зависимых динамических библиотек в процессе работы программы

Форум — Development

Здравствуйте! У меня появился такой вопрос. Я полазил по форуму и прочел, что если некий бинарник использует разделяемые библиотеки, то они mmap-ятся в оперативную память. В таком случае, если во время работы бинарника заменить либу на более новую (или вообще удалить), то есть вероятность, что система переммапит его в память и выполнение бинарника испоритится. Эксперименты показывают, что вероятность такая довольно велика. Бинарник падает. Но тогда мне непонятно, как пакетный менеджер может обновлять пакеты, от которых зависит? Например pacman:

$ ldd /bin/pacman
        linux-vdso.so.1 (0x00007fff6df57000)
        libalpm.so.9 => /usr/lib/libalpm.so.9 (0x00007fd0e6059000)
        libarchive.so.13 => /usr/lib/libarchive.so.13 (0x00007fd0e5db6000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fd0e5a13000)
        libgpgme.so.11 => /usr/lib/libgpgme.so.11 (0x00007fd0e57da000)
        libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007fd0e5567000)
        libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fd0e50eb000)
        libacl.so.1 => /usr/lib/libacl.so.1 (0x00007fd0e4ee2000)
        libattr.so.1 => /usr/lib/libattr.so.1 (0x00007fd0e4cdd000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fd0e4ab3000)
        liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0x00007fd0e4891000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fd0e466b000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fd0e445b000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fd0e4245000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd0e628a000)
        libassuan.so.0 => /usr/lib/libassuan.so.0 (0x00007fd0e4033000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007fd0e3e21000)
        libidn.so.11 => /usr/lib/libidn.so.11 (0x00007fd0e3bed000)
        libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007fd0e39c4000)
        libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fd0e3749000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007fd0e34fc000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007fd0e3217000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007fd0e2fe4000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007fd0e2de0000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fd0e2bc3000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd0e29bf000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007fd0e27b2000)
        libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007fd0e25ae000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007fd0e2397000)
Очень много от чего зависит. Но почему тогда при переустановке пакетов, от которых от зависит, он не падает? У меня довольно давно стоит Арч и я регулярно его обновляю, но всегда все проходило стабильно.

 ,

esvstn
()

Как генерируются ключи в CryptoAPI Linux?

Форум — Security

Ковыряю стандартный модуль ядра aes-generic. Пытаюсь понять, как работает. Вроде начало понятно, надо создать структурку типа struct crypto_alg, заполнить ее соответствующие поля и записать туда же указатели на функции crypto_aes_set_key, aes_encrypt и aes_decrypt. Эти функции необходимо реализовать в коде. Ничего не меняю, опять же смотрю стандартную реализацию.

int crypto_aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
		unsigned int key_len)
{
	struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
	u32 *flags = &tfm->crt_flags;
	int ret;

	ret = crypto_aes_expand_key(ctx, in_key, key_len);
	if (!ret)
		return 0;

	*flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
	return -EINVAL;
}
Вот здесь не очень понятно. Структура ctx, насколько я понял из документации, необходима для передачи неких приватных данных между вызовами функции шифрования. Ее реализация:
struct crypto_aes_ctx {
	u32 key_enc[AES_MAX_KEYLENGTH_U32];
	u32 key_dec[AES_MAX_KEYLENGTH_U32];
	u32 key_length;
};
Раскопал реализацию структуры tfm:

struct crypto_tfm {

	u32 crt_flags;
	
	union {
		struct cipher_tfm cipher;
		struct digest_tfm digest;
		struct compress_tfm compress;
	} crt_u;
	
	struct crypto_alg *__crt_alg;
};
Реализации различны. Предпоолагаю, что функция crypto_tfm_ctx() выполняет некое преобразование над структурой, но документации по ней я не нашел. Это печалит. Буду признателен, если подскажете, где почитать можно. Далее я предполагаю, что основную работу над преобразованием ключа выполняет функция crypto_aes_expand_key(). Ее хочется попробовать отладить. В начало функции впиливаю такой код:
int crypto_aes_expand_key(struct crypto_aes_ctx *ctx, const u8 *in_key, unsigned int key_len)
{
	const __le32 *key = (const __le32 *)in_key;
	u32 i, t, u, v, w, j;
	#ifdef __DEBUG__
		u8 ic;
		static u8 callnum;
		printk("@setkey: %d \n", callnum++);
                for(ic = 0; ic < key_len; ic++) printk(" %d", *(in_key++));
                printk( "\nlen: %d \n", key_len );
	#endif
Компилю, подгружаю модуль и шифрую тестовый файлик. Парольную фразу использую «password»:
insmod aes_generic_test.ko
cryptsetup -c aestest luksFormat test.img
Смотрю dmesg, а там...
[20424.784155] @setkey: 0 
[20424.784158]  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
len: 32 
[20424.833566] @setkey: 1 
[20424.833632]  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
len: 32 
[20427.779761] @setkey: 2 
[20427.779761]  130 92 60 220 127 250 172 229 23 142 121 102 90 147 86 68 83 26 104 151 161 177 175 125 248 18 91 57 36 187 180 43
len: 32 
[20427.779761] @setkey: 3 
[20427.779761]  130 92 60 220 127 250 172 229 23 142 121 102 90 147 86 68 83 26 104 151 161 177 175 125 248 18 91 57 36 187 180 43
len: 32 
Почему-то 4 вызова функции. При этом при первых двух вызовах там вообще нули в ключе. Шифрую еще раз. Вывод dmesg:
[21096.884222] @setkey: 4 
[21096.884226]  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
len: 32 
[21096.897071] @setkey: 5 
[21096.897077]  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
len: 32 
[21099.761775] @setkey: 6 
[21099.771637]  247 128 66 45 202 109 37 95 162 76 218 185 161 120 54 193 40 30 45 78 116 189 142 58 123 196 127 156 184 82 145 154
len: 32 
[21099.775441] @setkey: 7 
[21099.775470]  247 128 66 45 202 109 37 95 162 76 218 185 161 120 54 193 40 30 45 78 116 189 142 58 123 196 127 156 184 82 145 154
len: 32 
Выгружаю и загружаю модуль обратно. Шифрую.
[21217.221897] @setkey: 0 
[21217.221897]  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
len: 32 
[21217.229780] @setkey: 1 
[21217.229783]  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
len: 32 
[21220.164857] @setkey: 2 
[21220.164857]  141 102 75 227 249 233 47 193 248 96 3 193 14 9 146 192 249 134 63 180 15 82 95 186 75 118 217 162 46 181 170 253
len: 32 
[21220.164857] @setkey: 3 
[21220.164857]  141 102 75 227 249 233 47 193 248 96 3 193 14 9 146 192 249 134 63 180 15 82 95 186 75 118 217 162 46 181 170 253
len: 32
Почему везде разные ключи? Парольные фразы я вводил везде одинаковые. И почему они только на 3-й и 4-й вызов оказываются отличными от нуля? Я не понимаю, как это работает. Могу ли я собственным алгоритмом генерировать ключ из парольной фразы?

 , , ,

esvstn
()

Компиляция модуля ядра под arch linux

Форум — General

Здравствуйте! Пытался научиться разработке модулей ядра по книге Олега Цилюрика «Разработка модулей ядра Linux». Сразу же столкнулся с проблемой - собранный модуль не хочет загружаться.

$ insmod md1.ko
insmod: ERROR: could not insert module md1.ko: Invalid module format
$ modprobe md1.ko
$ dmesg | tail -1
[188270.664792] md1: no symbol version for module_layout
Нагуглил, что это может быть из за несовместимости версий ядра. Мое ядро:
$ uname -r
3.15.8-1-ARCH
Исходники для компиляции качал с kernel.org. Версия 3.15.8. Конфиг выкачал из текущего ядра и кинул в каталог с исходниками. Но там релиз не "-1-ARCH", а "-ARCH". Что, собственно, мы и замечаем в собранном модуле в графе vermagic:
$ modinfo md1.ko
filename:       /root/my_module/md1.ko
version:        3.15.8-1-ARCH
author:         Oleg Tsiliuric <olej@front.ru>
license:        GPL
srcversion:     5E2EE73E2DB63255874264A
depends:        
vermagic:       3.15.8-ARCH SMP preempt mod_unload modversions
Есть ли возможность писать модули для текущего арчевского ядра, или они подгрузятся только в заново скомпилированное?

 , , ,

esvstn
()

Разрешение экрана в plymouth

Форум — General

Здравствуйте!

Столкнулся на днях с такой проблемой. Установил RedHat 6.2 на компьютер с процессором Intel(R) Atom(TM) CPU D2550. Видеоадаптер встроенный в проц. После загрузки рабочего стола выводилось разрешение 1280х1024 вне зависимости от монитора, который я к нему подключаю. И других настроек не предлагает. Xrandr показывает то же самое. Самостоятельно собрать драйвер ни один не смог, почему-то они у меня после сборки не заводились. Нагуглил, что в более новых ядрах присутствует драйвер gma500_gfx, который теоретически может подцепить мой видеоадаптер. Ну скачал ядро 3.15.1-1.el6.elrepo.x86_64, загрузился с него. Разрешение не искажает, но выводит изображение не на весь экран, а в прямоугольнике в левом верхнем углу. Подключил репозиторий, обновил иксы. Увидел в репе драйвер для иксов xorg-x11-drv-modesetting-0.5.0-1.el6.x86_64. Ради эксперимента решил поставить. И ура! Монитор определяет автоматически, все разрешения настраиваются через графический интерфейс.

Но! Экран загрузки системы по прежнему показывается в прямоугольнике в левой верхней части экрана. Некрасиво очень. Нагуглил, что за этот экран отвечает программка plymouth, сидящая в initramfs. И выводит изображение она через дефолтный фреймбуфер. Разрешение фреймбуфера, говорят, можно менять задавая параметры ядра в grub вроде vga=*режим*. Но во-первых в списке режимов нет моего монитора (1600х900), а во-вторых оно на параметры вообще не реагирует, я разные пробовал ставить. Распаковал initramfs, драйвера modesetting там не обнаружил(что закономерно, он же для иксов). Поудалял оттуда все, что хоть как-то напоминает framebuffer. Но картинка не меняется, все выглядит точно так же. Делаю вывод, что framebuffer вкомпилен в ядро. Предполагаю, что нужно в initramfs установить какой-нибудь драйвер, хоть самый глупый, пусть в дурацком разрешении запускает, но хоть на весь экран. Как-то в конфигах plymouth этот драйвер прописать заместо дефолтного и собрать initramfs обратно. Ну как-то так хочется. Скажите пожалуйста, это возможно? И ежели возможно, то как? Всем заранее признателен за возможные ответы.

 , , , ,

esvstn
()

RSS подписка на новые темы