From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Message-ID: <39b55026-3552-43cb-aa95-34cabaaf17bb@altlinux.org> Date: Mon, 1 Jun 2026 13:44:57 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: make-initrd@lists.altlinux.org References: <7abadb27-fa4e-4a3b-940d-1688f0b067ca@altlinux.org> <84eb4e6d-4952-44fb-ad2b-d696b563a5eb@altlinux.org> <8c4f166a-c736-46a2-853e-253a3284539b@altlinux.org> Content-Language: ru, en-US From: Anton Midyukov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [make-initrd] =?utf-8?b?0JfQsNC80LXQvdCwIC92YXIvcnVuINC4IC92YXIv?= =?utf-8?b?bG9jayDQvdCwINGB0LjQvNC70LjQvdC60LgsINGD0LrQsNC30YvQstCw0Y4=?= =?utf-8?b?0YjQuNC1INC90LAgL3J1biDQuCAvcnVuL2xvY2sg0L3QsCDRgdGC0LDQtNC4?= =?utf-8?b?0LggaW5pdHJk?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2026 10:45:03 -0000 Archived-At: List-Archive: 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