From: Leonid Krivoshein <klark.devel@gmail.com>
To: make-initrd@lists.altlinux.org
Subject: Re: [make-initrd] put-udev-rules и p11
Date: Wed, 28 Feb 2024 01:23:57 +0300
Message-ID: <c55a989f-5aea-46e5-b417-d4bffaae0b77@gmail.com> (raw)
In-Reply-To: <Zd4xJkShG5TujODa@example.org>
On 2/27/24 21:59, Alexey Gladkov wrote:
> On Tue, Feb 27, 2024 at 08:17:52PM +0300, Leonid Krivoshein wrote:
>> On 2/27/24 19:44, Alexey Gladkov wrote:
>>> On Tue, Feb 27, 2024 at 07:17:56PM +0300, Leonid Krivoshein wrote:
>>>> Алексей, привет!
>>>>
>>>>
>>>> Накануне p11 словили потенциальную граблю -- см. скриншот. Детали здесь
>>>> точно не важны. В make-initrd появился чудесный строгий валидатор udev
>>>> правил. Теперь, если в каком-то другом пакете пакуются правила с
>>>> ошибками, может быть не только ругань, но и отказ собирать initrd. В
>>>> случае инсталлятора 11.x это может означать, что в каких-то
>>>> конфигурациях мы можем ничего не установить, но об ошибках в правилах
>>>> udev узнаем только пост-фактум из логов.
>>>>
>>>> Тем не менее, проверка нужная. Но, может, стоит проверять все udev
>>>> правила при упаковке на сборочнице, чтобы исключить такие сюрпризы?
>>>> Можно ли (и насколько сложно) туда будет приделать твой валидатор? Что
>>>> ты об этом думаешь?
>>> По мотивам этого валидатора в systemd 254 был добавлен: udevadm verify. Он
>>> делает ещё больше проверок т.к. он использует тот же парсер.
>>>
>>> Свою утилиту я писал глядя на правила в пакетах sisyphus и глядя в парсер
>>> udev.
>> Понятно. Если говорить о деталях, то в данном случае это была очередная
>> попытка собрать апстримную версию в p10 всё на том же стенде с
>> multipath, т.е. с более старой пакетной базой, где ещё не было данного
>> коммита:
>> https://git.altlinux.org/tasks/341515/gears/100/git?p=git;a=commitdiff;h=57ee6f941a4f3ea68bba67e018cf10bd954144ac
>> , т.е. на текущем Сизифе именно этой ошибки случиться не может, но
>> потенциально может произойти что-то аналогично.
> Я лишь могу посоветовать вам внимательнее следить за тем, что вы
> бэкпортируете в ваши стабильные бранчи.
>
> Например, утилита udev-rules появилась весной 2023, а говоришь ты про неё
> сейчас. Кстати, исправление multipath-tools, о котором ты говоришь
> появилось также в мае 2023.
>
>>> Запускать проверку правил важно и нужно.
>> Только не во время инсталляции. Поэтому стоит подумать о ключике --force
>> не только для udev-rules, а для всех потенциальных точек отказа. Иначе
>> получится как в ситуации микрокодом новых процессоров AMD после выпуска
>> 10.0, когда уже поздно пить Боржоми. :-)
> Нет. Поздно будет, когда проблема с правилами всплывёт во время загрузки
> системы. Очень трудно исправлять initramfs внутри него. ))
>
> Я очень хочу написать что-нибудь язвительное про тестирование и
> сопровождение пакетов, но не буду.
Понимаю всю твою аргументацию, тем не менее, в данной ситуации имеем
следующее: со старой версией multipath-tools без вышеупомянутого коммита
система с "ошибочным" правилом udev грузится. Вот что об этом пишет
коммитер:
Note (mwilck): technically, this udev rule was parsed and executed by
udev correctly, and this is unlikely to change. But the missing comma
didn't comply with the udev(7) man page.
Так что получается, что парсер придрался к запятой, без которой всё
равно всё работает и даже обещается, что так будет и дальше. В общем,
мне кажется, и --force в make-initrd, и проверка на сборочнице в данном
случае -- наиболее безопасные решения.
--
WBR, Leonid Krivoshein.
next prev parent reply other threads:[~2024-02-27 22:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 16:35 ` Leonid Krivoshein
2024-02-27 18:44 ` Alexey Gladkov
2024-02-27 16:44 ` Alexey Gladkov
2024-02-27 17:17 ` Leonid Krivoshein
2024-02-27 18:59 ` Alexey Gladkov
2024-02-27 22:23 ` Leonid Krivoshein [this message]
2024-02-27 22:43 ` Alexey Gladkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c55a989f-5aea-46e5-b417-d4bffaae0b77@gmail.com \
--to=klark.devel@gmail.com \
--cc=make-initrd@lists.altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Make-initrd development discussion
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \
make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com
public-inbox-index make-initrd
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.make-initrd
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git