[make-initrd] put-udev-rules и p11

[Leonid Krivoshein]

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.