Bug 37201

> /etc/udev/rules/50-udev-default.rules: The line takes no effect, ignoring.

make-initrd запускает udev с параметром  --resolve-names=never:

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/etc/rc.d/init.d/udev;h=1e45c832e13e635f2cab877d9ccf8582554c98d9#l37

В этой ситуации udev игнорирует действия вида GROUP="<name>" -- ему же запрещено превращать символьное имя в gid. Игнорирует настолько, что получается, что такого действия (action) в строке как бы нет:

http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=blob;f=src/udev/udev-rules.c;h=1642f105354674746b899f9072332d2ddbb49391#l889

При этом есть правила, которые никаких действий кроме GROUP не содержат. Например:

KERNEL=="parport[0-9]*", GROUP="lp"
SUBSYSTEM=="printer", KERNEL=="lp*", GROUP="lp"
SUBSYSTEM=="ppdev", GROUP="lp"
KERNEL=="lp[0-9]*", GROUP="lp"
KERNEL=="irlpt[0-9]*", GROUP="lp"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp"

Получается, что у udev есть правило, которое может с чем-то совпасть, но ничего не делает. Начиная, похоже, с коммита 25de7aa7b90c23d33ea50ada1e50c5834a414237 такая ситуация превратилась из log_notice в log_token_warning.

На x86_64 на Сизифе это тоже происходит, но всё происходит немного быстрее, поэтому большая часть таких сообщений попадает в:

[    2.414871] printk: udevd: 86 output lines suppressed due to ratelimiting

так в чем ошибка? я не понял.

(В ответ на комментарий №3)
> так в чем ошибка? я не понял.

В том, что пользователь видит кучу каких-то ошибок. Хотелось бы, чтобы они не выводились на экран, раз они не ошибки.

это не ошибки, а ворнинги.

Проблема не в ворнингах, а в их количестве, которое валится на пользователя при загрузке. Причё

Сорри, случайно нажал enter.


> Причё

Причём не в логи, а на экран. Если это не проблема, то и не надо об этом пользователя так рьяно оповещать.

А ему можно опустить log level, вызывая из initrd?

(В ответ на комментарий №8)
> А ему можно опустить log level, вызывая из initrd?

man udevd:

Parameters starting with "rd." will be read when systemd-udevd is used in an initrd.

udev.log_priority=, rd.udev.log_priority=
 Set the log level.


Так же можно положить в /etc/udev/udev.conf
udev_log=err

(In reply to Ivan A. Melnikov from comment #1)
> make-initrd запускает udev с параметром  --resolve-names=never:
Так вот оно что! А я эти строки из старого make-initrd брал:
http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=blob;f=udev.c;h=0c211a9956d15a7fbbe52a18ed77493be7c1c707;hb=095e17ab91a18021753ac82142fd9c2100a6bc78#l89

Тогда поправить минутное дело (случайно наткнулся на этот баг)...

В современном make-initrd:
udevadm control --reload >/dev/null 2>&1 ||:

В пропагатор было перенесено из make-initrd 0.8 сразу с исправлением:
udevadm control --reload-rules

Согласно тогдашним манам это было правильней. Возможно я допустил ошибку в функции spawn_silent(), иначе этому сложно найти объяснение. :-)

В современном make-initrd udev не напрямую запускается, а через скриптик udevd
$ cat /lib/initrd/udevd 
#!/bin/bash -efu

exec udevd --debug "$@" >/var/log/udevd.log 2>&1

Можно его вызывать вместо /sbin/udevd:
diff --git a/udev.c b/udev.c
index 0c211a9..466733e 100644
--- a/udev.c
+++ b/udev.c
@@ -87,7 +87,7 @@ static void spawn_silent(char * const command[])
 void udev_start(void)
 {
        /* See make-initrd v0.8.x @ /data/lib/initrd/modules/050-udev for more details */
-       static char* const udevd[]    = {"/sbin/udevd",   "udevd",   "--resolve-names=never", NULL};
+       static char* const udevd[]    = {"/lib/initrd/udevd",   "udevd",   "--resolve-names=never", NULL};

Пытаюсь установить на пк 10 kde, вылетают такие ошибки и все намертво виснет, в биосе уже кучу всего перепробовал, смотрел видео как настроить мать на хакинтош и тд, ничего не помогает

Created attachment 14456 [details]
Скрин

(In reply to Parajiva from comment #13)
> Пытаюсь установить на пк 10 kde, вылетают такие ошибки и все намертво виснет

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

Эта же флешка, на другом пк прекрасно ставит линукс, на новом пк нет, биос обновил на последнюю версию и при выборе установка или лайв режим выходят данные сообщения, скрин приложил. Вы не знаете как решить проблему?

(In reply to Parajiva from comment #16)
> Эта же флешка, на другом пк прекрасно ставит линукс, на новом пк нет, биос
> обновил на последнюю версию и при выборе установка или лайв режим выходят
> данные сообщения, скрин приложил.

Такие сообщение выводятся независимо от того, успешно проходит загрузка или нет; просто когда всё работает, загрузка идёт дальше и этих сообщений не видно. Связывать проблему загрузки и эти сообщения скорее всего неверно.

> Вы не знаете как решить проблему?

По этому скрину я не могу опрделить причину проблемы. Это могут быть проблемы с ядром (слишком старое ядро/слишком новое железо), проблемы с железом (глючное), проблемы с initrd (чего-то специфичного не хватает), и другие. Я бы предложил загрузиться с какой-нибудь live регулярки чтобы проверить, что, например, на новом ядре загрузка проходит дальше.

Но я тут не специалист и это оффтопик в этом обсуждении.

Created attachment 14546 [details]
udev.c: redirect udev messages to /var/log/udevd.log

(Ответ для Антон Мидюков на комментарий #12)
> В современном make-initrd udev не напрямую запускается, а через скриптик
> udevd
Приложил патч с очередной попыткой исправить spawn_silent(). Хотя не сомневаюсь, что и предыдущие варианты должны были всё убрать с экрана. Если сообщения снова не исчезнут, думаю проблема в другом:

(Ответ для Ivan A. Melnikov на комментарий #2)
> На x86_64 на Сизифе это тоже происходит, но всё происходит немного быстрее,
> поэтому большая часть таких сообщений попадает в:
> 
> [    2.414871] printk: udevd: 86 output lines suppressed due to ratelimiting
Возможно, на экране мы видим не stdout/stderr от udevd, а вывод сообщений ядра, попадающие на эту консоль иным способом. Тогда в самом начале может помочь что-то вроде:

mesg n или dmesg --console-off

Что думаете об этом?

(Ответ для Leonid Krivoshein на комментарий #19)
> mesg n или dmesg --console-off
Стоит проверить с таском #330240

(Ответ для Leonid Krivoshein на комментарий #20)
> (Ответ для Leonid Krivoshein на комментарий #19)
> > mesg n или dmesg --console-off
> Стоит проверить с таском #330240

Не помогло. Прочитай ещё раз 12 комментарий.(Ответ для Leonid Krivoshein на комментарий #20)
> (Ответ для Leonid Krivoshein на комментарий #19)
> > mesg n или dmesg --console-off
> Стоит проверить с таском #330240

Не стоило. А вот:
https://git.altlinux.org/tasks/330336/

проблему чинит. Сообщения в /var/log/udevd.log
Спасибо. Жду в Сизифе.

(Ответ для Антон Мидюков на комментарий #21)
> Не помогло. Прочитай ещё раз 12 комментарий.
Там говорится, что помогает перенаправление в лог через скрипт-обёртку, но и раньше в коде было перенаправление, только в /dev/null. И это противоречит данной фактологии из комментария 2:

[    2.414871] printk: udevd: 86 output lines suppressed due to ratelimiting

udevd использует ядерный printk для отправки сообщений в буфер ядра (в dmesg). По крайней мере, это происходит в каких-то случаях, в них может и второе задание помочь.

(Ответ для Антон Мидюков на комментарий #21)
> Не стоило. А вот: https://git.altlinux.org/tasks/330336/
> проблему чинит. Сообщения в /var/log/udevd.log
> Спасибо. Жду в Сизифе.
Нет, братцы, это мы уже проходили -- если забивается рамдиск, propagator становится колом; достигнуть такого несложно, например, большим кол-вом дисков (подробности письмом).

Если вести логи stage1, то исключительно на отдельную tmpfs с игнорированием ошибок записи.

Ну и спам бы удалять/чинить, а не заметать под коврик.

(Ответ для Alexey Shabalin на комментарий #9)
> Так же можно положить в /etc/udev/udev.conf
> udev_log=err

Кто-нить проверял с тех пор?

(Ответ для Michael Shigorin на комментарий #23)
> (Ответ для Alexey Shabalin на комментарий #9)
> > Так же можно положить в /etc/udev/udev.conf
> > udev_log=err
> 
> Кто-нить проверял с тех пор?

В kernel cmdline можно добавить udev.log_level=err и тогда всё будет хорошо.
Спасибо за вразумление. Исправлю в mkimage-profiles так:
diff --git a/features.in/stage2/config.mk b/features.in/stage2/config.mk
index c310fbf75f..9f161cd80c 100644
--- a/features.in/stage2/config.mk
+++ b/features.in/stage2/config.mk
@@ -5,6 +5,7 @@ use/stage2:: sub/stage1
        @$(call add,STAGE1_MODLISTS,$$(FEATURES))
        @$(call xport,STAGE1_PACKAGES)
        @$(call xport,STAGE1_KCONFIG)
+       @$(call add,STAGE2_BOOTARGS,udev.log_level=err)
 
 ifneq (,$(filter-out e2k%,$(ARCH)))
 ifeq (sisyphus,$(BRANCH))

(Ответ для Michael Shigorin на комментарий #23)
> если забивается рамдиск, propagator становится колом; достигнуть такого
> несложно, например, большим кол-вом дисков
В отличии от tmpfs, размер initramfs ограничен только реальным размером ОЗУ. Скорее проблема была в том, что логи записывались на tmpfs или devtmfs размером 8Мб (например, в /dev/.initramfs/). При нынешних объёмах ОЗУ на машинах с дясятками дисков главное правильно выбирать место для записи логов.

> Если вести логи stage1, то исключительно на отдельную tmpfs с игнорированием
> ошибок записи.
Как раз наоборт. Игнорировать ошибки записи в журнал тем более нельзя.

> Ну и спам бы удалять/чинить, а не заметать под коврик.
СПАМ удалять, остальное логировать. Изучил, как это делает загрузка с propagator. doklog() из init.c копирует в цикле 1Кб из /dev/kmsg в /dev/tty4, сообщения syslog, идущие в /dev/log, никуда не попадают, хотя по задумке их тоже хотели отправлять на ту же отладочную консоль. Если во внешних скриптах что-то перенаправляется в файлы, их размер ничем не ограничивается, но это уже не вина пропагатора. По дефолту udevd выводит в stdout/stderr при включенной отладке, в большинстве случаев вывод реализован через syslog или запись в /dev/kmsg.

(Ответ для Антон Мидюков на комментарий #24)
> В kernel cmdline можно добавить udev.log_level=err и тогда всё будет хорошо.
Значение почти сразу перебивается propagator на info. Кроме того, для некоторых целей может потребоваться уровень debug. Так что ищем решение, которе будет безопасным и красивым в 10.2 до окончания поддержки пропагатора. :-)

(Ответ для Leonid Krivoshein на комментарий #25)
> (Ответ для Антон Мидюков на комментарий #24)
> > В kernel cmdline можно добавить udev.log_level=err и тогда всё будет хорошо.
> Значение почти сразу перебивается propagator на info. Кроме того, для
> некоторых целей может потребоваться уровень debug. Так что ищем решение,
> которе будет безопасным и красивым в 10.2 до окончания поддержки
> пропагатора. :-)

Не прибивается. На экране лишь сообщение
Failed to send request to set log level: No such file or directory

По факту сейчас уровень логов udev меняется через параметр udev.log_level. Мне этот способ кажется наиболее удобным. Подключился по serial console с параметром udev.log_level=debug, и вот он лог udev в текстовом терминале.
Поэтому предлагаю убрать в propagator изменение уровня логов. info и так дефолт у udev. Какую-то бесполезную работу он пытается делать сейчас.

(Ответ для Антон Мидюков на комментарий #26)
> По факту сейчас уровень логов udev меняется через параметр udev.log_level.
> Мне этот способ кажется наиболее удобным. Подключился по serial console с
> параметром udev.log_level=debug, и вот он лог udev в текстовом терминале.
> Поэтому предлагаю убрать в propagator изменение уровня логов. info и так
> дефолт у udev. Какую-то бесполезную работу он пытается делать сейчас.
Убрал и вернул redirect в /dev/null: #330537.

Данную ошибку это не починит, но всё вкупе, включая #330240, должно помочь...

(Ответ для Leonid Krivoshein на комментарий #27)
> (Ответ для Антон Мидюков на комментарий #26)
> > По факту сейчас уровень логов udev меняется через параметр udev.log_level.
> > Мне этот способ кажется наиболее удобным. Подключился по serial console с
> > параметром udev.log_level=debug, и вот он лог udev в текстовом терминале.
> > Поэтому предлагаю убрать в propagator изменение уровня логов. info и так
> > дефолт у udev. Какую-то бесполезную работу он пытается делать сейчас.
> Убрал и вернул redirect в /dev/null: #330537.
> 
> Данную ошибку это не починит, но всё вкупе, включая #330240, должно помочь...

А мы точно не хотим иметь возможность видеть ошибки?

(Ответ для Антон Мидюков на комментарий #28)
> А мы точно не хотим иметь возможность видеть ошибки?
Об этом баг.)) Варианта всего три:
1) конслоль, это как сейчас в баге
2) журнал на initramfs, но mike@ против, хоть я и не согласен
3) /dev/null, как было изначально, и на что я вернул теперь

(Ответ для Leonid Krivoshein на комментарий #29)
> (Ответ для Антон Мидюков на комментарий #28)
> > А мы точно не хотим иметь возможность видеть ошибки?
> Об этом баг.)) Варианта всего три:
> 1) конслоль, это как сейчас в баге
> 2) журнал на initramfs, но mike@ против, хоть я и не согласен
> 3) /dev/null, как было изначально, и на что я вернул теперь

4) Консоль, но управлять через udev.log_level в kernel cmdline

(Ответ для Антон Мидюков на комментарий #30)
> 4) Консоль, но управлять через udev.log_level в kernel cmdline
Могу собрать и такой вариант. Нужно?

(Ответ для Leonid Krivoshein на комментарий #31)
> (Ответ для Антон Мидюков на комментарий #30)
> > 4) Консоль, но управлять через udev.log_level в kernel cmdline
> Могу собрать и такой вариант. Нужно?
#330551

mkimage-profiles-1.5.12-alt1 -> sisyphus:

 Fri Sep 29 2023 Anton Midyukov <antohami@altlinux> 1.5.12-alt1
 - pkgpriorities: fix clash 50-pkgpriorities.mk,
   fix usage for main subprofile
 - branding: add release to use/branding
 - stage2: add STAGE2_BOOTARGS=udev.log_level=err (ALT bug 37201)
 - build.mk: replace obsoleted GREP_COLOR with GREP_COLORS
 - x11: install radeon/amdgpu drivers on loongarch64 (thx @asheplyakov)
 - grub: do make a graphical boot menu on LoongArch (thx @asheplyakov)
 - live.mk: add use/stage2/kms to grub-net-install
 - mixin.mk: add power-profiles-daemon (ALT bug 47679)
 - latest commit for alt-server server (thx @jqt4)
 - latest commits for alt-education (thx @cas)
 - spec: don't build documentation on LoongArch (thx @asheplyakov)

(Ответ для Leonid Krivoshein на комментарий #32)
> (Ответ для Leonid Krivoshein на комментарий #31)
> > (Ответ для Антон Мидюков на комментарий #30)
> > > 4) Консоль, но управлять через udev.log_level в kernel cmdline
> > Могу собрать и такой вариант. Нужно?
> #330551

В m-p исправил. Дело за propagator.

(Ответ для Антон Мидюков на комментарий #24)
> > > Так же можно положить в /etc/udev/udev.conf
> > > udev_log=err
> > Кто-нить проверял с тех пор?
> В kernel cmdline можно добавить udev.log_level=err и тогда всё будет хорошо.
> Спасибо за вразумление. Исправлю в mkimage-profiles так:
> +       @$(call add,STAGE2_BOOTARGS,udev.log_level=err)
Это не cmdline и потому не в m-p: так ты не только замусориваешь cmdline,
но и делаешь это для всех udev, которые туда смотрят; а нам надо только
тому передать, который в initrd.  Соответственно делать надо в make-initrd, propagator или укладыванием в stage1::/etc/udev/udev.conf нужной строчки.

(Ответ для Антон Мидюков на комментарий #26)
> Failed to send request to set log level: No such file or directory
Это тоже (экранный) мусор, которого хотелось бы избежать.

(Ответ для Антон Мидюков на комментарий #34)
> > > > 4) Консоль, но управлять через udev.log_level в kernel cmdline
> > > Могу собрать и такой вариант. Нужно?
> > #330551
> В m-p исправил. Дело за propagator.
Попробуй, пожалуйста, _вместо_ 1c38381c109c8f2b11794ce91921eb6f3e142419
сделать что-то такое (в этом наброске недостаёт указания make-initrd
забрать ещё и созданный файлик, у меня он в initrd.img _не_ попал):

---
#!/bin/sh
# silence useless udev log spam
# see http://bugzilla.altlinux.org/37201 for discussion

dir=usr/share/make-initrd/data/etc/udev

cd .work &&
mkdir -p $dir &&
echo "udev_log=err" >> $dir/udev.conf
:
--- features.in/kernel/stage1/scripts.d/50-silent-udev.sh 

По-хорошему это надо делать в самом make-initrd, чтобы не зависело от того,
из чего конфигурируется такая stage1 (т.е. в m-p это заведомые хаки, лезущие "через голову" конкретно применяемого генератора initrd -- shaba@ где-то применял dracut, например).

Хостовый udev.conf для initrd make-initrd не подбирает, судя по
отсутствию упоминаний (я было думал его и сформировать).

Исправил добавлением конфига /etc/udev/udev.conf в make-initrd-propagator:
[#332241] DONE (try 2) make-initrd-propagator.git=0.50-alt1

В m-p коммиты откатил.

Для p10:
[#332261] p10 EPERM make-initrd-propagator.git=0.50-alt1

(Ответ для Michael Shigorin на комментарий #35)
> (Ответ для Антон Мидюков на комментарий #26)
> > Failed to send request to set log level: No such file or directory
> Это тоже (экранный) мусор, которого хотелось бы избежать.
Как раз с этим борьба в пропагаторе. Исправляется таском #330551.

Он же решает озвученную проблему:
(Ответ для Michael Shigorin на комментарий #23)
> Ну и спам бы удалять/чинить, а не заметать под коврик.
Всё жду апрува...

mkimage-profiles-1.5.13-alt1 -> p10:

 Fri Oct 27 2023 Anton Midyukov <antohami@altlinux> 1.5.13-alt1
 - remove lilo support
 - image.in/Makefile: fix show image size
 - oem: do not set English language by default
 - services: Add (un)mask systemd units (thx @jqt4)
 - grub: add variable DISABLE_LANG_MENU
 - x11-autostart: enable graphical.target
 - oem: fix enabled oem.target
 - x11-autostart: do not require use/x11
 - Revert "initrd-propagator: add {STAGE2,RESCUE}_BOOTARGS=udev.log_level=err"
 - l10n: set KEYMAP in vconsole.conf if exist
 - initrd-bootchain: exclude initrd feature kbd
 - live-install: remove use/live-install/vnc
 - live-install: add use/live-install-pkg
 - oem: add systemd.unit=setup.target to kernel cmdline
 - alt-education: sync with ALT Education 10.2 (thx @cas)
 - slinux: sync with Simply Linux 10.2 (thx @sem)
 - alt-server: add latest commits (thx @jqt4)
 Fri Sep 29 2023 Anton Midyukov <antohami@altlinux> 1.5.12-alt1
 - pkgpriorities: fix clash 50-pkgpriorities.mk,
   fix usage for main subprofile
 - branding: add release to use/branding
 - stage2: add STAGE2_BOOTARGS=udev.log_level=err (ALT bug 37201)
 - build.mk: replace obsoleted GREP_COLOR with GREP_COLORS
 - x11: install radeon/amdgpu drivers on loongarch64 (thx @asheplyakov)
 - grub: do make a graphical boot menu on LoongArch (thx @asheplyakov)
 - live.mk: add use/stage2/kms to grub-net-install
 - mixin.mk: add power-profiles-daemon (ALT bug 47679)
 - latest commit for alt-server server (thx @jqt4)
 - latest commits for alt-education (thx @cas)
 - spec: don't build documentation on LoongArch (thx @asheplyakov)

Копирование mkimage-profiles в p10 привело к закрытию бага. Переоткрываю.

Так все 10.2/11.0 будут идти с этим ужасом при загрузке.

Хотел ещё один баг исправить, а смысл, если #330551 всё ещё на EPERM.

(Ответ для Leonid Krivoshein на комментарий #40)
> Так все 10.2/11.0 будут идти с этим ужасом при загрузке.
> 
> Хотел ещё один баг исправить, а смысл, если #330551 всё ещё на EPERM.

https://git.altlinux.org/tasks/330551/gears/100/git?p=git;a=commit;h=b498b553504ec02b3a72bc91afb6d5e8dcf0104c

из этого commit message я вообще не понял зачем ты это делаешь.

(Ответ для Anton Farygin на комментарий #41)
> из этого commit message я вообще не понял зачем ты это делаешь.
Это и так слишком долго и сложно объяснять, особенно на каждой тестовой сборке. Конечно, можно написать because mike@ says "Ну и спам бы удалять/чинить, а не заметать под коврик." :-) Есть же ссылка на баг в следующем коммите.

Мы возвращаем ситуацию с вызовом spawn() к 2018 году до этих двух изменений:

https://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=08aefa7dde7ad0ae4821af4246ba1eda3a86167a
https://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=70bd62ff84fce8a4e9aad678564c062061569210

Когда ещё был старый systemd, новая логика со всеми вызовами, вынесенная в отдельный исходник udev.c, была перенесена из ещё старого рантайма make-initrd, у которого не было проблем с udev, аналогичных тем, что были тогда в пропагаторе. И конкретно данный вызов "заметал весь вывод под коврик". Изначально же его просто не существовало, был просто spawn().

Вообще вот: https://bugzilla.altlinux.org/show_bug.cgi?id=37201#c37 , теперь управление уровнем журналирования перенесено в m-p.

(Ответ для Leonid Krivoshein на комментарий #42)
> Вообще вот: https://bugzilla.altlinux.org/show_bug.cgi?id=37201#c37 , теперь
> управление уровнем журналирования перенесено в m-p.

Уже нет. Сделано в make-initrd-propagator:
20 октября 2023 г. Anton Midyukov 0.50-alt1
- rules.mk: add udev_log=err to udev.conf

Лёня, я написал про commit message не для того, что бы ты мне объяснил, а что бы поправил commit message.
https://initialcommit.com/blog/git-commit-messages-best-practices

(Ответ для Anton Farygin на комментарий #44)
> Лёня, я написал про commit message не для того, что бы ты мне объяснил, а
> что бы поправил commit message.
Понимаю, просто все сборки были тестовые, чего только не пробовали. Сказал бы сразу -- у нас уже пара дистрибутивов вышла бы с этими улучшениями. В новой сборке поменял только сообщение и дату, код не трогал: #334825.

Ну тут всё просто - я увидел что мне непонятно происходящее и оставил другим изучать подробности.

propagator-20231121-alt1 -> sisyphus:

 Tue Nov 21 2023 Leonid Krivoshein <klark@altlinux> 20231121-alt1
 - improvements to logging during boot loading (closes #37201)

(Ответ для Michael Shigorin на комментарий #23)
> Ну и спам бы удалять/чинить, а не заметать под коврик.
Благодаря этому обнаружили ещё один баг в старом коде. У сообщения, проскакивающего очень быстро, которое antohami@ смог поймать только на серийной консоли перед появлением синего окна пропагатора, очевидно log priority как раз err, что теперь задаётся в конфиге udev. Так что оно не просто проскакивает, а ещё и красное. :-)