Bug 34985

(В ответ на комментарий №0)
> Внешним модулям ядра необходимо тестирование, которое не может произойти в
> хешере под юзером, поэтому есть идея создавать тестовое окружение в initrd и
> запускать его через qemu.
> 
> Для этого в make-initrd не хватает или не удобно сделано:
> 
> - Необходима возможность запуска make-initrd под юзером (скажем при опции
> --no-checks). Сейчас приходится подменять id на echo 0. (Пермишены на чтение
> /boot и /lib/modules будут сделаны rpm-build-kernel-perms хелпером, depmod
> отключен --no-depmod.)

Ок. Это можно сделать.

> - Необходима возможность добавлять внешние модули в initrd, находящиеся в
> произвольных дирах. Сейчас приходится класть модуль в /usr/src/mod/ и в
> confik.mk писать
> 
> KERNEL_MODULES = /usr/src/mod
> MODULES_ADD += xt_so.ko
> 
> тогда make-initrd находит, что у xt_so.ko есть зависимость x_tables и добавляет
> его. Однако, всё равно внутри initrd нельзя загрузить модуль так как там нет
> insmod, а modules.* не содержит упоминаний для xt_so.ko. Поэтому нельзя
> использовать modprobe. Я ещё даже не придумал как это решить.

Потому что depmod создаёт их только в /lib/modules/KVERSION. Позтому нет смысла менять путь в initrd.

> Я думал над вариантом сделать user readable/writabe копию /lib/modules (скажем
> в /usr/srs/lib/), но make-initrd не поддерживает смену basedir.

Сделайте /lib/modules user writabe.

> - Неудобно, что depinfo требуются modules.*.bin для работы, приходится
> вставлять их генерацию в хелпер.

Он использует libkmod. Это libkmod их использует.

> - PUT_DIRS добавляет диру стрипая префикс, а PUT_FILES оставляя, было бы
> удобнее, чтоб можно было указать в какое место initrd класть диру/файл. Хочется
> положить бинарник модуля не в произвольную диру, а в /lib/modules/*/misc (или
> extra/).

PUT_DIRS/PUT_FILES -- это хэлперы у которых есть определённый сюзкейс. Они нужны, чтобы просто добавлять файлы в образ. Для более сложных случаев они не подходят. Придумывать язык в этом месте будет неправильно. Если хочется что-то положить под другим именем, то это можно сделать в соответствующей цели без врапперов.

> - Нельзя положить в iproute2's бинарник ip через PUT_PROGS, его перекрывает
> busybox. (Он нужен чтоб сделать "сеть" через veth.)

Да, так было задумано. Раньше это не мешало. Как быстрое решение ip можно положить в другой каталог.

> - PUT_PROGS не может полностью добавить бинарник iptables так как не видит, что
> ему требуется /lib*/iptables/. Впрочем, это можно пофиксить через PUT_FILES +=
> /lib*/iptables/*.so

Это так и должно быть. Такие вещи на совести кладущего что-то в образ.

> - Не помешала бы feature запускающая фиксированный скрипт (точка входа в тесты)
> и после этого делающая shutdown системе, без таймаутов и прочего.

Положите в образ /sbin/init-bin с своим содержимым и этот файл заменит init в образе. Этим пользуется make-initrd-propagator.

Спасибо за ответ.

(В ответ на комментарий №1)
> > - Не помешала бы feature запускающая фиксированный скрипт (точка входа в тесты)
> > и после этого делающая shutdown системе, без таймаутов и прочего.
> 
> Положите в образ /sbin/init-bin с своим содержимым и этот файл заменит init в
> образе. Этим пользуется make-initrd-propagator.

Ок, но oneshot feature была бы предпочтительнее, чтоб не делать работу init
самому (держать такой ALT-specific скрипт инициализации в upstream мало
смысла). Хотя, может так и лучше.

(В ответ на комментарий №2)
> > Положите в образ /sbin/init-bin с своим содержимым и этот файл заменит init в
> > образе. Этим пользуется make-initrd-propagator.
> 
> Ок, но oneshot feature была бы предпочтительнее, чтоб не делать работу init
> самому (держать такой ALT-specific скрипт инициализации в upstream мало
> смысла). Хотя, может так и лучше.

Файл /sbin/init-bin не ALT-specific. Недавно это было настоящим init'ом и частью системы инициализации, а модуль make-initrd-propagator это заабьюзил, чтобы подменить init на себя. Я не хотел такого, но раз уж так случилось, то пусть уж используется.

При тестирования использую вот такую фичу/хак:

/people/legion/packages/make-initrd-hacker.git

для установленных в систему ядер. Для апстримных ядер и тестирования патчей к нему это несовсем подходит и я использую другой инструмент.

Для этой фичи я использую скрипт:

$ cat ./run-unfsd
/usr/sbin/unfsd -e "$cwd/exports" -d -n 9000 -m 9001 -p

$ cat "$cwd/exports"
/ 127.0.0.1(rw,insecure)

(In reply to comment #4)
> При тестирования использую вот такую фичу/хак:

Спасибо!

ps. Пытались заюзать 9p virtfs qemu, для того, чтоб загрузить "полную" систему из того что установлено в хешере (идея glebfm). Не вышло, так как при security_model=mapped-file - не работают симлинки, а без - всё равно не хватает пермишенов. Буду ещё думать на эту тему, чтоб расширить возможности тестирования в хешере под реальным рутом.

(В ответ на комментарий №5)
> (In reply to comment #4)
> > При тестирования использую вот такую фичу/хак:
> 
> Спасибо!
> 
> ps. Пытались заюзать 9p virtfs qemu, для того, чтоб загрузить "полную" систему
> из того что установлено в хешере (идея glebfm). Не вышло, так как при
> security_model=mapped-file - не работают симлинки, а без - всё равно не хватает
> пермишенов. Буду ещё думать на эту тему, чтоб расширить возможности
> тестирования в хешере под реальным рутом.

Для разработки ядра использую 9p и qemu, но без хэшера. Я сделал корманный враппер для Кирилла Шутемова:

https://github.com/legionus/vm

Он позволяет запускать ядро из дерева исходников с доступом к хостовой файловой системе откуда я запускаю тесты. Собственно make-initrd-hacher делает тоже самое, но на nfs, а vm у меня остался как запускалка тестов.

То что я обещал сделать вроде уже сделано и в сизифе.