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: Date: Mon, 1 Jun 2026 13:04:05 +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:04:11 -0000 Archived-At: List-Archive: 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