[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 at altlinux.org>