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

[Alexey Gladkov <legion@kernel.org>]

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