Make-initrd development discussion
 help / color / mirror / Atom feed
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.



  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