[make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Anton Midyukov]

Доброго времени суток

Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.

Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
В таком случае потребуется монтировать /var, если он на отдельном разделе.
А также потребуется монтировать систему на запись.
Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
не являются симлинками.
Хотелось бы узнать, насколько это хорошая идея.

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Alexey Gladkov]

On Sun, May 31, 2026 at 04:54:56PM +0300, Anton Midyukov wrote:
> Доброго времени суток
> 
> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
> 
> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
> В таком случае потребуется монтировать /var, если он на отдельном разделе.
> А также потребуется монтировать систему на запись.
> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
> не являются симлинками.
> Хотелось бы узнать, насколько это хорошая идея.

Технически это возможно. В момент initramfs можно добавить

MOUNTPOINTS += /var

тогда мы попробуем добавить всё необходимое для /var и попытаемся
смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
что сделало бы миграцию.

Когда-то давно я предлагал сделать фичу для обновлений, но в то время
такая идея не вызвала интереса. Я предлагал сделать возможность вызова
скрипта определённого имени из рута системы перед запуском INIT.

-- 
Rgrds, legion

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Leonid Krivoshein]

Всем привет!


On 5/31/26 10:57 PM, Alexey Gladkov wrote:
> On Sun, May 31, 2026 at 04:54:56PM +0300, Anton Midyukov wrote:
>> Доброго времени суток
>>
>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
>>
>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
>> А также потребуется монтировать систему на запись.
>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
>> не являются симлинками.
>> Хотелось бы узнать, насколько это хорошая идея.
> 
> Технически это возможно. В момент initramfs можно добавить
> 
> MOUNTPOINTS += /var
> 
> тогда мы попробуем добавить всё необходимое для /var и попытаемся
> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
> что сделало бы миграцию.
> 
> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
> скрипта определённого имени из рута системы перед запуском INIT.
> 


А зачем? /sbin/init можно заменить для разовой операции, выполнить 
обновление из заменённого скрипта и вернуть всё обратно. Как-то так:

#!/bin/sh

T=/tmp/update.sh

if [ "$0" != "$T" ]; then
     cp -Lf -- "$0" "$T"
     exec $T "$@"
     exit 1
fi

# Doing update here...
...

# Restoring the original init
mv -f /sbin/init.old /sbin/init

# Call init or reboot
exec /sbin/init "$@"
exit 1


-- 
WBR, Leonid Krivoshein.

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Alexey Gladkov]

On Mon, Jun 01, 2026 at 01:17:01AM +0300, Leonid Krivoshein wrote:
> Всем привет!
> 
> 
> On 5/31/26 10:57 PM, Alexey Gladkov wrote:
> > On Sun, May 31, 2026 at 04:54:56PM +0300, Anton Midyukov wrote:
> >> Доброго времени суток
> >>
> >> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
> >> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
> >> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
> >>
> >> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
> >> В таком случае потребуется монтировать /var, если он на отдельном разделе.
> >> А также потребуется монтировать систему на запись.
> >> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
> >> не являются симлинками.
> >> Хотелось бы узнать, насколько это хорошая идея.
> > 
> > Технически это возможно. В момент initramfs можно добавить
> > 
> > MOUNTPOINTS += /var
> > 
> > тогда мы попробуем добавить всё необходимое для /var и попытаемся
> > смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
> > что сделало бы миграцию.
> > 
> > Когда-то давно я предлагал сделать фичу для обновлений, но в то время
> > такая идея не вызвала интереса. Я предлагал сделать возможность вызова
> > скрипта определённого имени из рута системы перед запуском INIT.
> > 
> 
> 
> А зачем? /sbin/init можно заменить для разовой операции, выполнить 
> обновление из заменённого скрипта и вернуть всё обратно. Как-то так:

Этот хак повреждает локальную систему. Можно добиться того же эффекта
сделав в grub one-shot запись с init=/update.sh .

Но в целом, вот эти же аргументы и звучали раньше.

> #!/bin/sh
> 
> T=/tmp/update.sh
> 
> if [ "$0" != "$T" ]; then
>      cp -Lf -- "$0" "$T"
>      exec $T "$@"
>      exit 1
> fi
> 
> # Doing update here...
> ...
> 
> # Restoring the original init
> mv -f /sbin/init.old /sbin/init
> 
> # Call init or reboot
> exec /sbin/init "$@"
> exit 1
> 
> 
> -- 
> WBR, Leonid Krivoshein.
> 
> _______________________________________________
> Make-initrd mailing list
> Make-initrd@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/make-initrd

-- 
Rgrds, legion

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Anton Midyukov]

01.06.2026 09:44, Alexey Gladkov пишет:
> On Mon, Jun 01, 2026 at 01:17:01AM +0300, Leonid Krivoshein wrote:
>> Всем привет!
>>
>>
>> On 5/31/26 10:57 PM, Alexey Gladkov wrote:
>>> On Sun, May 31, 2026 at 04:54:56PM +0300, Anton Midyukov wrote:
>>>> Доброго времени суток
>>>>
>>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
>>>>
>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
>>>> А также потребуется монтировать систему на запись.
>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
>>>> не являются симлинками.
>>>> Хотелось бы узнать, насколько это хорошая идея.
>>>
>>> Технически это возможно. В момент initramfs можно добавить
>>>
>>> MOUNTPOINTS += /var
>>>
>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
>>> что сделало бы миграцию.
>>>
>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
>>> скрипта определённого имени из рута системы перед запуском INIT.
>>>

А почему скрипт не помещать в initrd? Чтобы была универсальной?
Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
какой-то ещё переменной, которая укажет путь до скрипта.
И тогда мы получаем простой способ делать с системой разное. Мне нравится.

>>
>>
>> А зачем? /sbin/init можно заменить для разовой операции, выполнить 
>> обновление из заменённого скрипта и вернуть всё обратно. Как-то так:
> 
> Этот хак повреждает локальную систему. Можно добиться того же эффекта
> сделав в grub one-shot запись с init=/update.sh .
> 
> Но в целом, вот эти же аргументы и звучали раньше.
> 
>> #!/bin/sh
>>
>> T=/tmp/update.sh
>>
>> if [ "$0" != "$T" ]; then
>>      cp -Lf -- "$0" "$T"
>>      exec $T "$@"
>>      exit 1
>> fi
>>
>> # Doing update here...
>> ...
>>
>> # Restoring the original init
>> mv -f /sbin/init.old /sbin/init
>>
>> # Call init or reboot
>> exec /sbin/init "$@"
>> exit 1
>>
>>
>> -- 
>> WBR, Leonid Krivoshein.
>>
>> _______________________________________________
>> Make-initrd mailing list
>> Make-initrd@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/make-initrd
> 

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Alexey Gladkov]

On Mon, Jun 01, 2026 at 10:43:20AM +0300, Anton Midyukov wrote:
> 01.06.2026 09:44, Alexey Gladkov пишет:
> > On Mon, Jun 01, 2026 at 01:17:01AM +0300, Leonid Krivoshein wrote:
> >> Всем привет!
> >>
> >>
> >> On 5/31/26 10:57 PM, Alexey Gladkov wrote:
> >>> On Sun, May 31, 2026 at 04:54:56PM +0300, Anton Midyukov wrote:
> >>>> Доброго времени суток
> >>>>
> >>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
> >>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
> >>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
> >>>>
> >>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
> >>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
> >>>> А также потребуется монтировать систему на запись.
> >>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
> >>>> не являются симлинками.
> >>>> Хотелось бы узнать, насколько это хорошая идея.
> >>>
> >>> Технически это возможно. В момент initramfs можно добавить
> >>>
> >>> MOUNTPOINTS += /var
> >>>
> >>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
> >>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
> >>> что сделало бы миграцию.
> >>>
> >>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
> >>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
> >>> скрипта определённого имени из рута системы перед запуском INIT.
> >>>
> 
> А почему скрипт не помещать в initrd? Чтобы была универсальной?

Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про
необходимость дополнительных действий при создании initrd). У меня идея
была в том, что бы любой initrd мог выполнить манипуляции с системой,
пользуясь либо утилитами из initrd, либо из системы.

> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
> какой-то ещё переменной, которая укажет путь до скрипта.
> И тогда мы получаем простой способ делать с системой разное. Мне нравится.

У нас есть:

features/runtime/data/etc/rc.d/rc.sysexec

его можно расширить запуском дополнительных скриптов. Нужно лишь придумать
какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать
какой-нибудь /lib/sysexec.sh ?

Тогда вся обновлялка твоя будет:

MOUNTPOINTS += /var
PUT_FILES += /lib/sysexec.sh

> >>
> >>
> >> А зачем? /sbin/init можно заменить для разовой операции, выполнить 
> >> обновление из заменённого скрипта и вернуть всё обратно. Как-то так:
> > 
> > Этот хак повреждает локальную систему. Можно добиться того же эффекта
> > сделав в grub one-shot запись с init=/update.sh .
> > 
> > Но в целом, вот эти же аргументы и звучали раньше.
> > 
> >> #!/bin/sh
> >>
> >> T=/tmp/update.sh
> >>
> >> if [ "$0" != "$T" ]; then
> >>      cp -Lf -- "$0" "$T"
> >>      exec $T "$@"
> >>      exit 1
> >> fi
> >>
> >> # Doing update here...
> >> ...
> >>
> >> # Restoring the original init
> >> mv -f /sbin/init.old /sbin/init
> >>
> >> # Call init or reboot
> >> exec /sbin/init "$@"
> >> exit 1
> >>
> >>
> >> -- 
> >> WBR, Leonid Krivoshein.
> >>
> >> _______________________________________________
> >> Make-initrd mailing list
> >> Make-initrd@lists.altlinux.org
> >> https://lists.altlinux.org/mailman/listinfo/make-initrd
> > 
> 
> -- 
> best regards, Anton Midyukov <antohami@altlinux.org>
> 
> _______________________________________________
> Make-initrd mailing list
> Make-initrd@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/make-initrd

-- 
Rgrds, legion

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Anton Midyukov]

01.06.2026 11:08, Alexey Gladkov пишет:
> On Mon, Jun 01, 2026 at 10:43:20AM +0300, Anton Midyukov wrote:
>> 01.06.2026 09:44, Alexey Gladkov пишет:
>>> On Mon, Jun 01, 2026 at 01:17:01AM +0300, Leonid Krivoshein wrote:
>>>> Всем привет!
>>>>
>>>>
>>>> On 5/31/26 10:57 PM, Alexey Gladkov wrote:
>>>>> On Sun, May 31, 2026 at 04:54:56PM +0300, Anton Midyukov wrote:
>>>>>> Доброго времени суток
>>>>>>
>>>>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
>>>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
>>>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
>>>>>>
>>>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
>>>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
>>>>>> А также потребуется монтировать систему на запись.
>>>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
>>>>>> не являются симлинками.
>>>>>> Хотелось бы узнать, насколько это хорошая идея.
>>>>>
>>>>> Технически это возможно. В момент initramfs можно добавить
>>>>>
>>>>> MOUNTPOINTS += /var
>>>>>
>>>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
>>>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
>>>>> что сделало бы миграцию.
>>>>>
>>>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
>>>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
>>>>> скрипта определённого имени из рута системы перед запуском INIT.
>>>>>
>>
>> А почему скрипт не помещать в initrd? Чтобы была универсальной?
> 
> Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про
> необходимость дополнительных действий при создании initrd). У меня идея
> была в том, что бы любой initrd мог выполнить манипуляции с системой,
> пользуясь либо утилитами из initrd, либо из системы.
> 
>> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
>> какой-то ещё переменной, которая укажет путь до скрипта.
>> И тогда мы получаем простой способ делать с системой разное. Мне нравится.
> 
> У нас есть:
> 
> features/runtime/data/etc/rc.d/rc.sysexec
> 
> его можно расширить запуском дополнительных скриптов. Нужно лишь придумать
> какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать
> какой-нибудь /lib/sysexec.sh ?
> 
> Тогда вся обновлялка твоя будет:
> 
> MOUNTPOINTS += /var
> PUT_FILES += /lib/sysexec.sh
> 

Полагаю, что недостаточно. Так как будут ставиться в будущем пакеты с разноимёнными скриптами,
в %postinstall для первой установке которых будет генерация make-initrd с определёнными параметрами.
(хотя может это и неудачная идея, make-initrd может быть перегенерирован ещё по какой-то причине при обновлении)
То есть нужна некая новая переменная, которую нужно обработать. Можно назвать её SYSEXEC.

>>>>
>>>>
>>>> А зачем? /sbin/init можно заменить для разовой операции, выполнить 
>>>> обновление из заменённого скрипта и вернуть всё обратно. Как-то так:
>>>
>>> Этот хак повреждает локальную систему. Можно добиться того же эффекта
>>> сделав в grub one-shot запись с init=/update.sh .
>>>
>>> Но в целом, вот эти же аргументы и звучали раньше.
>>>
>>>> #!/bin/sh
>>>>
>>>> T=/tmp/update.sh
>>>>
>>>> if [ "$0" != "$T" ]; then
>>>>      cp -Lf -- "$0" "$T"
>>>>      exec $T "$@"
>>>>      exit 1
>>>> fi
>>>>
>>>> # Doing update here...
>>>> ...
>>>>
>>>> # Restoring the original init
>>>> mv -f /sbin/init.old /sbin/init
>>>>
>>>> # Call init or reboot
>>>> exec /sbin/init "$@"
>>>> exit 1
>>>>
>>>>
>>>> -- 
>>>> WBR, Leonid Krivoshein.
>>>>
>>>> _______________________________________________
>>>> Make-initrd mailing list
>>>> Make-initrd@lists.altlinux.org
>>>> https://lists.altlinux.org/mailman/listinfo/make-initrd
>>>
>>
>> -- 
>> best regards, Anton Midyukov <antohami@altlinux.org>
>>
>> _______________________________________________
>> Make-initrd mailing list
>> Make-initrd@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/make-initrd
> 

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Alexey Gladkov]

On Mon, Jun 01, 2026 at 11:18:59AM +0300, Anton Midyukov wrote:
> >>>>>> Доброго времени суток
> >>>>>>
> >>>>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
> >>>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
> >>>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
> >>>>>>
> >>>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
> >>>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
> >>>>>> А также потребуется монтировать систему на запись.
> >>>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
> >>>>>> не являются симлинками.
> >>>>>> Хотелось бы узнать, насколько это хорошая идея.
> >>>>>
> >>>>> Технически это возможно. В момент initramfs можно добавить
> >>>>>
> >>>>> MOUNTPOINTS += /var
> >>>>>
> >>>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
> >>>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
> >>>>> что сделало бы миграцию.
> >>>>>
> >>>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
> >>>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
> >>>>> скрипта определённого имени из рута системы перед запуском INIT.
> >>>>>
> >>
> >> А почему скрипт не помещать в initrd? Чтобы была универсальной?
> > 
> > Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про
> > необходимость дополнительных действий при создании initrd). У меня идея
> > была в том, что бы любой initrd мог выполнить манипуляции с системой,
> > пользуясь либо утилитами из initrd, либо из системы.
> > 
> >> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
> >> какой-то ещё переменной, которая укажет путь до скрипта.
> >> И тогда мы получаем простой способ делать с системой разное. Мне нравится.
> > 
> > У нас есть:
> > 
> > features/runtime/data/etc/rc.d/rc.sysexec
> > 
> > его можно расширить запуском дополнительных скриптов. Нужно лишь придумать
> > какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать
> > какой-нибудь /lib/sysexec.sh ?
> > 
> > Тогда вся обновлялка твоя будет:
> > 
> > MOUNTPOINTS += /var
> > PUT_FILES += /lib/sysexec.sh
> > 
> 
> Полагаю, что недостаточно. Так как будут ставиться в будущем пакеты с разноимёнными скриптами,
> в %postinstall для первой установке которых будет генерация make-initrd с определёнными параметрами.
> (хотя может это и неудачная идея, make-initrd может быть перегенерирован ещё по какой-то причине при обновлении)
> То есть нужна некая новая переменная, которую нужно обработать. Можно назвать её SYSEXEC.
> 

Раз речь уже идёт о %postinstall, то, возможно, стоит сделать
/lib/initramfs-upgrade.d и класть его в initrd. Тогда разные пакеты
могут класть туда скрипты параллельно, а триггер сгенерирует финальный
initrd.

Мне ещё подумалось про kickstart-files в этой директории, но возможно это
лишнее. Просто там уже есть команды и `%post [--nochroot]` то есть
возможность выполнять код как вне так и внутри реальной системы.

-- 
Rgrds, legion

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Anton Midyukov]

01.06.2026 12:01, Alexey Gladkov пишет:
> On Mon, Jun 01, 2026 at 11:18:59AM +0300, Anton Midyukov wrote:
>>>>>>>> Доброго времени суток
>>>>>>>>
>>>>>>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
>>>>>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
>>>>>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
>>>>>>>>
>>>>>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
>>>>>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
>>>>>>>> А также потребуется монтировать систему на запись.
>>>>>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
>>>>>>>> не являются симлинками.
>>>>>>>> Хотелось бы узнать, насколько это хорошая идея.
>>>>>>>
>>>>>>> Технически это возможно. В момент initramfs можно добавить
>>>>>>>
>>>>>>> MOUNTPOINTS += /var
>>>>>>>
>>>>>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
>>>>>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
>>>>>>> что сделало бы миграцию.
>>>>>>>
>>>>>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
>>>>>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
>>>>>>> скрипта определённого имени из рута системы перед запуском INIT.
>>>>>>>
>>>>
>>>> А почему скрипт не помещать в initrd? Чтобы была универсальной?
>>>
>>> Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про
>>> необходимость дополнительных действий при создании initrd). У меня идея
>>> была в том, что бы любой initrd мог выполнить манипуляции с системой,
>>> пользуясь либо утилитами из initrd, либо из системы.
>>>
>>>> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
>>>> какой-то ещё переменной, которая укажет путь до скрипта.
>>>> И тогда мы получаем простой способ делать с системой разное. Мне нравится.
>>>
>>> У нас есть:
>>>
>>> features/runtime/data/etc/rc.d/rc.sysexec
>>>
>>> его можно расширить запуском дополнительных скриптов. Нужно лишь придумать
>>> какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать
>>> какой-нибудь /lib/sysexec.sh ?
>>>
>>> Тогда вся обновлялка твоя будет:
>>>
>>> MOUNTPOINTS += /var
>>> PUT_FILES += /lib/sysexec.sh
>>>
>>
>> Полагаю, что недостаточно. Так как будут ставиться в будущем пакеты с разноимёнными скриптами,
>> в %postinstall для первой установке которых будет генерация make-initrd с определёнными параметрами.
>> (хотя может это и неудачная идея, make-initrd может быть перегенерирован ещё по какой-то причине при обновлении)
>> То есть нужна некая новая переменная, которую нужно обработать. Можно назвать её SYSEXEC.
>>
> 
> Раз речь уже идёт о %postinstall, то, возможно, стоит сделать
> /lib/initramfs-upgrade.d и класть его в initrd. Тогда разные пакеты
> могут класть туда скрипты параллельно, а триггер сгенерирует финальный
> initrd.
> 

Тогда возникает, видимо, проблемка, что до удаления пакета скрипт будет попадать в initrd постоянно.
Но можно его не пакетить, а создавать в %postinstall туда, и при успешном выполнении себя оттуда удалять.
Но как быть с MOUNTPOINTS += /var? Добавлять в /etc/initrd.mk, а потом оттуда убирать после успешного выполнения скрипта?
В целом, такого тогда достаточно будет.

> Мне ещё подумалось про kickstart-files в этой директории, но возможно это
> лишнее. Просто там уже есть команды и `%post [--nochroot]` то есть
> возможность выполнять код как вне так и внутри реальной системы.
> 

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Alexey Gladkov]

On Mon, Jun 01, 2026 at 01:04:05PM +0300, Anton Midyukov wrote:
> 01.06.2026 12:01, Alexey Gladkov пишет:
> > On Mon, Jun 01, 2026 at 11:18:59AM +0300, Anton Midyukov wrote:
> >>>>>>>> Доброго времени суток
> >>>>>>>>
> >>>>>>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
> >>>>>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
> >>>>>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
> >>>>>>>>
> >>>>>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
> >>>>>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
> >>>>>>>> А также потребуется монтировать систему на запись.
> >>>>>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
> >>>>>>>> не являются симлинками.
> >>>>>>>> Хотелось бы узнать, насколько это хорошая идея.
> >>>>>>>
> >>>>>>> Технически это возможно. В момент initramfs можно добавить
> >>>>>>>
> >>>>>>> MOUNTPOINTS += /var
> >>>>>>>
> >>>>>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
> >>>>>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
> >>>>>>> что сделало бы миграцию.
> >>>>>>>
> >>>>>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
> >>>>>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
> >>>>>>> скрипта определённого имени из рута системы перед запуском INIT.
> >>>>>>>
> >>>>
> >>>> А почему скрипт не помещать в initrd? Чтобы была универсальной?
> >>>
> >>> Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про
> >>> необходимость дополнительных действий при создании initrd). У меня идея
> >>> была в том, что бы любой initrd мог выполнить манипуляции с системой,
> >>> пользуясь либо утилитами из initrd, либо из системы.
> >>>
> >>>> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
> >>>> какой-то ещё переменной, которая укажет путь до скрипта.
> >>>> И тогда мы получаем простой способ делать с системой разное. Мне нравится.
> >>>
> >>> У нас есть:
> >>>
> >>> features/runtime/data/etc/rc.d/rc.sysexec
> >>>
> >>> его можно расширить запуском дополнительных скриптов. Нужно лишь придумать
> >>> какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать
> >>> какой-нибудь /lib/sysexec.sh ?
> >>>
> >>> Тогда вся обновлялка твоя будет:
> >>>
> >>> MOUNTPOINTS += /var
> >>> PUT_FILES += /lib/sysexec.sh
> >>>
> >>
> >> Полагаю, что недостаточно. Так как будут ставиться в будущем пакеты с разноимёнными скриптами,
> >> в %postinstall для первой установке которых будет генерация make-initrd с определёнными параметрами.
> >> (хотя может это и неудачная идея, make-initrd может быть перегенерирован ещё по какой-то причине при обновлении)
> >> То есть нужна некая новая переменная, которую нужно обработать. Можно назвать её SYSEXEC.
> >>
> > 
> > Раз речь уже идёт о %postinstall, то, возможно, стоит сделать
> > /lib/initramfs-upgrade.d и класть его в initrd. Тогда разные пакеты
> > могут класть туда скрипты параллельно, а триггер сгенерирует финальный
> > initrd.
> > 
> 
> Тогда возникает, видимо, проблемка, что до удаления пакета скрипт будет попадать в initrd постоянно.
> Но можно его не пакетить, а создавать в %postinstall туда, и при успешном выполнении себя оттуда удалять.
> Но как быть с MOUNTPOINTS += /var? Добавлять в /etc/initrd.mk, а потом оттуда убирать после успешного выполнения скрипта?
> В целом, такого тогда достаточно будет.

Так. Сформулируй ещё раз по пунктам, что тебе хочется иметь.

Потому что изначально, когда я предлагал /lib/sysexec.sh то думал, что
инсталлер (ты упоминал установку) будет делать:

make-initrd MOUNTPOINTS+=/var PUT_FILES+=/lib/sysexec.sh

то есть добавлять эти параметры один раз без конфига или с отдельным
конфигом. Тогда бы после миграции и перегенерации initrd этих файлов там
не было бы.


Если же мы говорим про опакечивание и %postinstall, то тут уже несколько
другое дело.

С `MOUNTPOINTS += /var` просится какая-то инфраструктура с кусками
конфига и скриптами, но мне очень не хочется раздувать эту идею. Это может
превратиться в целый фреймворк для обновлений с генерацией конфига и
проверками применённости состояния.

-- 
Rgrds, legion

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Anton Midyukov]

01.06.2026 13:31, Alexey Gladkov пишет:
> On Mon, Jun 01, 2026 at 01:04:05PM +0300, Anton Midyukov wrote:
>> 01.06.2026 12:01, Alexey Gladkov пишет:
>>> On Mon, Jun 01, 2026 at 11:18:59AM +0300, Anton Midyukov wrote:
>>>>>>>>>> Доброго времени суток
>>>>>>>>>>
>>>>>>>>>> Необходимость замены  /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock
>>>>>>>>>> уже давно перезрела. Начиная с p9, все новые системы являются мигрировавшими при их установке.
>>>>>>>>>> Но остаются системы, обновлявшиеся с p8, какие-то самодельные сборки, где эта миграция не выполнялась.
>>>>>>>>>>
>>>>>>>>>> Наверное, самый безопасный способ миграции таких систем - сделать это на этапе initrd.
>>>>>>>>>> В таком случае потребуется монтировать /var, если он на отдельном разделе.
>>>>>>>>>> А также потребуется монтировать систему на запись.
>>>>>>>>>> Видимо, это должна быть фича, которая добавляется в initrd автоматически, если /var/run или /var/lock
>>>>>>>>>> не являются симлинками.
>>>>>>>>>> Хотелось бы узнать, насколько это хорошая идея.
>>>>>>>>>
>>>>>>>>> Технически это возможно. В момент initramfs можно добавить
>>>>>>>>>
>>>>>>>>> MOUNTPOINTS += /var
>>>>>>>>>
>>>>>>>>> тогда мы попробуем добавить всё необходимое для /var и попытаемся
>>>>>>>>> смонтировать его для системы. Далее нужно вызвать что-то вместо INIT,
>>>>>>>>> что сделало бы миграцию.
>>>>>>>>>
>>>>>>>>> Когда-то давно я предлагал сделать фичу для обновлений, но в то время
>>>>>>>>> такая идея не вызвала интереса. Я предлагал сделать возможность вызова
>>>>>>>>> скрипта определённого имени из рута системы перед запуском INIT.
>>>>>>>>>
>>>>>>
>>>>>> А почему скрипт не помещать в initrd? Чтобы была универсальной?
>>>>>
>>>>> Да. В то время я не думал про `MOUNTPOINTS += /var` (то есть про
>>>>> необходимость дополнительных действий при создании initrd). У меня идея
>>>>> была в том, что бы любой initrd мог выполнить манипуляции с системой,
>>>>> пользуясь либо утилитами из initrd, либо из системы.
>>>>>
>>>>>> Тогда можно неким скриптом послеустановочным делать make-initrd c MOUNTPOINTS += /var и
>>>>>> какой-то ещё переменной, которая укажет путь до скрипта.
>>>>>> И тогда мы получаем простой способ делать с системой разное. Мне нравится.
>>>>>
>>>>> У нас есть:
>>>>>
>>>>> features/runtime/data/etc/rc.d/rc.sysexec
>>>>>
>>>>> его можно расширить запуском дополнительных скриптов. Нужно лишь придумать
>>>>> какой интерфейс тебя устроит. Достаточно ли будет проверять и вызывать
>>>>> какой-нибудь /lib/sysexec.sh ?
>>>>>
>>>>> Тогда вся обновлялка твоя будет:
>>>>>
>>>>> MOUNTPOINTS += /var
>>>>> PUT_FILES += /lib/sysexec.sh
>>>>>
>>>>
>>>> Полагаю, что недостаточно. Так как будут ставиться в будущем пакеты с разноимёнными скриптами,
>>>> в %postinstall для первой установке которых будет генерация make-initrd с определёнными параметрами.
>>>> (хотя может это и неудачная идея, make-initrd может быть перегенерирован ещё по какой-то причине при обновлении)
>>>> То есть нужна некая новая переменная, которую нужно обработать. Можно назвать её SYSEXEC.
>>>>
>>>
>>> Раз речь уже идёт о %postinstall, то, возможно, стоит сделать
>>> /lib/initramfs-upgrade.d и класть его в initrd. Тогда разные пакеты
>>> могут класть туда скрипты параллельно, а триггер сгенерирует финальный
>>> initrd.
>>>
>>
>> Тогда возникает, видимо, проблемка, что до удаления пакета скрипт будет попадать в initrd постоянно.
>> Но можно его не пакетить, а создавать в %postinstall туда, и при успешном выполнении себя оттуда удалять.
>> Но как быть с MOUNTPOINTS += /var? Добавлять в /etc/initrd.mk, а потом оттуда убирать после успешного выполнения скрипта?
>> В целом, такого тогда достаточно будет.
> 
> Так. Сформулируй ещё раз по пунктам, что тебе хочется иметь.
> 
> Потому что изначально, когда я предлагал /lib/sysexec.sh то думал, что
> инсталлер (ты упоминал установку) будет делать:
> 
> make-initrd MOUNTPOINTS+=/var PUT_FILES+=/lib/sysexec.sh

Это postinstall скрипт установки некоего пакета при обновлении. Под установкой я имел в виду установку некоего пакета.

> 
> то есть добавлять эти параметры один раз без конфига или с отдельным
> конфигом. Тогда бы после миграции и перегенерации initrd этих файлов там
> не было бы.
> 
> 
> Если же мы говорим про опакечивание и %postinstall, то тут уже несколько
> другое дело.
> 

Кейс у меня нарисовался такой:
1. Делается пакет с %postinstall скриптом, который обязательно приедет всем.
2. При первой установке пакета по определённому условию в %postinstall создаётся скрипт в /lib/initramfs-upgrade.d
По условию, что /var отдельный раздел добавляется MOUNTPOINTS+=/var в /etc/initrd.mk
3. Так как появился новый файл в /lib/initramfs-upgrade.d отрабатывает триггер (сработает ли он на %ghost? или тут я весь замысел сломал с триггером?)
4. При загрузке в initrd вызывается скрипт, который после успешной отработки удаляет себя в /lib/initramfs-upgrade.d и убирает MOUNTPOINTS+=/var из /etc/initrd.mk
5. запускается init

> С `MOUNTPOINTS += /var` просится какая-то инфраструктура с кусками
> конфига и скриптами, но мне очень не хочется раздувать эту идею. Это может
> превратиться в целый фреймворк для обновлений с генерацией конфига и
> проверками применённости состояния.
> 

Да, согласен. Поэтому и подумал, что скрипт мог бы за собой убирать и сам из /etc/initrd.mk.

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

Re: [make-initrd] Замена /var/run и /var/lock на симлинки, указываюшие на /run и /run/lock на стадии initrd

[Alexey Gladkov]

On Mon, Jun 01, 2026 at 01:44:57PM +0300, Anton Midyukov wrote:
> >> Тогда возникает, видимо, проблемка, что до удаления пакета скрипт будет попадать в initrd постоянно.
> >> Но можно его не пакетить, а создавать в %postinstall туда, и при успешном выполнении себя оттуда удалять.
> >> Но как быть с MOUNTPOINTS += /var? Добавлять в /etc/initrd.mk, а потом оттуда убирать после успешного выполнения скрипта?
> >> В целом, такого тогда достаточно будет.
> > 
> > Так. Сформулируй ещё раз по пунктам, что тебе хочется иметь.
> > 
> > Потому что изначально, когда я предлагал /lib/sysexec.sh то думал, что
> > инсталлер (ты упоминал установку) будет делать:
> > 
> > make-initrd MOUNTPOINTS+=/var PUT_FILES+=/lib/sysexec.sh
> 
> Это postinstall скрипт установки некоего пакета при обновлении. Под установкой я имел в виду установку некоего пакета.
> 
> > 
> > то есть добавлять эти параметры один раз без конфига или с отдельным
> > конфигом. Тогда бы после миграции и перегенерации initrd этих файлов там
> > не было бы.
> > 
> > 
> > Если же мы говорим про опакечивание и %postinstall, то тут уже несколько
> > другое дело.
> > 
> 
> Кейс у меня нарисовался такой:
> 1. Делается пакет с %postinstall скриптом, который обязательно приедет всем.
> 2. При первой установке пакета по определённому условию в %postinstall создаётся скрипт в /lib/initramfs-upgrade.d
> По условию, что /var отдельный раздел добавляется MOUNTPOINTS+=/var в /etc/initrd.mk
> 3. Так как появился новый файл в /lib/initramfs-upgrade.d отрабатывает триггер (сработает ли он на %ghost? или тут я весь замысел сломал с триггером?)
> 4. При загрузке в initrd вызывается скрипт, который после успешной отработки удаляет себя в /lib/initramfs-upgrade.d и убирает MOUNTPOINTS+=/var из /etc/initrd.mk
> 5. запускается init

Ты можешь создавать /etc/initrd.mk.d/upgrade.mk и make-initrd создаст
отдельный образ для этого конфига. Ты туда можешь сложить всё что тебе
нужно. Далее ты можешь добавить его в grub.conf и загрузить как once.
Далее если всё образ больше не нужен ты можешь удалить upgrade.mk и образ
больше не будет создаваться. Тогда не нужно делать %ghost и удалять
запакованные файлы.

> > С `MOUNTPOINTS += /var` просится какая-то инфраструктура с кусками
> > конфига и скриптами, но мне очень не хочется раздувать эту идею. Это может
> > превратиться в целый фреймворк для обновлений с генерацией конфига и
> > проверками применённости состояния.
> > 
> 
> Да, согласен. Поэтому и подумал, что скрипт мог бы за собой убирать и сам из /etc/initrd.mk.
> 

-- 
Rgrds, legion