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

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

[Leonid Krivoshein]

On 2/27/24 19:17, Leonid Krivoshein wrote:
> [...] может, стоит проверять все udev правила при упаковке на 
> сборочнице, чтобы исключить такие сюрпризы? Можно ли (и насколько 
> сложно) туда будет приделать твой валидатор?

Ещё вариант: изменить уровень с ошибки на предупреждение. Ведь даже 
systemd-udevd как-то перемалывает такие правила с кучей ругани в 
журнале, но не отказывается загружать систему. Либо сделать это 
зависимым от ключика. Например, из инсталлятора make-initrd всегда 
запускать с ключом --force.

> Что ты об этом думаешь?

-- 
WBR, Leonid Krivoshein.

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

[Alexey Gladkov]

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.

Запускать проверку правил важно и нужно. Правила с ошибками не
исполняются, какая-то ругань про ошибки попадает в лог udev, но кто это
читает? В итоге правило частично или полностью не работает.

Я специально положил свой парсер в /usr/sbin на случай если она кому-то
ещё понадобиться. В остальном выбор за вами каким валидатором
пользоваться.

-- 
Rgrds, legion

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

[Leonid Krivoshein]

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 
, т.е. на текущем Сизифе именно этой ошибки случиться не может, но 
потенциально может произойти что-то аналогично.


> Запускать проверку правил важно и нужно.

Только не во время инсталляции. Поэтому стоит подумать о ключике --force 
не только для udev-rules, а для всех потенциальных точек отказа. Иначе 
получится как в ситуации микрокодом новых процессоров AMD после выпуска 
10.0, когда уже поздно пить Боржоми. :-)


> Правила с ошибками не
> исполняются, какая-то ругань про ошибки попадает в лог udev, но кто это
> читает? В итоге правило частично или полностью не работает.

Полностью согласен.


> Я специально положил свой парсер в /usr/sbin на случай если она кому-то
> ещё понадобиться. В остальном выбор за вами каким валидатором
> пользоваться.

-- 
WBR, Leonid Krivoshein.

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

[Alexey Gladkov]

On Tue, Feb 27, 2024 at 07:35:05PM +0300, Leonid Krivoshein wrote:
> 
> On 2/27/24 19:17, Leonid Krivoshein wrote:
> > [...] может, стоит проверять все udev правила при упаковке на 
> > сборочнице, чтобы исключить такие сюрпризы? Можно ли (и насколько 
> > сложно) туда будет приделать твой валидатор?
> 
> Ещё вариант: изменить уровень с ошибки на предупреждение. Ведь даже 
> systemd-udevd как-то перемалывает такие правила с кучей ругани в 
> журнале, но не отказывается загружать систему.

Он ругается и не выполняет это правило. Это не как-то, а вообще никак,
если тебе важно именно это правило.

udev поступает так потому что у него правила из всех пакетов для всей
системы. Там у него есть жизненно необходимые правила и опциональные, те
которые понадобятся лишь для какой-то периферии. Если откажет usb-camera,
то это печально, но не смертельно, ведь до загрузки рута мы уже как-то
добрались.

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

> Либо сделать это зависимым от ключика. Например, из инсталлятора
> make-initrd всегда запускать с ключом --force.

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

Предупреждения не имеют смысла. На них никто не смотрит.

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

Так что нет. Я не считаю, что так или иначе игнорировать эти проблемы
не допустимо.

-- 
Rgrds, legion

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

[Alexey Gladkov]

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 внутри него. ))

Я очень хочу написать что-нибудь язвительное про тестирование и
сопровождение пакетов, но не буду.

-- 
Rgrds, legion

Re: [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.

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

[Alexey Gladkov]

On Wed, Feb 28, 2024 at 01:23:57AM +0300, Leonid Krivoshein wrote:
> >>> Запускать проверку правил важно и нужно.
> >> Только не во время инсталляции. Поэтому стоит подумать о ключике --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, и проверка на сборочнице в данном 
> случае -- наиболее безопасные решения.

В сборочнице.

-- 
Rgrds, legion