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

[Anton Midyukov <antohami@altlinux.org>]

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>