[sisyphus] udev-197

[sisyphus] udev-197

[sbolshakov]

После обновления на udev-197-alt1 у меня сложилось впечатление,
что группы, которыми раньше определялся доступ к некоторым
классам устройств, больше не выставляются.
Бишь, раньше на /dev/snd/* ставилась audio, на камеры video
и т.п. -- но не сейчас.
Как результат, без systemd жить уже не получится.
Это так ?

-- 

Re: [sisyphus] udev-197

[sbolshakov]

>>>>> "sbolshakov" == sbolshakov  <sbolshakov-u2l5PoMzF> writes:

 > После обновления на udev-197-alt1 у меня сложилось впечатление,
 > что группы, которыми раньше определялся доступ к некоторым
 > классам устройств, больше не выставляются.
 > Бишь, раньше на /dev/snd/* ставилась audio, на камеры video
 > и т.п. -- но не сейчас.
 > Как результат, без systemd жить уже не получится.
 > Это так ?

Спрашивали -- отвечаем.
Да, это так для устройств, поддержка которых содержится не в модулях,
а в ядре -- что редко в x86 и повсеместно на arm, см. коммит
http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1

-- 

Re: [sisyphus] udev-197

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Thu, Jan 24, 2013 at 10:33:27PM +0400, sbolshakov@altlinux.ru wrote:
> >>>>> "sbolshakov" == sbolshakov  <sbolshakov-u2l5PoMzF> writes:
> 
>  > После обновления на udev-197-alt1 у меня сложилось впечатление,
>  > что группы, которыми раньше определялся доступ к некоторым
>  > классам устройств, больше не выставляются.
>  > Бишь, раньше на /dev/snd/* ставилась audio, на камеры video
>  > и т.п. -- но не сейчас.
>  > Как результат, без systemd жить уже не получится.
>  > Это так ?
> 
> Спрашивали -- отвечаем.
> Да, это так для устройств, поддержка которых содержится не в модулях,
> а в ядре -- что редко в x86 и повсеместно на arm, см. коммит
> http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1

И как предлагается теперь выставлять правильные права на файлы устройств?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] udev-197

[Sergey Bolshakov]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

>>>>> "Dmitry" == Dmitry V Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On Thu, Jan 24, 2013 at 10:33:27PM +0400, sbolshakov-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org wrote:
 >> >>>>> "sbolshakov" == sbolshakov  <sbolshakov-u2l5PoMzF> writes:
 >> 
 >> > После обновления на udev-197-alt1 у меня сложилось впечатление,
 >> > что группы, которыми раньше определялся доступ к некоторым
 >> > классам устройств, больше не выставляются.
 >> > Бишь, раньше на /dev/snd/* ставилась audio, на камеры video
 >> > и т.п. -- но не сейчас.
 >> > Как результат, без systemd жить уже не получится.
 >> > Это так ?
 >> 
 >> Спрашивали -- отвечаем.
 >> Да, это так для устройств, поддержка которых содержится не в модулях,
 >> а в ядре -- что редко в x86 и повсеместно на arm, см. коммит
 >> http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1

 > И как предлагается теперь выставлять правильные права на файлы устройств?

Не знаю. Я сделал так:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: udevd.diff --]
[-- Type: text/x-patch, Size: 464 bytes --]

--- /etc/rc.d/init.d/udevd~	2013-01-24 22:16:08.348977338 +0400
+++ /etc/rc.d/init.d/udevd	2013-01-24 22:21:31.486708131 +0400
@@ -196,7 +193,7 @@
 		RETVAL=$[$RETVAL+$?]
 		[ "$RETVAL" == "0" ] && echo "" >/proc/sys/kernel/hotplug
 		/sbin/udevadm control --property="STARTUP=1"
-		/sbin/udevadm trigger
+		/sbin/udevadm trigger --action=add
 		action "Populating /dev:" /sbin/udevadm settle
 		/sbin/udevadm control --property="STARTUP="
 		RETVAL=$[$RETVAL+$?]

[-- Attachment #3: Type: text/plain, Size: 5 bytes --]


-- 

Re: [sisyphus] udev-197

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

On Fri, Jan 25, 2013 at 02:51:10PM +0400, Sergey Bolshakov wrote:
> >>>>> "Dmitry" == Dmitry V Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
>  > On Thu, Jan 24, 2013 at 10:33:27PM +0400, sbolshakov-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org wrote:
>  >> >>>>> "sbolshakov" == sbolshakov  <sbolshakov-u2l5PoMzF> writes:
[...]
>  >> http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1
> 
>  > И как предлагается теперь выставлять правильные права на файлы устройств?
> 
> Не знаю. Я сделал так:

> --- /etc/rc.d/init.d/udevd~	2013-01-24 22:16:08.348977338 +0400
> +++ /etc/rc.d/init.d/udevd	2013-01-24 22:21:31.486708131 +0400
> @@ -196,7 +193,7 @@
>  		RETVAL=$[$RETVAL+$?]
>  		[ "$RETVAL" == "0" ] && echo "" >/proc/sys/kernel/hotplug
>  		/sbin/udevadm control --property="STARTUP=1"
> -		/sbin/udevadm trigger
> +		/sbin/udevadm trigger --action=add
>  		action "Populating /dev:" /sbin/udevadm settle
>  		/sbin/udevadm control --property="STARTUP="
>  		RETVAL=$[$RETVAL+$?]

И, судя по комментариям из вышеупомянутого коммита, добавление
--action=add - это правильное решение.

Хотя на самом деле в systemd-udev-trigger.service команды более
сложные:

  http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=blob;f=units/systemd-udev-trigger.service.in;h=391f9969306d96a6f993dc20270d5bd641e742d0;hb=0908dd2fd5536cf15d75780980ac2eca37ff800f

Там отдельно два вызова:

  udevadm trigger --type=subsystems --action=add
  udevadm trigger --type=devices --action=add

Причём это было так с самого первого появления этого файла ещё во
время существования udev как отдельного проекта:

  http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commitdiff;h=fc1de713f5b754fb38876b5b797e18f812727f0a#patch3

Хотя ранее эти команды были в udev.service, но и там они впервые
появились именно в таком виде:

  http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commitdiff;h=43fefbf6f1c528947a77643582bcc34cf3538b2d#patch3

См. также:

  http://www.spinics.net/lists/hotplug/msg05105.html
  http://www.spinics.net/lists/hotplug/msg05119.html

Возможно, из-за отсутствия --type=subsystems не работает что-то ещё,
что не так заметно.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] udev-197

[Alexey Shabalin]

26 января 2013 г., 21:12 пользователь Sergey Vlasov  написал:
>>  >> http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1
>>
>>  > И как предлагается теперь выставлять правильные права на файлы устройств?
>>
>> Не знаю. Я сделал так:
>
>> --- /etc/rc.d/init.d/udevd~   2013-01-24 22:16:08.348977338 +0400
>> +++ /etc/rc.d/init.d/udevd    2013-01-24 22:21:31.486708131 +0400
>> @@ -196,7 +193,7 @@
>>               RETVAL=$[$RETVAL+$?]
>>               [ "$RETVAL" == "0" ] && echo "" >/proc/sys/kernel/hotplug
>>               /sbin/udevadm control --property="STARTUP=1"
>> -             /sbin/udevadm trigger
>> +             /sbin/udevadm trigger --action=add
>>               action "Populating /dev:" /sbin/udevadm settle
>>               /sbin/udevadm control --property="STARTUP="
>>               RETVAL=$[$RETVAL+$?]
>
> И, судя по комментариям из вышеупомянутого коммита, добавление
> --action=add - это правильное решение.
>

Я извиняюсь, может чего-то недопонимаю, объясните пожалуйста.
Дело в том, что и из systemd-udev-trigger.service я тоже убрал из
параметров --action=add при вызове udevadm trigger.
Все из-за того, что у нас initrd (сделанный make-initrd) удаляет за
собой базу udev, и после смены корневой фс, базу udev надо заново
наполнить, иначе возникают различные проблемы (я уже описывал их ранее
в рассылке).
Т.е. пока make-initrd не будет копировать базу udev, добавлять
--action=add мне кажется опасным.


--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Gladkov]

28.01.2013 14:27, Alexey Shabalin wrote:
> 26 января 2013 г., 21:12 пользователь Sergey Vlasov  написал:
>>>  >> http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1
>>>
>>>  > И как предлагается теперь выставлять правильные права на файлы устройств?
>>>
>>> Не знаю. Я сделал так:
>>
>>> --- /etc/rc.d/init.d/udevd~   2013-01-24 22:16:08.348977338 +0400
>>> +++ /etc/rc.d/init.d/udevd    2013-01-24 22:21:31.486708131 +0400
>>> @@ -196,7 +193,7 @@
>>>               RETVAL=$[$RETVAL+$?]
>>>               [ "$RETVAL" == "0" ] && echo "" >/proc/sys/kernel/hotplug
>>>               /sbin/udevadm control --property="STARTUP=1"
>>> -             /sbin/udevadm trigger
>>> +             /sbin/udevadm trigger --action=add
>>>               action "Populating /dev:" /sbin/udevadm settle
>>>               /sbin/udevadm control --property="STARTUP="
>>>               RETVAL=$[$RETVAL+$?]
>>
>> И, судя по комментариям из вышеупомянутого коммита, добавление
>> --action=add - это правильное решение.
>>
> 
> Я извиняюсь, может чего-то недопонимаю, объясните пожалуйста.
> Дело в том, что и из systemd-udev-trigger.service я тоже убрал из
> параметров --action=add при вызове udevadm trigger.
> Все из-за того, что у нас initrd (сделанный make-initrd) удаляет за
> собой базу udev, и после смены корневой фс, базу udev надо заново
> наполнить, иначе возникают различные проблемы (я уже описывал их ранее
> в рассылке).
> Т.е. пока make-initrd не будет копировать базу udev, добавлять
> --action=add мне кажется опасным.

make-initrd как раз и формирует базу с нуля с помощью --action=add.
Без этого ключа база будет не полной.

-- 
-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 14:35 пользователь Alexey Gladkov написал:
> 28.01.2013 14:27, Alexey Shabalin wrote:
>> 26 января 2013 г., 21:12 пользователь Sergey Vlasov  написал:
>>>>  >> http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commit;h=48a849ee17fb25e0001bfcc0f28a4aa633d016a1
>>>>
>>>>  > И как предлагается теперь выставлять правильные права на файлы устройств?
>>>>
>>>> Не знаю. Я сделал так:
>>>
>>>> --- /etc/rc.d/init.d/udevd~   2013-01-24 22:16:08.348977338 +0400
>>>> +++ /etc/rc.d/init.d/udevd    2013-01-24 22:21:31.486708131 +0400
>>>> @@ -196,7 +193,7 @@
>>>>               RETVAL=$[$RETVAL+$?]
>>>>               [ "$RETVAL" == "0" ] && echo "" >/proc/sys/kernel/hotplug
>>>>               /sbin/udevadm control --property="STARTUP=1"
>>>> -             /sbin/udevadm trigger
>>>> +             /sbin/udevadm trigger --action=add
>>>>               action "Populating /dev:" /sbin/udevadm settle
>>>>               /sbin/udevadm control --property="STARTUP="
>>>>               RETVAL=$[$RETVAL+$?]
>>>
>>> И, судя по комментариям из вышеупомянутого коммита, добавление
>>> --action=add - это правильное решение.
>>>
>>
>> Я извиняюсь, может чего-то недопонимаю, объясните пожалуйста.
>> Дело в том, что и из systemd-udev-trigger.service я тоже убрал из
>> параметров --action=add при вызове udevadm trigger.
>> Все из-за того, что у нас initrd (сделанный make-initrd) удаляет за
>> собой базу udev, и после смены корневой фс, базу udev надо заново
>> наполнить, иначе возникают различные проблемы (я уже описывал их ранее
>> в рассылке).
>> Т.е. пока make-initrd не будет копировать базу udev, добавлять
>> --action=add мне кажется опасным.
>
> make-initrd как раз и формирует базу с нуля с помощью --action=add.
> Без этого ключа база будет не полной.

Лёшь, посмотри в личной переписке, тема
"start swap on lvm (systemd)"
Я там описывал проблему:

из initrd приезжают диски, информация о которых в udev минимальна. Это
не даёт нормально их подмонтировать средствами systemd+udev.

После загрузки нормальная информация появляется только после
vgchange --refresh

Решением проблемы старта swap на lvm как раз было удалить
"--action=add", что бы база udev заполнялась заново.


Также вот выдержка из  /lib/udev/rules.d/10-dm.rules, где рекомендуют
не удалять udev базу в initrd.

# Normally, we operate on "change" events. But when coldplugging, there's an
# "add" event present. We have to recognize this and do our actions in this
# particular situation, too. Also, we don't want the nodes to be created
# prematurely on "add" events while not coldplugging. We check
# DM_UDEV_PRIMARY_SOURCE_FLAG to see if the device was activated correctly
# before and if not, we ignore the "add" event totally. This way we can support
# udev triggers generating "add" events (e.g. "udevadm trigger --action=add" or
# "echo add > /sys/block/<dm_device>/uevent"). The trigger with "add" event is
# also used at boot to reevaluate udev rules for all existing devices activated
# before (e.g. in initrd). If udev is used in initrd, we require the udev init
# script to not remove the existing udev database so we can reuse the
information
# stored at the time of device activation in the initrd.


--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Gladkov]

28.01.2013 14:58, Alexey Shabalin wrote:
> из initrd приезжают диски, информация о которых в udev минимальна. Это
> не даёт нормально их подмонтировать средствами systemd+udev.

Потому что udev ничего не знает о том, что было в initrd. Для этого в
sysv был перезапуск udev.

> Решением проблемы старта swap на lvm как раз было удалить
> "--action=add", что бы база udev заполнялась заново.

Этот параметр указывает эвенты с каким типом нужно передёрнуть. change
означает, что будут передёрнуты только эвенты с изменениями, а эвенты
с добавлением устройств не пошлются.

Попробуй запустить "udevadm monitor --udev" и посмотри что будет
приходить по "udevadm trigger --action=change" и по "udevadm trigger
--action=add".


> Также вот выдержка из  /lib/udev/rules.d/10-dm.rules, где рекомендуют
> не удалять udev базу в initrd.

Тогда с обновлением udev будет нужно будет обновлять initrd.

-- 
Rgrds, legion


-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 16:25 пользователь Alexey Gladkov написал:
> 28.01.2013 14:58, Alexey Shabalin wrote:
>> из initrd приезжают диски, информация о которых в udev минимальна. Это
>> не даёт нормально их подмонтировать средствами systemd+udev.
>
> Потому что udev ничего не знает о том, что было в initrd. Для этого в
> sysv был перезапуск udev.
>
>> Решением проблемы старта swap на lvm как раз было удалить
>> "--action=add", что бы база udev заполнялась заново.
>
> Этот параметр указывает эвенты с каким типом нужно передёрнуть. change
> означает, что будут передёрнуты только эвенты с изменениями, а эвенты
> с добавлением устройств не пошлются.
>
> Попробуй запустить "udevadm monitor --udev" и посмотри что будет
> приходить по "udevadm trigger --action=change" и по "udevadm trigger
> --action=add".
>
>
>> Также вот выдержка из  /lib/udev/rules.d/10-dm.rules, где рекомендуют
>> не удалять udev базу в initrd.
>
> Тогда с обновлением udev будет нужно будет обновлять initrd.

Не уверен. Если и надо, то только для очень старых версий udev.
Вообще udev определяет версию базы и при необходимости запускает
перестроение её.

--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Gladkov]

28.01.2013 16:43, Alexey Shabalin wrote:
>>> Также вот выдержка из  /lib/udev/rules.d/10-dm.rules, где рекомендуют
>>> не удалять udev базу в initrd.
>>
>> Тогда с обновлением udev будет нужно будет обновлять initrd.
> 
> Не уверен. Если и надо, то только для очень старых версий udev.
> Вообще udev определяет версию базы и при необходимости запускает
> перестроение её.

Он делает лишь одну конвертацию /dev/.udev/db -> /run/udev/data. Есть
ещё изменения внутри самой базы (добавление, изменение формата ...).
Так как в initrd будет старый udev, а в системе он будет постоянно
обновляться, то разрыв между версиями будет постоянно увеличиваться. В
какой-то момент может случиться очень плохое без шансов это исправить
т.к. система будет всегда полагаться на корректную базу udev из initrd.

-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 16:25 пользователь Alexey Gladkov написал:
> 28.01.2013 14:58, Alexey Shabalin wrote:
>> из initrd приезжают диски, информация о которых в udev минимальна. Это
>> не даёт нормально их подмонтировать средствами systemd+udev.
>
> Потому что udev ничего не знает о том, что было в initrd. Для этого в
> sysv был перезапуск udev.

А можно меня ткнуть носом, где этот перезапуск осуществляется в sysv?
И стоит ли делать аналогичное для systemd?


>> Решением проблемы старта swap на lvm как раз было удалить
>> "--action=add", что бы база udev заполнялась заново.
>
> Этот параметр указывает эвенты с каким типом нужно передёрнуть. change
> означает, что будут передёрнуты только эвенты с изменениями, а эвенты
> с добавлением устройств не пошлются.
>
> Попробуй запустить "udevadm monitor --udev" и посмотри что будет
> приходить по "udevadm trigger --action=change" и по "udevadm trigger
> --action=add".
>
>
>> Также вот выдержка из  /lib/udev/rules.d/10-dm.rules, где рекомендуют
>> не удалять udev базу в initrd.
>
> Тогда с обновлением udev будет нужно будет обновлять initrd.
>
> --
> Rgrds, legion
>
>
> --
> Rgrds, legion
>
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus



--
Alexey Shabalin

Re: [sisyphus] udev-197

[Sergei Epiphanov]

On 28 января 2013 16:25 Alexey Gladkov wrote:
> Тогда с обновлением udev будет нужно будет обновлять initrd.

Вот это правильная мысль. Порой ядро обновляется гораздо реже обновлений udev 
(а значит и перестроений initrd по факту обновления ядра гораздо меньше).

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

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] udev-197

[Alexey Gladkov]

28.01.2013 17:29, Sergei Epiphanov wrote:
> On 28 января 2013 16:25 Alexey Gladkov wrote:
>> Тогда с обновлением udev будет нужно будет обновлять initrd.
> 
> Вот это правильная мысль. Порой ядро обновляется гораздо реже обновлений udev 
> (а значит и перестроений initrd по факту обновления ядра гораздо меньше).

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

Сейчас initrd и живая система взаимодействуют через ядро. Но если мы
передаём в живую систему runtime других программ, то мы начинаем
зависеть от них тоже.

Если же мы захотим переносить какие-либо бинарники из initrd в живую
систему, то мы начнём зависеть и от библиотек. Кстати, такая
зависимость может появиться не только в этом случае.

> Кстати, тогда придётся передёргивать initrd у всех имеющихся на машине ядер. И 
> не факт, что новый вариант initrd будет правильным. Предыдущий вариант initrd 
> тоже нужно сохранять, чтобы была возможность загрузки с проверенной версией.

Тогда будет нужен будет logrotate для /boot :)))

-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Gladkov]

28.01.2013 17:24, Alexey Shabalin wrote:
>> Потому что udev ничего не знает о том, что было в initrd. Для этого в
>> sysv был перезапуск udev.
> 
> А можно меня ткнуть носом, где этот перезапуск осуществляется в sysv?

У нас есть запуск udev из rc.sysinit если не попросили этого не делать:

http://git.altlinux.org/people/ldv/packages/startup.git?p=startup.git;a=blob;f=startup/rc.d/rc.sysinit;h=00086e0c0858d92bde4747948f1d06291d2aa41a;hb=d73bee425ea95bbec237cba3b0458eb235578ad0#l116

Далее будет работать /etc/init.d/udevd, который уже приводился в этом
треде.

> И стоит ли делать аналогичное для systemd?

На этот вопрос я ответить не могу. Я ни разу его не запускал и не
знаю, что ему нужно от systemd-udevd и от initrd.

-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Sergei Epiphanov]

On 28 января 2013 17:50 Alexey Gladkov wrote:
> Тогда будет нужен будет logrotate для /boot :)))

Ага, а потом ещё и grub/lilo не забыть: может, придётся добавлять строчки вида 
"ядро zzz с initrd от даты yyy" :)))

Эдак полсистемы уползёт в initrd. :)))

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 18:15 пользователь Alexey Gladkov написал:
> 28.01.2013 17:24, Alexey Shabalin wrote:
>>> Потому что udev ничего не знает о том, что было в initrd. Для этого в
>>> sysv был перезапуск udev.
>>
>> А можно меня ткнуть носом, где этот перезапуск осуществляется в sysv?
>
> У нас есть запуск udev из rc.sysinit если не попросили этого не делать:
>
> http://git.altlinux.org/people/ldv/packages/startup.git?p=startup.git;a=blob;f=startup/rc.d/rc.sysinit;h=00086e0c0858d92bde4747948f1d06291d2aa41a;hb=d73bee425ea95bbec237cba3b0458eb235578ad0#l116
>
> Далее будет работать /etc/init.d/udevd, который уже приводился в этом
> треде.

Так я и прошу показать где происходит перезапуск. Под перезапуском я
понимаю, что первый экземпляр где-то стопится. Пока я вижу только
старт из rc.sysinit и

потом

# Check if udevd is already running
if start-stop-daemon --stop --exec $udevd \
                               --user root --test >/dev/null; then
                        [ -n "$RUN_FROM_SYSINIT" ] || touch "$LOCKFILE"
                        return 0
fi

если udevd уже запущен, то больше не запускается.
Т.е. если он запускается только один раз из rc.sysinit, то добавление
"--action=add" так же поломает наполнение базы udev?

>> И стоит ли делать аналогичное для systemd?
>
> На этот вопрос я ответить не могу. Я ни разу его не запускал и не
> знаю, что ему нужно от systemd-udevd и от initrd.


--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Gladkov]

28.01.2013 19:04, Alexey Shabalin wrote:
> Так я и прошу показать где происходит перезапуск. Под перезапуском я
> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
> старт из rc.sysinit и

Под перезапуском я понимаю, что udev останавливается в initrd и
запускается в системе с чистого листа и наполняет базу заново.

> Т.е. если он запускается только один раз из rc.sysinit, то добавление
> "--action=add" так же поломает наполнение базы udev?

Тут должна быть инициализация базы с нуля. Примерно также делается в
initrd.

-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 19:23 пользователь Alexey Gladkov написал:
> 28.01.2013 19:04, Alexey Shabalin wrote:
>> Так я и прошу показать где происходит перезапуск. Под перезапуском я
>> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
>> старт из rc.sysinit и
>
> Под перезапуском я понимаю, что udev останавливается в initrd и
> запускается в системе с чистого листа и наполняет базу заново.
>
>> Т.е. если он запускается только один раз из rc.sysinit, то добавление
>> "--action=add" так же поломает наполнение базы udev?
>
> Тут должна быть инициализация базы с нуля. Примерно также делается в
> initrd.
Для sysv не страшно, если база пустая, т.к. swapon,  vgchange -a y,
mdadm --assemble --scan и т.п. все равно при любых условиях
запускаются из rc.sysinit  и наполняют базу udev.
Для systemd они ни откуда ни запускаются , полагается только на уже
существующую наполненую базу udev. И если она пустая - то будет облом.

--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 19:37 пользователь Alexey Shabalin написал:
> 28 января 2013 г., 19:23 пользователь Alexey Gladkov написал:
>> 28.01.2013 19:04, Alexey Shabalin wrote:
>>> Так я и прошу показать где происходит перезапуск. Под перезапуском я
>>> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
>>> старт из rc.sysinit и
>>
>> Под перезапуском я понимаю, что udev останавливается в initrd и
>> запускается в системе с чистого листа и наполняет базу заново.
>>
>>> Т.е. если он запускается только один раз из rc.sysinit, то добавление
>>> "--action=add" так же поломает наполнение базы udev?
>>
>> Тут должна быть инициализация базы с нуля. Примерно также делается в
>> initrd.
> Для sysv не страшно, если база пустая, т.к. swapon,  vgchange -a y,
> mdadm --assemble --scan и т.п. все равно при любых условиях
> запускаются из rc.sysinit  и наполняют базу udev.
> Для systemd они ни откуда ни запускаются , полагается только на уже
> существующую наполненую базу udev. И если она пустая - то будет облом.

Кстати, может сделаем такой компромисс - базу udev из initrd будем
копировать, а удалять уже из rc.sysinit ? А для systemd Эту базу можно
не удалять.



--
Alexey Shabalin

Re: [sisyphus] udev-197

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Mon, Jan 28, 2013 at 07:42:27PM +0400, Alexey Shabalin wrote:
> 28 января 2013 г., 19:37 пользователь Alexey Shabalin написал:
> > 28 января 2013 г., 19:23 пользователь Alexey Gladkov написал:
> >> 28.01.2013 19:04, Alexey Shabalin wrote:
> >>> Так я и прошу показать где происходит перезапуск. Под перезапуском я
> >>> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
> >>> старт из rc.sysinit и
> >>
> >> Под перезапуском я понимаю, что udev останавливается в initrd и
> >> запускается в системе с чистого листа и наполняет базу заново.
> >>
> >>> Т.е. если он запускается только один раз из rc.sysinit, то добавление
> >>> "--action=add" так же поломает наполнение базы udev?
> >>
> >> Тут должна быть инициализация базы с нуля. Примерно также делается в
> >> initrd.
> > Для sysv не страшно, если база пустая, т.к. swapon,  vgchange -a y,
> > mdadm --assemble --scan и т.п. все равно при любых условиях
> > запускаются из rc.sysinit  и наполняют базу udev.
> > Для systemd они ни откуда ни запускаются , полагается только на уже
> > существующую наполненую базу udev. И если она пустая - то будет облом.
> 
> Кстати, может сделаем такой компромисс - базу udev из initrd будем
> копировать, а удалять уже из rc.sysinit ? А для systemd Эту базу можно
> не удалять.

Это будет не компромисс, а мина замедленного действия, до первого
нарушения обратной совместимости формата базы udev.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] udev-197

[Alexey Shabalin]

28 января 2013 г., 19:49 пользователь Dmitry V. Levin написал:
> On Mon, Jan 28, 2013 at 07:42:27PM +0400, Alexey Shabalin wrote:
>> 28 января 2013 г., 19:37 пользователь Alexey Shabalin написал:
>> > 28 января 2013 г., 19:23 пользователь Alexey Gladkov написал:
>> >> 28.01.2013 19:04, Alexey Shabalin wrote:
>> >>> Так я и прошу показать где происходит перезапуск. Под перезапуском я
>> >>> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
>> >>> старт из rc.sysinit и
>> >>
>> >> Под перезапуском я понимаю, что udev останавливается в initrd и
>> >> запускается в системе с чистого листа и наполняет базу заново.
>> >>
>> >>> Т.е. если он запускается только один раз из rc.sysinit, то добавление
>> >>> "--action=add" так же поломает наполнение базы udev?
>> >>
>> >> Тут должна быть инициализация базы с нуля. Примерно также делается в
>> >> initrd.
>> > Для sysv не страшно, если база пустая, т.к. swapon,  vgchange -a y,
>> > mdadm --assemble --scan и т.п. все равно при любых условиях
>> > запускаются из rc.sysinit  и наполняют базу udev.
>> > Для systemd они ни откуда ни запускаются , полагается только на уже
>> > существующую наполненую базу udev. И если она пустая - то будет облом.
>>
>> Кстати, может сделаем такой компромисс - базу udev из initrd будем
>> копировать, а удалять уже из rc.sysinit ? А для systemd Эту базу можно
>> не удалять.
>
> Это будет не компромисс, а мина замедленного действия, до первого
> нарушения обратной совместимости формата базы udev.

Тогда давайте копировать базу udev и обновлять initrd при обновлении
udev хотя бы для текущего ядра (не трогая остальные) - у
администратора останется возможность загрузится и если надо вручную
обновить initrd для других ядер.

--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Gladkov]

29.01.2013 13:44, Alexey Shabalin wrote:
> 28 января 2013 г., 19:49 пользователь Dmitry V. Levin написал:
>> On Mon, Jan 28, 2013 at 07:42:27PM +0400, Alexey Shabalin wrote:
>>> 28 января 2013 г., 19:37 пользователь Alexey Shabalin написал:
>>>> 28 января 2013 г., 19:23 пользователь Alexey Gladkov написал:
>>>>> 28.01.2013 19:04, Alexey Shabalin wrote:
>>>>>> Так я и прошу показать где происходит перезапуск. Под перезапуском я
>>>>>> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
>>>>>> старт из rc.sysinit и
>>>>>
>>>>> Под перезапуском я понимаю, что udev останавливается в initrd и
>>>>> запускается в системе с чистого листа и наполняет базу заново.
>>>>>
>>>>>> Т.е. если он запускается только один раз из rc.sysinit, то добавление
>>>>>> "--action=add" так же поломает наполнение базы udev?
>>>>>
>>>>> Тут должна быть инициализация базы с нуля. Примерно также делается в
>>>>> initrd.
>>>> Для sysv не страшно, если база пустая, т.к. swapon,  vgchange -a y,
>>>> mdadm --assemble --scan и т.п. все равно при любых условиях
>>>> запускаются из rc.sysinit  и наполняют базу udev.
>>>> Для systemd они ни откуда ни запускаются , полагается только на уже
>>>> существующую наполненую базу udev. И если она пустая - то будет облом.
>>>
>>> Кстати, может сделаем такой компромисс - базу udev из initrd будем
>>> копировать, а удалять уже из rc.sysinit ? А для systemd Эту базу можно
>>> не удалять.
>>
>> Это будет не компромисс, а мина замедленного действия, до первого
>> нарушения обратной совместимости формата базы udev.
> 
> Тогда давайте копировать базу udev и обновлять initrd при обновлении
> udev хотя бы для текущего ядра (не трогая остальные) - у
> администратора останется возможность загрузится и если надо вручную
> обновить initrd для других ядер.

Представим ситуацию, когда новый initrd не загрузился (такое иногда
бывает) и есть несовместимость баз. Что делать пользователю? Новое
ядро не грузится... и старое тоже не будет грузится.

Таким образом система будет работать, когда всё хорошо и не будет
работать при проблемах. Собственно как и в случае неперегенерации
initrd и копирования баз. Эффект будет одинаковым.

Как один из обходных вариантов можно реализовать cmdline ключ для
управления копированием базы udev в систему, который по умолчанию
будет выставлен в "копировать". Тогда если реализовать аварийный
механизм в системе на случай, когда базы udev нет, то пользователь
сможет(?) загрузиться хоть как-то.

Тут у меня возникают сомнения в возможности реализации аварийного
режима т.к. этот тред и есть следствие того, что systemd не умеет
нормально работать без базы udev. 2shaba@: Можно ли тут что-то сделать ?

-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Shabalin]

29 января 2013 г., 15:38 пользователь Alexey Gladkov написал:
> 29.01.2013 13:44, Alexey Shabalin wrote:
>> 28 января 2013 г., 19:49 пользователь Dmitry V. Levin написал:
>>> On Mon, Jan 28, 2013 at 07:42:27PM +0400, Alexey Shabalin wrote:
>>>> 28 января 2013 г., 19:37 пользователь Alexey Shabalin написал:
>>>>> 28 января 2013 г., 19:23 пользователь Alexey Gladkov написал:
>>>>>> 28.01.2013 19:04, Alexey Shabalin wrote:
>>>>>>> Так я и прошу показать где происходит перезапуск. Под перезапуском я
>>>>>>> понимаю, что первый экземпляр где-то стопится. Пока я вижу только
>>>>>>> старт из rc.sysinit и
>>>>>>
>>>>>> Под перезапуском я понимаю, что udev останавливается в initrd и
>>>>>> запускается в системе с чистого листа и наполняет базу заново.
>>>>>>
>>>>>>> Т.е. если он запускается только один раз из rc.sysinit, то добавление
>>>>>>> "--action=add" так же поломает наполнение базы udev?
>>>>>>
>>>>>> Тут должна быть инициализация базы с нуля. Примерно также делается в
>>>>>> initrd.
>>>>> Для sysv не страшно, если база пустая, т.к. swapon,  vgchange -a y,
>>>>> mdadm --assemble --scan и т.п. все равно при любых условиях
>>>>> запускаются из rc.sysinit  и наполняют базу udev.
>>>>> Для systemd они ни откуда ни запускаются , полагается только на уже
>>>>> существующую наполненую базу udev. И если она пустая - то будет облом.
>>>>
>>>> Кстати, может сделаем такой компромисс - базу udev из initrd будем
>>>> копировать, а удалять уже из rc.sysinit ? А для systemd Эту базу можно
>>>> не удалять.
>>>
>>> Это будет не компромисс, а мина замедленного действия, до первого
>>> нарушения обратной совместимости формата базы udev.
>>
>> Тогда давайте копировать базу udev и обновлять initrd при обновлении
>> udev хотя бы для текущего ядра (не трогая остальные) - у
>> администратора останется возможность загрузится и если надо вручную
>> обновить initrd для других ядер.
>
> Представим ситуацию, когда новый initrd не загрузился (такое иногда
> бывает) и есть несовместимость баз. Что делать пользователю? Новое
> ядро не грузится... и старое тоже не будет грузится.
>
> Таким образом система будет работать, когда всё хорошо и не будет
> работать при проблемах. Собственно как и в случае неперегенерации
> initrd и копирования баз. Эффект будет одинаковым.
>
> Как один из обходных вариантов можно реализовать cmdline ключ для
> управления копированием базы udev в систему, который по умолчанию
> будет выставлен в "копировать". Тогда если реализовать аварийный
> механизм в системе на случай, когда базы udev нет, то пользователь
> сможет(?) загрузиться хоть как-то.
>
> Тут у меня возникают сомнения в возможности реализации аварийного
> режима т.к. этот тред и есть следствие того, что systemd не умеет
> нормально работать без базы udev. 2shaba@: Можно ли тут что-то сделать ?

Честно говоря не понял какой вопрос мне адресован.
Есть ли в systemd аварийный режим? Да, есть.
Или что "что-то сделать"?

--
Alexey Shabalin

Re: [sisyphus] udev-197

[Alexey Gladkov]

29.01.2013 15:54, Alexey Shabalin wrote:
> Честно говоря не понял какой вопрос мне адресован.
> Есть ли в systemd аварийный режим? Да, есть.
> Или что "что-то сделать"?

Вопрос был что будет если базы всё-таки не будет и чем это грозит ?
Можно ли в этих условиях гарантировать загрузку рута ?

-- 
Rgrds, legion

Re: [sisyphus] udev-197

[Alexey Shabalin]

29 января 2013 г., 16:01 пользователь Alexey Gladkov написал:
> 29.01.2013 15:54, Alexey Shabalin wrote:
>> Честно говоря не понял какой вопрос мне адресован.
>> Есть ли в systemd аварийный режим? Да, есть.
>> Или что "что-то сделать"?
>
> Вопрос был что будет если базы всё-таки не будет и чем это грозит ?
> Можно ли в этих условиях гарантировать загрузку рута ?
Рутовые диски инициализируются в initrd, а потом перемонтируются.
Тут проблем нет.
Я пока встречал только следующую проблему:
- все разделы на lvm
- lvm инициируется в initrd (make-initrd)
- корень успешно переключается
- пустая база udev частично наполняется, но не обовсём, так например
информации о swap на lvm нет.
- соответственно swap активироваться не может.

--
Alexey Shabalin