[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