New release 2.14.0 is available. Git repository ============== https://github.com/osboot/make-initrd.git http://git.altlinux.org/people/legion/packages/make-initrd.git Feedback and bug reports, as always, are welcomed. Changelog ========= Alexey Gladkov (41): Add busybox submodule Add libshell submodule Add target to get release tarball Use bash builtin command to check the availability of utilities Fix udevd detection initrd-put: Handle symlinks in the root directory initrd-put: Add more verbosity initrd-put: Get the canonical path correctly initrd-put: Set mode and owner after directories creation initrd-put: mksock() always returns a return code and errno initrd-put: Do not add whole directory if symlink points to it Use absolute directory names in the PATH configure: Add more messages and fix libelf check Rename hasher-build-rootfs -> build-rootfs-altlinux Use wrapper around readlink for portability tests: Increase build timeout tests: Add missing mode runtime: Use start-stop-daemon from busybox runtime: Enforce PATH create-initrd: Fix compatibility symlinks create-initrd: Take into account utilities in LOCALBUILDDIR tests: Use bash for simple system init tests: Use locally compiled utilities tests: Add script to build rootfs for fedora tests: Allow to run single testcase without qemu wrappers udev variables $ID_* are optional Feature network: Always import runtime environment runtime: Add logfile for udevd tests: Add target to build individual testcase tests: Make kernel flavor optional tests: Update altlinux rootfs guess: Allow to set variables in guessed config Feature mdadm: Generate udev rules for any raid devices runtime: Add default udev rules runtime: Add support for root=SERIAL=* Feature pipeline: Fix possible race in the waitdev Do not create /bin/sh All make messages should go to stderr depinfo: Do not show an error if softdep is not found Make a symlink to /bin/bash if bash is in a non-standard location 2.14.0 -- Rgrds, legion
Алексей, привет!
30.03.2021 21:21, Alexey Gladkov пишет:
> New release 2.14.0 is available.
>
> Git repository
> ==============
>
> https://github.com/osboot/make-initrd.git
> http://git.altlinux.org/people/legion/packages/make-initrd.git
>
> Feedback and bug reports, as always, are welcomed.
>
> Changelog
> =========
>
> Alexey Gladkov (41):
> Add busybox submodule
> Add libshell submodule
> Add target to get release tarball
> Use bash builtin command to check the availability of utilities
> Fix udevd detection
> initrd-put: Handle symlinks in the root directory
> initrd-put: Add more verbosity
> initrd-put: Get the canonical path correctly
> initrd-put: Set mode and owner after directories creation
> initrd-put: mksock() always returns a return code and errno
> initrd-put: Do not add whole directory if symlink points to it
> Use absolute directory names in the PATH
> configure: Add more messages and fix libelf check
> Rename hasher-build-rootfs -> build-rootfs-altlinux
> Use wrapper around readlink for portability
> tests: Increase build timeout
> tests: Add missing mode
> runtime: Use start-stop-daemon from busybox
> runtime: Enforce PATH
> create-initrd: Fix compatibility symlinks
> create-initrd: Take into account utilities in LOCALBUILDDIR
> tests: Use bash for simple system init
> tests: Use locally compiled utilities
> tests: Add script to build rootfs for fedora
> tests: Allow to run single testcase without qemu wrappers
> udev variables $ID_* are optional
> Feature network: Always import runtime environment
> runtime: Add logfile for udevd
> tests: Add target to build individual testcase
> tests: Make kernel flavor optional
> tests: Update altlinux rootfs
> guess: Allow to set variables in guessed config
> Feature mdadm: Generate udev rules for any raid devices
> runtime: Add default udev rules
> runtime: Add support for root=SERIAL=*
> Feature pipeline: Fix possible race in the waitdev
> Do not create /bin/sh
> All make messages should go to stderr
> depinfo: Do not show an error if softdep is not found
> Make a symlink to /bin/bash if bash is in a non-standard location
> 2.14.0
>
Шикарный набор, впечатляет! Огромное тебе спасибо!!!
Не против, если я немного поковыряю pipeline для доведения его до
нынешнего пропагатора и скину все изменения оптом?
Мне не очень нравится, как сейчас с пропагатором организован режим
сохранения сеансов LiveCD, думаю не сохранять её, а сделать другую
реализацию, ближе к тому, что есть в Puppy. Ну и, все протоколы хочу
проверить.
--
Best regards,
Leonid Krivoshein.
On Tue, Mar 30, 2021 at 11:18:56PM +0300, Leonid Krivoshein wrote: > > 2.14.0 > > > > Шикарный набор, впечатляет! Огромное тебе спасибо!!! > > Не против, если я немного поковыряю pipeline для доведения его до нынешнего > пропагатора и скину все изменения оптом? Разве я могу запретить кому-то чем-то заниматься ? ))) Если чего-то не хватает, то это можно добавить. Фича pipeline была сделана как минимальный базис. > Мне не очень нравится, как сейчас с пропагатором организован режим > сохранения сеансов LiveCD, думаю не сохранять её, а сделать другую > реализацию, ближе к тому, что есть в Puppy. Ну и, все протоколы хочу > проверить. Я не очень понимаю о чём ты говоришь. -- Rgrds, legion
31.03.2021 10:44, Alexey Gladkov пишет: > On Tue, Mar 30, 2021 at 11:18:56PM +0300, Leonid Krivoshein wrote: >>> 2.14.0 >>> >> Шикарный набор, впечатляет! Огромное тебе спасибо!!! >> >> Не против, если я немного поковыряю pipeline для доведения его до нынешнего >> пропагатора и скину все изменения оптом? > Разве я могу запретить кому-то чем-то заниматься ? ))) > > Если чего-то не хватает, то это можно добавить. Фича pipeline была сделана > как минимальный базис. Да, это понятно. Разобрались, наконец, с локальной загрузкой и как/чего переделывать. Но наткнулись на другую неприятную ошибку. Скорее всего, она внутри initrd-put -- при создании универсального загрузочного носителя (на замену того, что было с propagator) более половины ядерных модулей и каталогов с модулями попадает не в /lib/modules/$KVER, а в корневой каталог initramfs. Причём, это не зависит от используемого способа (директив) указания списка модулей и места, где это делается. И это не только в 2.14.0, с 2.13.0 то же самое. Нужна ли какая-то дополнительная диагностика? >> Мне не очень нравится, как сейчас с пропагатором организован режим >> сохранения сеансов LiveCD, думаю не сохранять её, а сделать другую >> реализацию, ближе к тому, что есть в Puppy. Ну и, все протоколы хочу >> проверить. > Я не очень понимаю о чём ты говоришь. В коде будет понятней. Сейчас мы говорим о переходе из stage1 в stage2 для обеспечения совместимости с нашими rescue, инсталлятором и livecd при полном выкидывании пропагатора. -- Best regards, Leonid Krivoshein.
On Wed, Mar 31, 2021 at 04:08:26PM +0300, Leonid Krivoshein wrote:
>
>
> 31.03.2021 10:44, Alexey Gladkov пишет:
> > On Tue, Mar 30, 2021 at 11:18:56PM +0300, Leonid Krivoshein wrote:
> > > > 2.14.0
> > > >
> > > Шикарный набор, впечатляет! Огромное тебе спасибо!!!
> > >
> > > Не против, если я немного поковыряю pipeline для доведения его до нынешнего
> > > пропагатора и скину все изменения оптом?
> > Разве я могу запретить кому-то чем-то заниматься ? )))
> >
> > Если чего-то не хватает, то это можно добавить. Фича pipeline была сделана
> > как минимальный базис.
>
> Да, это понятно. Разобрались, наконец, с локальной загрузкой и как/чего
> переделывать. Но наткнулись на другую неприятную ошибку. Скорее всего, она
> внутри initrd-put -- при создании универсального загрузочного носителя (на
> замену того, что было с propagator) более половины ядерных модулей и
> каталогов с модулями попадает не в /lib/modules/$KVER, а в корневой каталог
> initramfs. Причём, это не зависит от используемого способа (директив)
> указания списка модулей и места, где это делается. И это не только в 2.14.0,
> с 2.13.0 то же самое. Нужна ли какая-то дополнительная диагностика?
Разумеется нужна. Расскажите, что вы делали ?
--
Rgrds, legion
[-- Attachment #1: Type: text/plain, Size: 2741 bytes --] 31.03.2021 16:39, Alexey Gladkov пишет: > On Wed, Mar 31, 2021 at 04:08:26PM +0300, Leonid Krivoshein wrote: >> 31.03.2021 10:44, Alexey Gladkov пишет: >>> On Tue, Mar 30, 2021 at 11:18:56PM +0300, Leonid Krivoshein wrote: >>>>> 2.14.0 >>>>> >>>> Шикарный набор, впечатляет! Огромное тебе спасибо!!! >>>> >>>> Не против, если я немного поковыряю pipeline для доведения его до нынешнего >>>> пропагатора и скину все изменения оптом? >>> Разве я могу запретить кому-то чем-то заниматься ? ))) >>> >>> Если чего-то не хватает, то это можно добавить. Фича pipeline была сделана >>> как минимальный базис. >> Да, это понятно. Разобрались, наконец, с локальной загрузкой и как/чего >> переделывать. Но наткнулись на другую неприятную ошибку. Скорее всего, она >> внутри initrd-put -- при создании универсального загрузочного носителя (на >> замену того, что было с propagator) более половины ядерных модулей и >> каталогов с модулями попадает не в /lib/modules/$KVER, а в корневой каталог >> initramfs. Причём, это не зависит от используемого способа (директив) >> указания списка модулей и места, где это делается. И это не только в 2.14.0, >> с 2.13.0 то же самое. Нужна ли какая-то дополнительная диагностика? > Разумеется нужна. Расскажите, что вы делали ? Просто давали команду make-initrd, предварительно скармливая разными способами список модулей через /etc/initrd.mk. Перепробованы были разные директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех случаях модули попадают, но в основном не туда, куда надо. См. во вложении пример вывода initrd-ls и один из вариантов скриптов, которым это делается. -- Best regards, Leonid Krivoshein. [-- Attachment #2: 511.lst.gz --] [-- Type: application/gzip, Size: 18769 bytes --] [-- Attachment #3: 80-make-initrd-for-pipeline --] [-- Type: text/plain, Size: 1957 bytes --] #!/bin/sh -efux # NB: /etc/initrd.mk carefully prepared by earlier scripts fatal() { echo "** error: $@" >&1; exit 1; } kver= for KFLAVOUR in $GLOBAL_KFLAVOURS; do kver+=" $(rpm -qa 'kernel-image*' \ --qf '%{version}-%{name}-%{release}\n' \ | grep "$KFLAVOUR" \ | sed 's/kernel-image-//')" done [ -n "$kver" ] || fatal "no kernel version identified" INITRD_FEATURES+="add-modules compress cleanup rdshell pipeline" INITRD_MODULES="$(grep -v ^# /.in/modules | grep -v / | grep .ko | sort -u)" INITRD_PUT_DIRS="$(grep -v ^# /.in/modules | grep -v .ko | sort -u)" initrd_modules_find() { if [ -n "$INITRD_MODULES" ]; then echo "MODULES_LOAD += \\" for INITRD_MODULE in $INITRD_MODULES; do MODNAME="$(find /lib/modules/$KVER -type f -name $INITRD_MODULE)" [ -z "$MODNAME" ] || echo " ${MODNAME##*/} \\" done echo " #" fi if [ -n "$INITRD_PUT_DIRS" ]; then echo "PUT_DIRS += \\" for INITRD_PUT_DIR in $INITRD_PUT_DIRS; do [ ! -d "/lib/modules/$KVER/$INITRD_PUT_DIR" ] || echo " /lib/modules/$KVER/$INITRD_PUT_DIR \\" done echo " #" fi } # FIXME: large storage systems can get that tmpfs filled up # with debug data as of make-initrd 2.2.12 rm -vf /usr/share/make-initrd/data/etc/udev/rules.d/00-debug.rules \ /usr/share/make-initrd/data/lib/uevent/filters/debug MAKE_INITRD_OPTS="--no-checks AUTODETECT=" MAKE_INITRD_VER="`make-initrd -V \ | sed -rn 's/^make-initrd version ([0-9.]+)/\1/p'`" [ -z "$GLOBAL_VERBOSE" ] || MAKE_INITRD_OPTS="$MAKE_INITRD_OPTS -v" cd /boot for KVER in $kver; do touch /etc/initrd.mk cp -Lvf /etc/initrd.mk /etc/initrd-mk.bak initrd_modules_find >> /etc/initrd.mk make-initrd $MAKE_INITRD_OPTS -k "$KVER" \ FEATURES+="$INITRD_FEATURES" || fatal "make-initrd failed" mv -vf /etc/initrd-mk.bak /etc/initrd.mk done case `arch` in e2k) kname=image;; *) kname=vmlinuz;; esac rm -f $kname initrd.img ln -s $kname-$KVER $kname ln -s initrd-$KVER.img initrd.img :
31.03.2021 20:55, Leonid Krivoshein пишет:
>
> 31.03.2021 16:39, Alexey Gladkov пишет:
>> On Wed, Mar 31, 2021 at 04:08:26PM +0300, Leonid Krivoshein wrote:
>>> 31.03.2021 10:44, Alexey Gladkov пишет:
>>>> On Tue, Mar 30, 2021 at 11:18:56PM +0300, Leonid Krivoshein wrote:
>>>>>> 2.14.0
>>>>>>
>>>>> Шикарный набор, впечатляет! Огромное тебе спасибо!!!
>>>>>
>>>>> Не против, если я немного поковыряю pipeline для доведения его до нынешнего
>>>>> пропагатора и скину все изменения оптом?
>>>> Разве я могу запретить кому-то чем-то заниматься ? )))
>>>>
>>>> Если чего-то не хватает, то это можно добавить. Фича pipeline была сделана
>>>> как минимальный базис.
>>> Да, это понятно. Разобрались, наконец, с локальной загрузкой и как/чего
>>> переделывать. Но наткнулись на другую неприятную ошибку. Скорее всего, она
>>> внутри initrd-put -- при создании универсального загрузочного носителя (на
>>> замену того, что было с propagator) более половины ядерных модулей и
>>> каталогов с модулями попадает не в /lib/modules/$KVER, а в корневой каталог
>>> initramfs. Причём, это не зависит от используемого способа (директив)
>>> указания списка модулей и места, где это делается. И это не только в 2.14.0,
>>> с 2.13.0 то же самое. Нужна ли какая-то дополнительная диагностика?
>> Разумеется нужна. Расскажите, что вы делали ?
>
> Просто давали команду make-initrd, предварительно скармливая разными способами список модулей через /etc/initrd.mk. Перепробованы были разные директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех случаях модули попадают, но в основном не туда, куда надо. См. во вложении пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
>
Я так полагаю, что надо просто все модули через MODULES_LOAD или MODULES_PRELOAD добавлять, а не как сейчас, часть в виде каталогов с модулями через PUT_DIRS.
--
С уважением, Антон Мидюков <antohami@basealt.ru>
On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
> > Разумеется нужна. Расскажите, что вы делали ?
>
> Просто давали команду make-initrd, предварительно скармливая разными
> способами список модулей через /etc/initrd.mk. Перепробованы были разные
> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
> случаях модули попадают, но в основном не туда, куда надо. См. во вложении
> пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
Текущее ядро:
$ uname -r
5.12.0-rc4
Вот конфиг плюс ещё один некий молуль:
$ grep -v ^# /etc/initrd.mk
AUTODETECT = all
PUT_FILES += /lib/modules/5.8.0/kernel/fs/9p/9p.ko.xz
$ make-initrd -D -b /tmp -c /etc/initrd.mk
...
[00:00:08] Image is saved as /tmp/initrd-5.12.0-rc4.img
Модули под целевое ядро на месте:
$ initrd-ls /tmp/initrd-5.12.0-rc4.img | grep -m1 '5.12.0.*.ko'
2 -rw-r--r-- 1 0 0 49720 Mar 31 16:10:34 2021 ./lib/modules/5.12.0-rc4/kernel/net/packet/af_packet.ko.xz
Запрашиваемый файл на месте:
$ initrd-ls /tmp/initrd-5.12.0-rc4.img | grep '9p\.ko'
2 drwxr-xr-x 2 0 0 0 Mar 31 16:10:35 2021 ./lib/modules/5.8.0/kernel/fs/9p
2 -rw-r--r-- 1 0 0 67056 Mar 31 16:10:33 2021 ./lib/modules/5.8.0/kernel/fs/9p/9p.ko.xz
Давай попробуем иначе:
$ grep -v ^# /etc/initrd.mk
AUTODETECT = all
MODULES_ADD += 9p
$ initrd-ls /tmp/initrd-5.12.0-rc4.img | grep '9p\.ko'
2 -rw-r--r-- 1 0 0 70340 Mar 31 16:17:16 2021 ./lib/modules/5.12.0-rc4/kernel/fs/9p/9p.ko.xz
У меня есть подозрение, что у вас make-intird в каком-то странном
окружении. Попробуйте ограничить его через env -i и добавить туда только
то что необходимо.
Также я был бы признателен за более понятный testcase.
Что находится в /.in/modules ?
--
Rgrds, legion
On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
> Просто давали команду make-initrd, предварительно скармливая разными
> способами список модулей через /etc/initrd.mk. Перепробованы были разные
> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
> случаях модули попадают, но в основном не туда, куда надо. См. во вложении
> пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
PUT_DIRS с самого момента создания make-initrd копирует содержимое
каталога без самого каталога. Например так копируется:
PUT_DIRS += /lib/initrd
--
Rgrds, legion
On Wed, Mar 31, 2021 at 04:40:58PM +0200, Alexey Gladkov wrote:
> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
> > Просто давали команду make-initrd, предварительно скармливая разными
> > способами список модулей через /etc/initrd.mk. Перепробованы были разные
> > директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
> > MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
> > случаях модули попадают, но в основном не туда, куда надо. См. во вложении
> > пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
>
> PUT_DIRS с самого момента создания make-initrd копирует содержимое
> каталога без самого каталога. Например так копируется:
>
> PUT_DIRS += /lib/initrd
Я наврал. Это случилось Sun May 6 15:35:14 2012. Да, согласен, это
регрессия.
--
Rgrds, legion
31.03.2021 17:40, Alexey Gladkov пишет:
> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
>> Просто давали команду make-initrd, предварительно скармливая разными
>> способами список модулей через /etc/initrd.mk. Перепробованы были разные
>> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
>> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
>> случаях модули попадают, но в основном не туда, куда надо. См. во вложении
>> пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
> PUT_DIRS с самого момента создания make-initrd копирует содержимое
> каталога без самого каталога. Например так копируется:
>
> PUT_DIRS += /lib/initrd
Ага, спасибо. Сейчас попробую переделать с учётом сказанного и
посмотрим, что получится.
--
Best regards,
Leonid Krivoshein.
31.03.2021 21:40, Alexey Gladkov пишет:
> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
>> Просто давали команду make-initrd, предварительно скармливая разными
>> способами список модулей через /etc/initrd.mk. Перепробованы были разные
>> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
>> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
>> случаях модули попадают, но в основном не туда, куда надо. См. во вложении
>> пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
>
> PUT_DIRS с самого момента создания make-initrd копирует содержимое
> каталога без самого каталога. Например так копируется:
>
> PUT_DIRS += /lib/initrd
>
Вот, именно в этом и проблема. Нужно найти все модули в целевых каталогах и добавить в список MODULES_LOAD.
В MODULES_LOAD каталоги добавлять же нельзя?
--
С уважением, Антон Мидюков <antohami@basealt.ru>
On Wed, Mar 31, 2021 at 09:50:11PM +0700, Антон Мидюков wrote:
> 31.03.2021 21:40, Alexey Gladkov пишет:
> > On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
> >> Просто давали команду make-initrd, предварительно скармливая разными
> >> способами список модулей через /etc/initrd.mk. Перепробованы были разные
> >> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
> >> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
> >> случаях модули попадают, но в основном не туда, куда надо. См. во вложении
> >> пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
> >
> > PUT_DIRS с самого момента создания make-initrd копирует содержимое
> > каталога без самого каталога. Например так копируется:
> >
> > PUT_DIRS += /lib/initrd
> >
>
> Вот, именно в этом и проблема. Нужно найти все модули в целевых каталогах и добавить в список MODULES_LOAD.
> В MODULES_LOAD каталоги добавлять же нельзя?
Это список имён модулей. Он же потом будет использован modprobe.
Было бы отлично если бы я знал какую задачу вы хотите решить.
--
Rgrds, legion
31.03.2021 22:22, Alexey Gladkov пишет:
> On Wed, Mar 31, 2021 at 09:50:11PM +0700, Антон Мидюков wrote:
>> 31.03.2021 21:40, Alexey Gladkov пишет:
>>> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote:
>>>> Просто давали команду make-initrd, предварительно скармливая разными
>>>> способами список модулей через /etc/initrd.mk. Перепробованы были разные
>>>> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы
>>>> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех
>>>> случаях модули попадают, но в основном не туда, куда надо. См. во вложении
>>>> пример вывода initrd-ls и один из вариантов скриптов, которым это делается.
>>>
>>> PUT_DIRS с самого момента создания make-initrd копирует содержимое
>>> каталога без самого каталога. Например так копируется:
>>>
>>> PUT_DIRS += /lib/initrd
>>>
>>
>> Вот, именно в этом и проблема. Нужно найти все модули в целевых каталогах и добавить в список MODULES_LOAD.
>> В MODULES_LOAD каталоги добавлять же нельзя?
>
> Это список имён модулей. Он же потом будет использован modprobe.
> Было бы отлично если бы я знал какую задачу вы хотите решить.
>
Решается задача упаковки при помощи make-initrd модулей, которые даны списком. В списке есть как каталоги, так и название модулей, вида <имя_модуля.ko>
Список был изначально предназначен для mkmodpack.
Конечная задача загрузка iso образа с initrd.img с использованием фичи pipeline вместо propagator.
Если модули просто добавить в initrd то они не подгружаются. waitdev не находит устройство (файловую систему isofs) по UUID.
Поэтому весь список модулей загружаем.
--
С уважением, Антон Мидюков <antohami@basealt.ru>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --] 31.03.2021 18:37, Антон Мидюков пишет: > 31.03.2021 22:22, Alexey Gladkov пишет: >> On Wed, Mar 31, 2021 at 09:50:11PM +0700, Антон Мидюков wrote: >>> 31.03.2021 21:40, Alexey Gladkov пишет: >>>> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote: >>>>> Просто давали команду make-initrd, предварительно скармливая разными >>>>> способами список модулей через /etc/initrd.mk. Перепробованы были разные >>>>> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы >>>>> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех >>>>> случаях модули попадают, но в основном не туда, куда надо. См. во вложении >>>>> пример вывода initrd-ls и один из вариантов скриптов, которым это делается. >>>> PUT_DIRS с самого момента создания make-initrd копирует содержимое >>>> каталога без самого каталога. Например так копируется: >>>> >>>> PUT_DIRS += /lib/initrd >>>> >>> Вот, именно в этом и проблема. Нужно найти все модули в целевых каталогах и добавить в список MODULES_LOAD. >>> В MODULES_LOAD каталоги добавлять же нельзя? >> Это список имён модулей. Он же потом будет использован modprobe. >> Было бы отлично если бы я знал какую задачу вы хотите решить. >> > Решается задача упаковки при помощи make-initrd модулей, которые даны списком. В списке есть как каталоги, так и название модулей, вида <имя_модуля.ko> > Список был изначально предназначен для mkmodpack. > Конечная задача загрузка iso образа с initrd.img с использованием фичи pipeline вместо propagator. > Если модули просто добавить в initrd то они не подгружаются. waitdev не находит устройство (файловую систему isofs) по UUID. > Поэтому весь список модулей загружаем. > Другой разговор. Теперь всё получилось! -- Best regards, Leonid Krivoshein. [-- Attachment #2: 511.lst.gz --] [-- Type: application/gzip, Size: 16759 bytes --] [-- Attachment #3: 80-make-initrd-for-pipeline --] [-- Type: text/plain, Size: 2166 bytes --] #!/bin/sh -efux # NB: /etc/initrd.mk carefully prepared by earlier scripts fatal() { echo "** error: $@" >&1; exit 1; } kver= for KFLAVOUR in $GLOBAL_KFLAVOURS; do kver+=" $(rpm -qa 'kernel-image*' \ --qf '%{version}-%{name}-%{release}\n' \ | grep "$KFLAVOUR" \ | sed 's/kernel-image-//')" done [ -n "$kver" ] || fatal "no kernel version identified" INITRD_FEATURES+="add-modules compress cleanup rdshell pipeline" INITRD_MODULES="$(grep -v ^# /.in/modules | grep -v / | grep .ko | sort -u)" INITRD_PUT_DIRS="$(grep -v ^# /.in/modules | grep -v .ko | sort -u)" initrd_modules_find() { if [ -n "$INITRD_MODULES" ]; then echo "MODULES_LOAD += \\" for INITRD_MODULE in $INITRD_MODULES; do MODNAME="$(find /lib/modules/$KVER -type f -name $INITRD_MODULE)" [ -z "$MODNAME" ] || echo " $(basename "$MODNAME" |sed -E 's/\.ko(\.gz)?$//') \\" done echo " #" fi if [ -n "$INITRD_PUT_DIRS" ]; then echo "MODULES_LOAD += \\" for INITRD_PUT_DIR in $INITRD_PUT_DIRS; do [ -d "/lib/modules/$KVER/$INITRD_PUT_DIR" ] || continue MODLIST="$(find /lib/modules/$KVER/$INITRD_PUT_DIR -type f)" [ -n "$MODLIST" ] || continue for MODNAME in $MODLIST; do echo " $(basename "$MODNAME" |sed -E 's/\.ko(\.gz)?$//') \\" done done echo " #" fi } # FIXME: large storage systems can get that tmpfs filled up # with debug data as of make-initrd 2.2.12 rm -vf /usr/share/make-initrd/data/etc/udev/rules.d/00-debug.rules \ /usr/share/make-initrd/data/lib/uevent/filters/debug MAKE_INITRD_OPTS="--no-checks AUTODETECT=" MAKE_INITRD_VER="`make-initrd -V \ | sed -rn 's/^make-initrd version ([0-9.]+)/\1/p'`" [ -z "$GLOBAL_VERBOSE" ] || MAKE_INITRD_OPTS="$MAKE_INITRD_OPTS -v" cd /boot for KVER in $kver; do touch /etc/initrd.mk cp -Lvf /etc/initrd.mk /etc/initrd-mk.bak initrd_modules_find >> /etc/initrd.mk make-initrd $MAKE_INITRD_OPTS -k "$KVER" \ FEATURES+="$INITRD_FEATURES" || fatal "make-initrd failed" mv -vf /etc/initrd-mk.bak /etc/initrd.mk done case `arch` in e2k) kname=image;; *) kname=vmlinuz;; esac rm -f $kname initrd.img ln -s $kname-$KVER $kname ln -s initrd-$KVER.img initrd.img :
On Wed, Mar 31, 2021 at 10:37:35PM +0700, Антон Мидюков wrote: > 31.03.2021 22:22, Alexey Gladkov пишет: > > On Wed, Mar 31, 2021 at 09:50:11PM +0700, Антон Мидюков wrote: > >> 31.03.2021 21:40, Alexey Gladkov пишет: > >>> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote: > >>>> Просто давали команду make-initrd, предварительно скармливая разными > >>>> способами список модулей через /etc/initrd.mk. Перепробованы были разные > >>>> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы > >>>> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех > >>>> случаях модули попадают, но в основном не туда, куда надо. См. во вложении > >>>> пример вывода initrd-ls и один из вариантов скриптов, которым это делается. > >>> > >>> PUT_DIRS с самого момента создания make-initrd копирует содержимое > >>> каталога без самого каталога. Например так копируется: > >>> > >>> PUT_DIRS += /lib/initrd > >>> > >> > >> Вот, именно в этом и проблема. Нужно найти все модули в целевых каталогах и добавить в список MODULES_LOAD. > >> В MODULES_LOAD каталоги добавлять же нельзя? > > > > Это список имён модулей. Он же потом будет использован modprobe. > > Было бы отлично если бы я знал какую задачу вы хотите решить. > > > > Решается задача упаковки при помощи make-initrd модулей, которые даны списком. В списке есть как каталоги, так и название модулей, вида <имя_модуля.ko> > Список был изначально предназначен для mkmodpack. Передайте всё в PUT_FILES. Если в списке будет каталог, то он скопируется рекурсивно. Например: $ grep -v ^# /etc/initrd.mk AUTODETECT = all PUT_FILES += /lib/modules/5.8.0/kernel/fs $ make-initrd -k 5.12.0-rc4 -c /etc/initrd.mk ... $ initrd-ls /tmp/initrd-5.12.0-rc4.img | grep '5\.8\.0/.*\.ko' |head -5 2 -rw-r--r-- 1 0 0 21264 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/zonefs/zonefs.ko.xz 2 -rw-r--r-- 1 0 0 666356 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/xfs/xfs.ko.xz 2 -rw-r--r-- 1 0 0 69816 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/ufs/ufs.ko.xz 2 -rw-r--r-- 1 0 0 98740 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/udf/udf.ko.xz 2 -rw-r--r-- 1 0 0 53596 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/squashfs/squashfs.ko.xz > Конечная задача загрузка iso образа с initrd.img с использованием фичи pipeline вместо propagator. > Если модули просто добавить в initrd то они не подгружаются. waitdev не находит устройство (файловую систему isofs) по UUID. > Поэтому весь список модулей загружаем. Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? Вы же знаете, что вы хотите ждать исошку. Для исошки вам нужно подождать пока udev загрузит нужный модуль и пока не появится условный /dev/cdrom. Для этого вообще не нужно ничего грузить руками (см test-pipeline-iso-squash). Возможно, понадобиться дополнительная команда, которая определит, что в приводе есть диск и он правильный. Но это уже совсем другое. -- Rgrds, legion
31.03.2021 18:57, Alexey Gladkov пишет: > On Wed, Mar 31, 2021 at 10:37:35PM +0700, Антон Мидюков wrote: >> 31.03.2021 22:22, Alexey Gladkov пишет: >>> On Wed, Mar 31, 2021 at 09:50:11PM +0700, Антон Мидюков wrote: >>>> 31.03.2021 21:40, Alexey Gladkov пишет: >>>>> On Wed, Mar 31, 2021 at 04:55:18PM +0300, Leonid Krivoshein wrote: >>>>>> Просто давали команду make-initrd, предварительно скармливая разными >>>>>> способами список модулей через /etc/initrd.mk. Перепробованы были разные >>>>>> директивы -- PUT_DIRS/PUT_FILES с указанием полных путей, директивы >>>>>> MODULES_LOAD и MODULES_PRELOAD с указанием только названий модулей. Во всех >>>>>> случаях модули попадают, но в основном не туда, куда надо. См. во вложении >>>>>> пример вывода initrd-ls и один из вариантов скриптов, которым это делается. >>>>> PUT_DIRS с самого момента создания make-initrd копирует содержимое >>>>> каталога без самого каталога. Например так копируется: >>>>> >>>>> PUT_DIRS += /lib/initrd >>>>> >>>> Вот, именно в этом и проблема. Нужно найти все модули в целевых каталогах и добавить в список MODULES_LOAD. >>>> В MODULES_LOAD каталоги добавлять же нельзя? >>> Это список имён модулей. Он же потом будет использован modprobe. >>> Было бы отлично если бы я знал какую задачу вы хотите решить. >>> >> Решается задача упаковки при помощи make-initrd модулей, которые даны списком. В списке есть как каталоги, так и название модулей, вида <имя_модуля.ko> >> Список был изначально предназначен для mkmodpack. > Передайте всё в PUT_FILES. Если в списке будет каталог, то он скопируется > рекурсивно. > > Например: > > $ grep -v ^# /etc/initrd.mk > AUTODETECT = all > PUT_FILES += /lib/modules/5.8.0/kernel/fs > > $ make-initrd -k 5.12.0-rc4 -c /etc/initrd.mk > ... > > $ initrd-ls /tmp/initrd-5.12.0-rc4.img | grep '5\.8\.0/.*\.ko' |head -5 > 2 -rw-r--r-- 1 0 0 21264 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/zonefs/zonefs.ko.xz > 2 -rw-r--r-- 1 0 0 666356 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/xfs/xfs.ko.xz > 2 -rw-r--r-- 1 0 0 69816 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/ufs/ufs.ko.xz > 2 -rw-r--r-- 1 0 0 98740 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/udf/udf.ko.xz > 2 -rw-r--r-- 1 0 0 53596 Mar 31 17:47:53 2021 ./lib/modules/5.8.0/kernel/fs/squashfs/squashfs.ko.xz > >> Конечная задача загрузка iso образа с initrd.img с использованием фичи pipeline вместо propagator. >> Если модули просто добавить в initrd то они не подгружаются. waitdev не находит устройство (файловую систему isofs) по UUID. >> Поэтому весь список модулей загружаем. > Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? > Вы же знаете, что вы хотите ждать исошку. Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd. И конечно теперь пойдём ещё раз по пути PUT_FILES += ... > Для исошки вам нужно подождать пока udev загрузит нужный модуль и пока не > появится условный /dev/cdrom. Для этого вообще не нужно ничего грузить > руками (см test-pipeline-iso-squash). > > Возможно, понадобиться дополнительная команда, которая определит, что в > приводе есть диск и он правильный. Но это уже совсем другое. Как раз хочу сделать cdrom вместо waitdev, чтобы там же было сразу и mountfs, но ещё не приступал. А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп для waitdev? Ведь сейчас waitdev позволяет указать только само устройство, подобно root=, но указать дополнительные параметры не получится. -- Best regards, Leonid Krivoshein.
On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: > > Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? > > Вы же знаете, что вы хотите ждать исошку. > > Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd. > И конечно теперь пойдём ещё раз по пути PUT_FILES += ... Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и указывать в PUT_FILES. Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно их искать руками. Для модулей работает: MODULES_TRY_ADD += drivers/char/ > > Для исошки вам нужно подождать пока udev загрузит нужный модуль и пока не > > появится условный /dev/cdrom. Для этого вообще не нужно ничего грузить > > руками (см test-pipeline-iso-squash). > > > > Возможно, понадобиться дополнительная команда, которая определит, что в > > приводе есть диск и он правильный. Но это уже совсем другое. > > Как раз хочу сделать cdrom вместо waitdev, чтобы там же было сразу и > mountfs, но ещё не приступал. Это логично и вполне ожидаемо. > А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп > для waitdev? А какой у этого юскейс ? waitdev только ожидает появления устройства. Оно не монтируется. Для mountfs наверно в этом есть смысл. > Ведь сейчас waitdev позволяет указать только само устройство, > подобно root=, но указать дополнительные параметры не получится. -- Rgrds, legion
31.03.2021 23:55, Alexey Gladkov пишет:
> On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote:
>>> Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ?
>>> Вы же знаете, что вы хотите ждать исошку.
>>
>> Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd.
>> И конечно теперь пойдём ещё раз по пути PUT_FILES += ...
>
> Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и
> указывать в PUT_FILES.
>
> Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно
> их искать руками. Для модулей работает:
>
> MODULES_TRY_ADD += drivers/char/
Это то, что нам надо! Не надо ничего проверять, добавлять каталоги так. Не знал, что так можно.
На конце обязательно должен быть '/' ?
--
С уважением, Антон Мидюков <antohami@basealt.ru>
On Thu, Apr 01, 2021 at 12:02:57AM +0700, Антон Мидюков wrote: > 31.03.2021 23:55, Alexey Gladkov пишет: > > On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: > >>> Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? > >>> Вы же знаете, что вы хотите ждать исошку. > >> > >> Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd. > >> И конечно теперь пойдём ещё раз по пути PUT_FILES += ... > > > > Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и > > указывать в PUT_FILES. > > > > Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно > > их искать руками. Для модулей работает: > > > > MODULES_TRY_ADD += drivers/char/ > > Это то, что нам надо! Не надо ничего проверять, добавлять каталоги так. Не знал, что так можно. > На конце обязательно должен быть '/' ? Это даже не строка. Это regexp [1], который будет применён к списку модулей. Слэш в конце гарантирует, что не будут положены char-foo-bar.ko [1] https://github.com/osboot/make-initrd/blob/master/features/add-modules/bin/put-modules#L48-L56 -- Rgrds, legion
31.03.2021 19:55, Alexey Gladkov пишет: > On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: >>> Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? >>> Вы же знаете, что вы хотите ждать исошку. >> Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd. >> И конечно теперь пойдём ещё раз по пути PUT_FILES += ... > Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и > указывать в PUT_FILES. > > Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно > их искать руками. Для модулей работает: > > MODULES_TRY_ADD += drivers/char/ > >>> Для исошки вам нужно подождать пока udev загрузит нужный модуль и пока не >>> появится условный /dev/cdrom. Для этого вообще не нужно ничего грузить >>> руками (см test-pipeline-iso-squash). >>> >>> Возможно, понадобиться дополнительная команда, которая определит, что в >>> приводе есть диск и он правильный. Но это уже совсем другое. >> Как раз хочу сделать cdrom вместо waitdev, чтобы там же было сразу и >> mountfs, но ещё не приступал. > Это логично и вполне ожидаемо. > >> А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп >> для waitdev? > А какой у этого юскейс ? Например, чтобы ФС монтировалась только в read-only, а поверх уже строить оверлей. В общем-то такой же смысл, как у всех root*= > waitdev только ожидает появления устройства. Оно не монтируется. Для > mountfs наверно в этом есть смысл. Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs). >> Ведь сейчас waitdev позволяет указать только само устройство, >> подобно root=, но указать дополнительные параметры не получится. -- Best regards, Leonid Krivoshein.
31.03.2021 20:17, Alexey Gladkov пишет:
> On Thu, Apr 01, 2021 at 12:02:57AM +0700, Антон Мидюков wrote:
>> 31.03.2021 23:55, Alexey Gladkov пишет:
>>> [...]
>>> Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и
>>> указывать в PUT_FILES.
>>>
>>> Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно
>>> их искать руками. Для модулей работает:
>>>
>>> MODULES_TRY_ADD += drivers/char/
>> Это то, что нам надо! Не надо ничего проверять, добавлять каталоги так. Не знал, что так можно.
>> На конце обязательно должен быть '/' ?
> Это даже не строка. Это regexp [1], который будет применён к списку
> модулей. Слэш в конце гарантирует, что не будут положены char-foo-bar.ko
>
> [1] https://github.com/osboot/make-initrd/blob/master/features/add-modules/bin/put-modules#L48-L56
По ходу вспомнили про существование фич modules-* и в случае создания
LiveCD их как раз есть смысл сразу проверить. Там же отыскиваются всякие
MODULES_PATTERN_SETS += ... что не менее полезно, IMHO. Вот только сходу
не нашёл описания для предикатов вида alias: name: not-filename: итп,
хотя и так можно догадаться, но нет исчерпывающего списка.
--
Best regards,
Leonid Krivoshein.
31.03.2021 21:08, Leonid Krivoshein пишет: > > > 31.03.2021 20:17, Alexey Gladkov пишет: >> On Thu, Apr 01, 2021 at 12:02:57AM +0700, Антон Мидюков wrote: >>> 31.03.2021 23:55, Alexey Gladkov пишет: >>>> [...] >>>> Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и >>>> указывать в PUT_FILES. >>>> >>>> Также, чтобы положить какой-то подкаталог с модулями совершенно не >>>> нужно >>>> их искать руками. Для модулей работает: >>>> >>>> MODULES_TRY_ADD += drivers/char/ >>> Это то, что нам надо! Не надо ничего проверять, добавлять каталоги >>> так. Не знал, что так можно. >>> На конце обязательно должен быть '/' ? >> Это даже не строка. Это regexp [1], который будет применён к списку >> модулей. Слэш в конце гарантирует, что не будут положены char-foo-bar.ko >> >> [1] >> https://github.com/osboot/make-initrd/blob/master/features/add-modules/bin/put-modules#L48-L56 > > По ходу вспомнили про существование фич modules-* и в случае создания > LiveCD их как раз есть смысл сразу проверить. Там же отыскиваются > всякие MODULES_PATTERN_SETS += ... что не менее полезно, IMHO. Вот > только сходу не нашёл описания для предикатов вида alias: name: > not-filename: итп, хотя и так можно догадаться, но нет исчерпывающего > списка. > Ну вот, по той же ссылке и нашёл. :-) https://github.com/osboot/make-initrd/blob/master/features/add-modules/bin/put-modules#L121 -- Best regards, Leonid Krivoshein.
01.04.2021 01:03, Leonid Krivoshein пишет: > > > 31.03.2021 19:55, Alexey Gladkov пишет: >> On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: >>>> Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? >>>> Вы же знаете, что вы хотите ждать исошку. >>> Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd. >>> И конечно теперь пойдём ещё раз по пути PUT_FILES += ... >> Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и >> указывать в PUT_FILES. >> >> Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно >> их искать руками. Для модулей работает: >> >> MODULES_TRY_ADD += drivers/char/ >> >>>> Для исошки вам нужно подождать пока udev загрузит нужный модуль и пока не >>>> появится условный /dev/cdrom. Для этого вообще не нужно ничего грузить >>>> руками (см test-pipeline-iso-squash). >>>> >>>> Возможно, понадобиться дополнительная команда, которая определит, что в >>>> приводе есть диск и он правильный. Но это уже совсем другое. >>> Как раз хочу сделать cdrom вместо waitdev, чтобы там же было сразу и >>> mountfs, но ещё не приступал. >> Это логично и вполне ожидаемо. >> >>> А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп >>> для waitdev? >> А какой у этого юскейс ? > > Например, чтобы ФС монтировалась только в read-only, а поверх уже строить оверлей. В общем-то такой же смысл, как у всех root*= > > >> waitdev только ожидает появления устройства. Оно не монтируется. Для >> mountfs наверно в этом есть смысл. > > Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs). Мне кажется, лучше делать универсальный disk=UUID=<UUID>. Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас. > > >>> Ведь сейчас waitdev позволяет указать только само устройство, >>> подобно root=, но указать дополнительные параметры не получится. > -- С уважением, Антон Мидюков <antohami@basealt.ru>
On Thu, Apr 01, 2021 at 01:11:38AM +0700, Антон Мидюков wrote: > > Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom > > и объединит waitdev с первым moutfs (isofs). > Мне кажется, лучше делать универсальный disk=UUID=<UUID>. > Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас. Можно искать stage2 по _его_ хэшу, как это было сделано в propagator (соответствующий кусок в mkimage-profiles ищется по "rescue_hash", упоминал Лёне недавно). Это страхует от подсовывания/подхватывания левого stage2, но обходится в соответствующее кол-во I/O и вычислений (хорошо сочетается с _отсутствующим_ lowmem в случае пропагатора, т.к. всяко уже закэшировали). -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
On Wed, Mar 31, 2021 at 09:08:01PM +0300, Leonid Krivoshein wrote: > > > 31.03.2021 20:17, Alexey Gladkov пишет: > > On Thu, Apr 01, 2021 at 12:02:57AM +0700, Антон Мидюков wrote: > > > 31.03.2021 23:55, Alexey Gladkov пишет: > > > > [...] > > > > Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и > > > > указывать в PUT_FILES. > > > > > > > > Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно > > > > их искать руками. Для модулей работает: > > > > > > > > MODULES_TRY_ADD += drivers/char/ > > > Это то, что нам надо! Не надо ничего проверять, добавлять каталоги так. Не знал, что так можно. > > > На конце обязательно должен быть '/' ? > > Это даже не строка. Это regexp [1], который будет применён к списку > > модулей. Слэш в конце гарантирует, что не будут положены char-foo-bar.ko > > > > [1] https://github.com/osboot/make-initrd/blob/master/features/add-modules/bin/put-modules#L48-L56 > > По ходу вспомнили про существование фич modules-* и в случае создания LiveCD > их как раз есть смысл сразу проверить. Там же отыскиваются всякие > MODULES_PATTERN_SETS += ... что не менее полезно, IMHO. Вот только сходу не > нашёл описания для предикатов вида alias: name: not-filename: итп, хотя и > так можно догадаться, но нет исчерпывающего списка. Вот этого описания недостаточно ? https://github.com/osboot/make-initrd/tree/master/features/add-modules#pattern-sets -- Rgrds, legion
On Thu, Apr 01, 2021 at 01:11:38AM +0700, Антон Мидюков wrote: > >> waitdev только ожидает появления устройства. Оно не монтируется. Для > >> mountfs наверно в этом есть смысл. > > > > Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs). > > Мне кажется, лучше делать универсальный disk=UUID=<UUID>. Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас. Я же писал [1], что параметр у waitdev имеет тот же формат, что и root=*. То есть он умеет waitdev=LABEL=*, waitdev=UUID=* и т.д. [1] https://github.com/osboot/make-initrd/tree/master/features/pipeline#boot-parameters -- Rgrds, legion
31.03.2021 21:11, Антон Мидюков пишет: > 01.04.2021 01:03, Leonid Krivoshein пишет: >> >> 31.03.2021 19:55, Alexey Gladkov пишет: >>> On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: >>>>> Почему бы не сделать 'MODULES_LOAD += isofs' ? Зачем грузить всё ? >>>>> Вы же знаете, что вы хотите ждать исошку. >>>> Видимо здесь надо MODULES_ADD += ... т.е. чтобы он просто попал в initrd. >>>> И конечно теперь пойдём ещё раз по пути PUT_FILES += ... >>> Если ты указал модуль в MODULES_ADD, то нет нужды его искать самому и >>> указывать в PUT_FILES. >>> >>> Также, чтобы положить какой-то подкаталог с модулями совершенно не нужно >>> их искать руками. Для модулей работает: >>> >>> MODULES_TRY_ADD += drivers/char/ >>> >>>>> Для исошки вам нужно подождать пока udev загрузит нужный модуль и пока не >>>>> появится условный /dev/cdrom. Для этого вообще не нужно ничего грузить >>>>> руками (см test-pipeline-iso-squash). >>>>> >>>>> Возможно, понадобиться дополнительная команда, которая определит, что в >>>>> приводе есть диск и он правильный. Но это уже совсем другое. >>>> Как раз хочу сделать cdrom вместо waitdev, чтобы там же было сразу и >>>> mountfs, но ещё не приступал. >>> Это логично и вполне ожидаемо. >>> >>>> А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп >>>> для waitdev? >>> А какой у этого юскейс ? >> Например, чтобы ФС монтировалась только в read-only, а поверх уже строить оверлей. В общем-то такой же смысл, как у всех root*= >> >> >>> waitdev только ожидает появления устройства. Оно не монтируется. Для >>> mountfs наверно в этом есть смысл. >> Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs). > Мне кажется, лучше делать универсальный disk=UUID=<UUID>. Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас. Как раз с UUID'ом на CDROM сейчас проблема. Возможно sin@ об этом что-то знает, они тут недавно решали похожее для propagator'а. Плохо в этом понимаю, но возможно такой патч её вылечит? /lib/udev/rules.d/60-cdrom_id.rules ... -IMPORT{program}="cdrom_id --lock-media $devnode" +IMPORT{program}="sh -c 'modprobe isofs; cdrom_id --lock-media $devnode'" ... Иначе без MODULES_PRELOAD += isofs по UUID'ам действительно не находится, waitdev ждёт бесконечно. >>>> Ведь сейчас waitdev позволяет указать только само устройство, >>>> подобно root=, но указать дополнительные параметры не получится. -- Best regards, Leonid Krivoshein.
On Wed, Mar 31, 2021 at 09:03:49PM +0300, Leonid Krivoshein wrote:
> > > А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп
> > > для waitdev?
> > А какой у этого юскейс ?
>
> Например, чтобы ФС монтировалась только в read-only, а поверх уже строить
> оверлей. В общем-то такой же смысл, как у всех root*=
>
>
> > waitdev только ожидает появления устройства. Оно не монтируется. Для
> > mountfs наверно в этом есть смысл.
>
> Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит
> waitdev с первым moutfs (isofs).
Да не вопрос. Я примерно так и думал, что будут сделаны подобные команды
для использования в pipeline.
--
Rgrds, legion
31.03.2021 21:38, Alexey Gladkov пишет:
> On Thu, Apr 01, 2021 at 01:11:38AM +0700, Антон Мидюков wrote:
>>>> waitdev только ожидает появления устройства. Оно не монтируется. Для
>>>> mountfs наверно в этом есть смысл.
>>> Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs).
>> Мне кажется, лучше делать универсальный disk=UUID=<UUID>. Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас.
> Я же писал [1], что параметр у waitdev имеет тот же формат, что и root=*.
> То есть он умеет waitdev=LABEL=*, waitdev=UUID=* и т.д.
>
> [1] https://github.com/osboot/make-initrd/tree/master/features/pipeline#boot-parameters
В том и дело, что сейчас без предварительной загрузки модуля isofs
конструкция wiatdev=UUID=@UUID@ не отрабатывает. Кстати, интересно,
будет ли она отрабатывать на обычных локальных носителях, если их
файловые системы предварительно никто не загрузит? Ведь при обнаружении
раздела ext4 возможно загрузить модуль ext4 или нужно всё равно его
грузить предварительно?
--
Best regards,
Leonid Krivoshein.
31.03.2021 21:29, Alexey Gladkov пишет:
> On Wed, Mar 31, 2021 at 09:08:01PM +0300, Leonid Krivoshein wrote:
>> [...]
>>
>> По ходу вспомнили про существование фич modules-* и в случае создания LiveCD
>> их как раз есть смысл сразу проверить. Там же отыскиваются всякие
>> MODULES_PATTERN_SETS += ... что не менее полезно, IMHO. Вот только сходу не
>> нашёл описания для предикатов вида alias: name: not-filename: итп, хотя и
>> так можно догадаться, но нет исчерпывающего списка.
> Вот этого описания недостаточно ?
>
> https://github.com/osboot/make-initrd/tree/master/features/add-modules#pattern-sets
О, слона-то я и не заметил! :-)
--
Best regards,
Leonid Krivoshein.
31.03.2021 21:24, Michael Shigorin пишет: > On Thu, Apr 01, 2021 at 01:11:38AM +0700, Антон Мидюков wrote: >>> Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom >>> и объединит waitdev с первым moutfs (isofs). >> Мне кажется, лучше делать универсальный disk=UUID=<UUID>. >> Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас. > Можно искать stage2 по _его_ хэшу, как это было сделано > в propagator (соответствующий кусок в mkimage-profiles > ищется по "rescue_hash", упоминал Лёне недавно). Про эту фичу знаю "с начала времён", учёл в iso2stick. :-) Не думаю, что её стоит использовать для поиска подходящего stage2. Разве что по требованию каких-нибудь регуляторов в дополнении к... UUID'ов вполне достаточно их можно получать/генерить заранее. > Это страхует от подсовывания/подхватывания левого stage2, Вот да, она для дополнительной безопасности, но не для быстрого поиска. > но обходится в соответствующее кол-во I/O и вычислений > (хорошо сочетается с _отсутствующим_ lowmem в случае > пропагатора, т.к. всяко уже закэшировали). -- Best regards, Leonid Krivoshein.
31.03.2021 21:38, Alexey Gladkov пишет:
> On Thu, Apr 01, 2021 at 01:11:38AM +0700, Антон Мидюков wrote:
>>>> waitdev только ожидает появления устройства. Оно не монтируется. Для
>>>> mountfs наверно в этом есть смысл.
>>> Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs).
>> Мне кажется, лучше делать универсальный disk=UUID=<UUID>. Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас.
> Я же писал [1], что параметр у waitdev имеет тот же формат, что и root=*.
> То есть он умеет waitdev=LABEL=*, waitdev=UUID=* и т.д.
>
> [1] https://github.com/osboot/make-initrd/tree/master/features/pipeline#boot-parameters
>
Всё же я был неправ, грузится по UUID.
--
Best regards,
Leonid Krivoshein.
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --] 31.03.2021 19:55, Alexey Gladkov пишет: > On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: > [...] >> А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп >> для waitdev? > А какой у этого юскейс ? > > waitdev только ожидает появления устройства. Оно не монтируется. Для > mountfs наверно в этом есть смысл. > >> Ведь сейчас waitdev позволяет указать только само устройство, >> подобно root=, но указать дополнительные параметры не получится. В качестве "пробы пера" и консультации (пока не проверял) прикладываю первый патч. Собственно, вопрос в том, можно ли так делать и будет ли это работать? -- Best regards, Leonid Krivoshein. [-- Attachment #2: mountfs.patch --] [-- Type: text/x-patch, Size: 2313 bytes --] commit 2c91f793bde657bb0bbd57b14a49cc5e1728dd19 Author: Leonid Krivoshein <klark@altlinux.org> Date: Thu Apr 1 02:45:23 2021 +0300 pipeline/mountfs: add MOUNTFSOPTS= and MOUNTFSTYPE= parameters diff --git a/features/pipeline/README.md b/features/pipeline/README.md index c573163..fa3f9e3 100644 --- a/features/pipeline/README.md +++ b/features/pipeline/README.md @@ -16,11 +16,16 @@ the previous elements. - `pipeline=name[,name1][,name2]` - the main parameter that determines the order in which pipe elements are called. - `getimage` specifies an URL to fetch and mount. -- `mountfs` specifies a file to mount. -- `overlayfs` defines a list of elements to be combined. - `waitdev` describes the local device to wait. The format of this parameter is the same as `root=`. +## Optional additional parameters + +- `mountfs` specifies a file to mount. +- `mountfstype` specifies a filesystem type. +- `mountfsopts` specifies a mount options. +- `overlayfs` defines a list of elements to be combined. + The separator between the elements is a comma (`,`). The parameters can be specified more than once depending on how many times diff --git a/features/pipeline/data/etc/initrd/cmdline.d/pipeline b/features/pipeline/data/etc/initrd/cmdline.d/pipeline index 4200d57..eb4854e 100644 --- a/features/pipeline/data/etc/initrd/cmdline.d/pipeline +++ b/features/pipeline/data/etc/initrd/cmdline.d/pipeline @@ -3,3 +3,5 @@ register_array string GETIMAGE register_array string MOUNTFS register_array string OVERLAYFS register_array string WAITDEV +register_array string MOUNTFSOPTS +register_array string MOUNTFSTYPE diff --git a/features/pipeline/data/lib/pipeline/mountfs b/features/pipeline/data/lib/pipeline/mountfs index 138afa5..6833455 100755 --- a/features/pipeline/data/lib/pipeline/mountfs +++ b/features/pipeline/data/lib/pipeline/mountfs @@ -9,8 +9,10 @@ target="$(resolve_target "$param")" [ -n "$target" ] || fatal "unable to resolve: $param" -opts= -[ ! -c "$target" ] && [ ! -b "$target" ] || +fstype="$(get_parameter MOUNTFSTYPE)" + +opts="$(get_parameter MOUNTFSOPTS)" +[ ! -c "$target" ] && [ ! -b "$target" ] || [ -n "$opts" ] || opts='ro,loop' -run mount ${opts:+-o $opts} "$target" "$destdir" +run mount ${fstype:+-t $fstype} ${opts:+-o $opts} -- "$target" "$destdir"
01.04.2021 01:38, Alexey Gladkov пишет:
> On Thu, Apr 01, 2021 at 01:11:38AM +0700, Антон Мидюков wrote:
>>>> waitdev только ожидает появления устройства. Оно не монтируется. Для
>>>> mountfs наверно в этом есть смысл.
>>>
>>> Да, pipeline=cdrom,... как раз будет аналогом automatic=cdrom и объединит waitdev с первым moutfs (isofs).
>>
>> Мне кажется, лучше делать универсальный disk=UUID=<UUID>. Без UUID будет угадайка, вдруг мне повезёт, как у нас сейчас.
>
> Я же писал [1], что параметр у waitdev имеет тот же формат, что и root=*.
> То есть он умеет waitdev=LABEL=*, waitdev=UUID=* и т.д.
>
> [1] https://github.com/osboot/make-initrd/tree/master/features/pipeline#boot-parameters
>
Я знаю. Я здесь совсем не о том. Я пишу, что не надо делать аналог cdrom, нужно делать сразу аналог disk propagator'a.
Т.е. искать не только isofs, но вообще любую локальную файловую систему с заданным UUID или LABEL.
Хотелось бы, чтобы initrd понимал automatic=method:disk,uuid=<UUID>, раскрывал его в
root=pipeline pipeline=waitdev,mountfs,mountfs,overlayfs,rootfs waitdev=UUID=@UUID@ mountfs=dev
а параметр stage=<STAGENAME> в опцию mountfs=<STAGENAME>
Тогда переход с propagator на initrd можно было бы осуществить бесшовно.
И некоторые другие методы было бы также здорово преобразовывать из текущего синтаксиса propagator в синтаксис pipeline.
Так сказать, интерфейс пользователя хотелось бы оставить близким к прежнему.
--
С уважением, Антон Мидюков <antohami@basealt.ru>
On Thu, Apr 01, 2021 at 02:49:05AM +0300, Leonid Krivoshein wrote:
>
> 31.03.2021 19:55, Alexey Gladkov пишет:
> > On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote:
> > [...]
> > > А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп
> > > для waitdev?
> > А какой у этого юскейс ?
> >
> > waitdev только ожидает появления устройства. Оно не монтируется. Для
> > mountfs наверно в этом есть смысл.
> >
> > > Ведь сейчас waitdev позволяет указать только само устройство,
> > > подобно root=, но указать дополнительные параметры не получится.
>
> В качестве "пробы пера" и консультации (пока не проверял) прикладываю первый
> патч.
> Собственно, вопрос в том, можно ли так делать и будет ли это работать?
Ты не пробовал этот код с несколькими mountfs в pipeline.
В pipeline идея: В pipeline= перечислены стадии. Параметры для стадий
должны идти в том же порядке. Поэтому опциональные параметры не ложатся в
эту схему.
Я бы предложил синтаксис аналогичный ip=, где разные поля разделены
двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]]
--
Rgrds, legion
01.04.2021 12:02, Alexey Gladkov пишет:
> On Thu, Apr 01, 2021 at 02:49:05AM +0300, Leonid Krivoshein wrote:
>> 31.03.2021 19:55, Alexey Gladkov пишет:
>>> On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote:
>>> [...]
>>>> А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп
>>>> для waitdev?
>>> А какой у этого юскейс ?
>>>
>>> waitdev только ожидает появления устройства. Оно не монтируется. Для
>>> mountfs наверно в этом есть смысл.
>>>
>>>> Ведь сейчас waitdev позволяет указать только само устройство,
>>>> подобно root=, но указать дополнительные параметры не получится.
>> В качестве "пробы пера" и консультации (пока не проверял) прикладываю первый
>> патч.
>> Собственно, вопрос в том, можно ли так делать и будет ли это работать?
> Ты не пробовал этот код с несколькими mountfs в pipeline.
>
> В pipeline идея: В pipeline= перечислены стадии. Параметры для стадий
> должны идти в том же порядке. Поэтому опциональные параметры не ложатся в
> эту схему.
>
> Я бы предложил синтаксис аналогичный ip=, где разные поля разделены
> двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]]
Понятно, тогда конечно буду переделывать.
--
Best regards,
Leonid Krivoshein.
01.04.2021 12:02, Alexey Gladkov пишет: > On Thu, Apr 01, 2021 at 02:49:05AM +0300, Leonid Krivoshein wrote: >> 31.03.2021 19:55, Alexey Gladkov пишет: >>> On Wed, Mar 31, 2021 at 07:20:58PM +0300, Leonid Krivoshein wrote: >>> [...] >>>> А что вообще думаешь об аналогии всяких rootonly=, roottype=, rootro=, итп >>>> для waitdev? >>> А какой у этого юскейс ? >>> >>> waitdev только ожидает появления устройства. Оно не монтируется. Для >>> mountfs наверно в этом есть смысл. >>> >>>> Ведь сейчас waitdev позволяет указать только само устройство, >>>> подобно root=, но указать дополнительные параметры не получится. >> В качестве "пробы пера" и консультации (пока не проверял) прикладываю первый >> патч. >> Собственно, вопрос в том, можно ли так делать и будет ли это работать? > Ты не пробовал этот код с несколькими mountfs в pipeline. > > В pipeline идея: В pipeline= перечислены стадии. Параметры для стадий > должны идти в том же порядке. Поэтому опциональные параметры не ложатся в > эту схему. > > Я бы предложил синтаксис аналогичный ip=, где разные поля разделены > двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]] Вчера, наконец, получилось сделать минимально рабочее сцепление при загрузке с CDROM. А как тебе такая идея? diff --git a/data/bin/initrd-sh-functions b/data/bin/initrd-sh-functions index a56e872..a0b5634 100644 --- a/data/bin/initrd-sh-functions +++ b/data/bin/initrd-sh-functions @@ -35,6 +35,15 @@ get_dev() { '') return 1 ;; + cdrom:*) + [ "${ID_CDROM-}" = "1" ] || + return 1 + name="${name#cdrom:}" + name="${name:-/dev/sr0}" + ;; + esac + + case "$name" in UUID=*) [ "${ID_FS_UUID-}" = "${name#UUID=}" ] || return 1 Мне кажется, это позволит указывать waitdev=cdrom: чтобы загрузиться с любого CDROM или ограничивать загрузку только с CDROM. При этом, можно указать вполне конкретный CDROM: waitdev=cdrom:UUID=<uuid> -- Best regards, Leonid Krivoshein.
02.04.2021 20:46, Leonid Krivoshein пишет:
>
> + cdrom:*)
> + [ "${ID_CDROM-}" = "1" ] ||
> + return 1
>
Может даже лучше так:
[ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" = "iso9660" ] ||
--
Best regards,
Leonid Krivoshein.
01.04.2021 12:02, Alexey Gladkov пишет: > Я бы предложил синтаксис аналогичный ip=, где разные поля разделены > двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]] И ещё FSTYPE=... по аналогии можно сделать: diff --git a/data/bin/initrd-sh-functions b/data/bin/initrd-sh-functions index a56e872..0e433c6 100644 --- a/data/bin/initrd-sh-functions +++ b/data/bin/initrd-sh-functions @@ -33,10 +33,26 @@ get_dev() { case "$name" in '') return 1 ;; + CDROM:*) + [ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" = "iso9660" ] || + return 1 + name="${name#CDROM:}" + name="${name:-/dev/sr0}" + ;; + FSTYPE=*:?*) + name="${name#FSTYPE=}" + value="${name%%:*}" + [ "${ID_FS_TYPE-}" = "$value" ] || + return 1 + name="${name#*:}" + ;; + esac + + case "$name" in UUID=*) [ "${ID_FS_UUID-}" = "${name#UUID=}" ] || return 1 ;; LABEL=*) Пока просто посоветоваться... А ещё хотел спросить: в этой же get_dev() есть такая строка: [ "${MAJOR-}" = "$(( $value / 256 ))" ] && [ "${MINOR-}" = "$(( $value % 256 ))" ] || Но я не нашёл выше кода, который присваивал бы значение переменной $value. Тут точно нет ошибки? -- Best regards, Leonid Krivoshein.
On Fri, Apr 02, 2021 at 09:37:41PM +0300, Leonid Krivoshein wrote: > > 01.04.2021 12:02, Alexey Gladkov пишет: > > Я бы предложил синтаксис аналогичный ip=, где разные поля разделены > > двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]] > > И ещё FSTYPE=... по аналогии можно сделать: > > > diff --git a/data/bin/initrd-sh-functions b/data/bin/initrd-sh-functions > index a56e872..0e433c6 100644 > --- a/data/bin/initrd-sh-functions > +++ b/data/bin/initrd-sh-functions > @@ -33,10 +33,26 @@ get_dev() { > > case "$name" in > '') > return 1 > ;; > + CDROM:*) > + [ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" = > "iso9660" ] || > + return 1 > + name="${name#CDROM:}" > + name="${name:-/dev/sr0}" > + ;; > + FSTYPE=*:?*) > + name="${name#FSTYPE=}" > + value="${name%%:*}" > + [ "${ID_FS_TYPE-}" = "$value" ] || > + return 1 > + name="${name#*:}" > + ;; > + esac > + > + case "$name" in > UUID=*) > [ "${ID_FS_UUID-}" = "${name#UUID=}" ] || > return 1 > ;; > LABEL=*) > $ git grep '\<get_dev ' data/lib/uevent/filters/mountdev:21: get_dev dev "$fsdev" || data/lib/uevent/filters/resume:8:get_dev devresume "${RESUME-}" || features/luks/data/lib/uevent/filters/luks:31: get_dev devluks "$dev" && features/luks/data/lib/uevent/filters/luks:35: get_dev devluks "$DEVNAME" || features/luks/data/lib/uevent/filters/lukskeys:26: get_dev realdev "$keydev" || features/luks/data/lib/uevent/handlers/085-luks:32: get_dev realdev "$luksdev" features/luks/data/lib/uevent/handlers/085-luks:70: get_dev "$luksdev" || features/pipeline/data/lib/uevent/filters/pipeline-waitdev:13: if [ -n "$spec" ] && get_dev dev "$spec"; then Ты правда хочешь, чтобы во всех этих фичах появилась поддержка cdrom:* ? > Пока просто посоветоваться... > А ещё хотел спросить: в этой же get_dev() есть такая строка: > > [ "${MAJOR-}" = "$(( $value / 256 ))" ] && [ "${MINOR-}" = "$(( $value % 256 > ))" ] || > > Но я не нашёл выше кода, который присваивал бы значение переменной $value. > Тут точно нет ошибки? Ты прав. Это регрессия после коммита: 799fd42580f4a7321050bad98d35e97f33275e7f -- Rgrds, legion
03.04.2021 14:09, Alexey Gladkov пишет:
> On Fri, Apr 02, 2021 at 09:37:41PM +0300, Leonid Krivoshein wrote:
>> 01.04.2021 12:02, Alexey Gladkov пишет:
>>> Я бы предложил синтаксис аналогичный ip=, где разные поля разделены
>>> двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]]
>> И ещё FSTYPE=... по аналогии можно сделать:
>>
>>
>> diff --git a/data/bin/initrd-sh-functions b/data/bin/initrd-sh-functions
>> index a56e872..0e433c6 100644
>> --- a/data/bin/initrd-sh-functions
>> +++ b/data/bin/initrd-sh-functions
>> @@ -33,10 +33,26 @@ get_dev() {
>>
>> case "$name" in
>> '')
>> return 1
>> ;;
>> + CDROM:*)
>> + [ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" =
>> "iso9660" ] ||
>> + return 1
>> + name="${name#CDROM:}"
>> + name="${name:-/dev/sr0}"
>> + ;;
>> + FSTYPE=*:?*)
>> + name="${name#FSTYPE=}"
>> + value="${name%%:*}"
>> + [ "${ID_FS_TYPE-}" = "$value" ] ||
>> + return 1
>> + name="${name#*:}"
>> + ;;
>> + esac
>> +
>> + case "$name" in
>> UUID=*)
>> [ "${ID_FS_UUID-}" = "${name#UUID=}" ] ||
>> return 1
>> ;;
>> LABEL=*)
>>
> $ git grep '\<get_dev '
> data/lib/uevent/filters/mountdev:21: get_dev dev "$fsdev" ||
> data/lib/uevent/filters/resume:8:get_dev devresume "${RESUME-}" ||
> features/luks/data/lib/uevent/filters/luks:31: get_dev devluks "$dev" &&
> features/luks/data/lib/uevent/filters/luks:35: get_dev devluks "$DEVNAME" ||
> features/luks/data/lib/uevent/filters/lukskeys:26: get_dev realdev "$keydev" ||
> features/luks/data/lib/uevent/handlers/085-luks:32: get_dev realdev "$luksdev"
> features/luks/data/lib/uevent/handlers/085-luks:70: get_dev "$luksdev" ||
> features/pipeline/data/lib/uevent/filters/pipeline-waitdev:13: if [ -n "$spec" ] && get_dev dev "$spec"; then
>
> Ты правда хочешь, чтобы во всех этих фичах появилась поддержка cdrom:* ?
Пока CDROM нужен лишь одной фиче (последняя строка), но, вдруг ещё где
потребуется? Соответственно, варианта только два:
- либо предусмотреть в get_dev() возможность указывать префиксы a.k.a
CDROM: , FSTYPE: для всех, кто запрашивает get_dev().
- либо сделать обёртку типа get_pipeline_dev() и вызывать из неё
get_dev(), а обёртку вызывать из pipeline-waitdev:13
Мне больше нравится первый вариант, но я же советуюсь. По идее на
перечисленных "клиентов" эта "возможность" влиять не должна. Префиксы
позволяют дополнительно ограничить спецификацию, но никто же не
заставляет использовать эти префиксы там, где они не требуются. Но можно
и заюзать, например, так: resume=FSTYPE=swap:/dev/sdb3 и в таком случае
devresume получит значение только в том случае, если /dev/sdb3 является
SWAP-разделом. Таких префиксов можно и больше напридумывать.
--
Best regards,
Leonid Krivoshein.
03.04.2021 18:31, Leonid Krivoshein пишет:
>
> 03.04.2021 14:09, Alexey Gladkov пишет:
>> On Fri, Apr 02, 2021 at 09:37:41PM +0300, Leonid Krivoshein wrote:
>>> 01.04.2021 12:02, Alexey Gladkov пишет:
>>>> Я бы предложил синтаксис аналогичный ip=, где разные поля разделены
>>>> двоеточиями т.е. mountfs=<device>[:<fstype>[:<mountopts>]]
>>> И ещё FSTYPE=... по аналогии можно сделать:
>>>
>>>
>>> diff --git a/data/bin/initrd-sh-functions b/data/bin/initrd-sh-functions
>>> index a56e872..0e433c6 100644
>>> --- a/data/bin/initrd-sh-functions
>>> +++ b/data/bin/initrd-sh-functions
>>> @@ -33,10 +33,26 @@ get_dev() {
>>>
>>> case "$name" in
>>> '')
>>> return 1
>>> ;;
>>> + CDROM:*)
>>> + [ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" =
>>> "iso9660" ] ||
>>> + return 1
>>> + name="${name#CDROM:}"
>>> + name="${name:-/dev/sr0}"
>>> + ;;
>>> + FSTYPE=*:?*)
>>> + name="${name#FSTYPE=}"
>>> + value="${name%%:*}"
>>> + [ "${ID_FS_TYPE-}" = "$value" ] ||
>>> + return 1
>>> + name="${name#*:}"
>>> + ;;
>>> + esac
>>> +
>>> + case "$name" in
>>> UUID=*)
>>> [ "${ID_FS_UUID-}" = "${name#UUID=}" ] ||
>>> return 1
>>> ;;
>>> LABEL=*)
>>>
>> $ git grep '\<get_dev '
>> data/lib/uevent/filters/mountdev:21: get_dev dev "$fsdev" ||
>> data/lib/uevent/filters/resume:8:get_dev devresume "${RESUME-}" ||
>> features/luks/data/lib/uevent/filters/luks:31: get_dev devluks "$dev" &&
>> features/luks/data/lib/uevent/filters/luks:35: get_dev devluks "$DEVNAME" ||
>> features/luks/data/lib/uevent/filters/lukskeys:26: get_dev realdev "$keydev" ||
>> features/luks/data/lib/uevent/handlers/085-luks:32: get_dev realdev "$luksdev"
>> features/luks/data/lib/uevent/handlers/085-luks:70: get_dev "$luksdev" ||
>> features/pipeline/data/lib/uevent/filters/pipeline-waitdev:13: if [ -n "$spec" ] && get_dev dev "$spec"; then
>>
>> Ты правда хочешь, чтобы во всех этих фичах появилась поддержка cdrom:* ?
>
> Пока CDROM нужен лишь одной фиче (последняя строка), но, вдруг ещё где потребуется? Соответственно, варианта только два:
Да не нужен cdrom нам вообще.
--
С уважением, Антон Мидюков <antohami@basealt.ru>
On Sat, Apr 03, 2021 at 02:31:22PM +0300, Leonid Krivoshein wrote: > > $ git grep '\<get_dev ' > > data/lib/uevent/filters/mountdev:21: get_dev dev "$fsdev" || > > data/lib/uevent/filters/resume:8:get_dev devresume "${RESUME-}" || > > features/luks/data/lib/uevent/filters/luks:31: get_dev devluks "$dev" && > > features/luks/data/lib/uevent/filters/luks:35: get_dev devluks "$DEVNAME" || > > features/luks/data/lib/uevent/filters/lukskeys:26: get_dev realdev "$keydev" || > > features/luks/data/lib/uevent/handlers/085-luks:32: get_dev realdev "$luksdev" > > features/luks/data/lib/uevent/handlers/085-luks:70: get_dev "$luksdev" || > > features/pipeline/data/lib/uevent/filters/pipeline-waitdev:13: if [ -n "$spec" ] && get_dev dev "$spec"; then > > > > Ты правда хочешь, чтобы во всех этих фичах появилась поддержка cdrom:* ? > > Пока CDROM нужен лишь одной фиче (последняя строка), но, вдруг ещё где > потребуется? Соответственно, варианта только два: > > - либо предусмотреть в get_dev() возможность указывать префиксы a.k.a CDROM: > , FSTYPE: для всех, кто запрашивает get_dev(). > - либо сделать обёртку типа get_pipeline_dev() и вызывать из неё get_dev(), > а обёртку вызывать из pipeline-waitdev:13 Я как раз хотел предложить второй вариант. Если юскейсы появятся глобального применения, то можно будет этот код перенести в get_dev. > Мне больше нравится первый вариант, но я же советуюсь. По идее на > перечисленных "клиентов" эта "возможность" влиять не должна. Префиксы > позволяют дополнительно ограничить спецификацию, но никто же не заставляет > использовать эти префиксы там, где они не требуются. Но можно и заюзать, > например, так: resume=FSTYPE=swap:/dev/sdb3 и в таком случае devresume > получит значение только в том случае, если /dev/sdb3 является SWAP-разделом. > Таких префиксов можно и больше напридумывать. -- Rgrds, legion
03.04.2021 14:37, Антон Мидюков пишет:
> 03.04.2021 18:31, Leonid Krivoshein пишет:
>> [...]
>> Пока CDROM нужен лишь одной фиче (последняя строка), но, вдруг ещё где потребуется? Соответственно, варианта только два:
> Да не нужен cdrom нам вообще.
Согласен, что в перспективе, если ты реализуешь в m-p полноценную
поддержку генерации и передачи UUID для CDROM, то не нужен, согласен,
что давно пора отказаться от этой пагубной практики, использовать
"первый попавшийся CD-ROM или ISO-образ". Тем не менее, propagator так
умеет и до сего дня это основной способ загрузки LiveCD, пригодный для
большинства применений, и вылезающий боком только в очень специфичных
ситуациях с локальным подключением нескольких CD-ROM/образов.
--
Best regards,
Leonid Krivoshein.
03.04.2021 19:16, Leonid Krivoshein пишет: > > 03.04.2021 14:37, Антон Мидюков пишет: >> 03.04.2021 18:31, Leonid Krivoshein пишет: >>> [...] >>> Пока CDROM нужен лишь одной фиче (последняя строка), но, вдруг ещё где потребуется? Соответственно, варианта только два: >> Да не нужен cdrom нам вообще. > > Согласен, что в перспективе, если ты реализуешь в m-p полноценную поддержку генерации и передачи UUID для CDROM, то не нужен, согласен, что давно пора отказаться от этой пагубной практики, использовать "первый попавшийся CD-ROM или ISO-образ". Тем не менее, propagator так умеет и до сего дня это основной способ загрузки LiveCD, пригодный для большинства применений, и вылезающий боком только в очень специфичных ситуациях с локальным подключением нескольких CD-ROM/образов. > Сначала нужно реализовать в mkimage. Реализовано, но не заапстримлено. Бага: https://bugzilla.altlinux.org/show_bug.cgi?id=39855 Это не перспектива, это потребность сегодняшнего дня. На Байкале М, где iso изначально писали на SATA HDD/SSD, проблема вылезла в полный рост. Переходить на UUID нужно уже "вчера" :-) -- С уважением, Антон Мидюков <antohami@basealt.ru>
Hi Leonid!
On 04/02/2021, at 08:57:45 PM you wrote:
>
> 02.04.2021 20:46, Leonid Krivoshein пишет:
> >
> > + cdrom:*)
> > + [ "${ID_CDROM-}" = "1" ] ||
> > + return 1
> >
>
> Может даже лучше так:
>
> [ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" = "iso9660" ] ||
не надо так, FS_TYPE может быть и ext2 и udf и все что угодно вообще то.
--
WBR et al.
Приветствую, Константин!
04.04.2021 22:04, Konstantin Lepikhov пишет:
> Hi Leonid!
>
> On 04/02/2021, at 08:57:45 PM you wrote:
>
>> 02.04.2021 20:46, Leonid Krivoshein пишет:
>>> + cdrom:*)
>>> + [ "${ID_CDROM-}" = "1" ] ||
>>> + return 1
>>>
>> Может даже лучше так:
>>
>> [ "${ID_CDROM-}" = "1" ] || [ "${ID_FS_TYPE-}" = "iso9660" ] ||
> не надо так, FS_TYPE может быть и ext2 и udf и все что угодно вообще то.
Тут же "ИЛИ", а не "И".
Префикс "CDROM:" подразумевает, что загрузка должна идти:
- либо с физического носителя CD/DVD/BlueRay
- либо с их симулирующего в виртуальной среде устройства
- либо из откуда угодно смонтрованого ISO-образа с ФС ISO-9660
А чтобы грузиться вообще с чего угодно, достаточно этот префикс убрать.
P.S.: собрал task #268947 в качестве proof-of-concept, код может быть
нерабочий, начинаю отладку...
--
Best regards,
Leonid Krivoshein.