spt при создании образов на x86_64 системе для i586 копирует внутрь чрута запускаемые файлы с хост-системы (mksquashfs, например). Соответственно они там не запускаются (чрут получается i586), что приводит к невозможности создавать какие-либо образы на x86_64 для i586. Крайне желательно сделать так, что бы spt был полностью независим от окружения. Например - устанавливать всё что ему необходимо для работы с "нуля" в отдельный чрут и использовать уже оттуда. так же просьба проверить SPT на работоспособность внутри виртуальных серверов без CAP_MKNOD. Устройства вполне можно создавать с помощью fakeroot.
По первому пункту я присоединяюсь - копировать динамически слинкованных ELFов из хост-системы в chroot нельзя. По второму пункту я думаю, что spt не занимается устройствами, их, наверное, создаёт hasher-priv.
2Lakostis: пунт 1 - в твоём GIT не исправлено. Я там сейчас наблюдаю "cp -a /sbin/mksquashfs $chroot/.host/". И это относится ко многим другим утилитам. И забери плз из моего репозитария мелкие фиксы на предмет юзабилити аргументов командной строки. Без бутылки не смог разобраться, что для инициализации профайла нужно дать парамет -P (написано что он дефолтный в "default"). Там ещё пару ляпов исправлено (например запуск без параметров - сразу вывод help) 2ldv: spt сейчас экспортирует переменную makedev_console, наверное это она и управляет поведением hasher-priv. Если честно, я не проверял на результат работы spt без выставления этой переменной. Подозреваю что что-то работать не будет.
Гражжне, а это не дуп ли #10047?
Да, дуп.. но IMHO здесь более корретный репорт. т.е. - ту можно закрыть как дуп этой.
*** Bug 10047 has been marked as a duplicate of this bug. ***
> так же просьба проверить SPT на работоспособность внутри виртуальных серверов > без CAP_MKNOD. Антон, мы потратили весь вечер пятницы на выяснения этого вопроса. Вкратце если - виновата довольно странная (скажем мягко) реализация xmknod в hasher-priv. Падает с руганью на CAP_MKNOD и вообще пытается делать mknod оно в момент hsh --initroot со включенным параметром makedev_console. Помогает либо выключение его - этого параметра (пролоббировано его включение, со слов Гоши, было mouse@, для чего-то он там требовался в терминальном проекте), либо в противном случае начинает выполняться xmknod в hasher-priv, создавая /dev/console в чруте. Работает он так: если есть реальный /dev/console - он делает хардлинк на него из чрута. Если нет - пытается делать вызов mknod и создавать реальное устройство. В OpenVZ есть свой /dev/console (эмулируемый), поэтому все нормально - xmknod делает этот хардлинк и все работает. В vserver, по крайней мере в том, что показывал Зерг, /dev/console нет - он поэтому проваливается до mknod и падает с ошибкой, что вызвать такое нельзя. Решений 2: отключить makedev_console или создать в vserver /dev/console (есть подозрение, что пойдет что угодно, вплоть до просто пустого файла, например). Как совсем хорошее решение - спросить автора hasher-priv, чем обусловлено такое странное поведение xmknod и нельзя ли сделать его чуть менее непонятным?
(In reply to comment #6) > > так же просьба проверить SPT на работоспособность внутри виртуальных серверов > > без CAP_MKNOD. > > Антон, мы потратили весь вечер пятницы на выяснения этого вопроса. Вкратце если > - виновата довольно странная (скажем мягко) реализация xmknod в hasher-priv. > а что в ней странного? Реализация блокировок на основе CAP_ в vserver просто идиотская.
2greycat: ничего странного в работе xmknod в hasher-priv я не вижу, а вот описание этой работы мне понравилось, если не трудно, отформатируй его для включения в документацию, пожалуйста. Что касается /dev/console, то это устройство потребовалось mouse'у для live cd. Если оно не нужно, то не надо экспортировать makedev_console, но оно, скорее всего, нужно. Что касается OpenVZ vs VServer, то они применяют разные подходы к проверке прав доступа: ovz проверяет права при попытке работать через файл устройства, а vs - при попытке создать файл устройства. Подход ovz более удобен, позволяя создавать файлы устройств, не используемые для open().
(In reply to comment #6) <skip> > В vserver, по крайней мере в том, что показывал Зерг, /dev/console нет - он > поэтому проваливается до mknod и падает с ошибкой, что вызвать такое нельзя. > > Решений 2: отключить makedev_console или создать в vserver /dev/console (есть > подозрение, что пойдет что угодно, вплоть до просто пустого файла, например). кстати, можно повесить FR на util-vserver. Поскольку: diff -uNpar --minimal util-vserver-0.30.210.orig/distrib/altSisyphus/devs util-vserver-0.30.210/distrib/altSisyphus/de --- util-vserver-0.30.210.orig/distrib/altSisyphus/devs 1970-01-01 03:00:00 +0300 +++ util-vserver-0.30.210/distrib/altSisyphus/devs 2006-03-25 15:09:27 +0300 @@ -0,0 +1,8 @@ +null c 1 3 666 +zero c 1 5 666 +full c 1 7 666 +random c 1 8 644 +urandom c 1 9 644 +tty c 5 0 666 +tty12 c 4 12 666 +ptmx c 5 2 666 - ничто не мешает добавить туда console.
И всё-таки /dev/console - это вторично. Первично - работа на x86_64 для i586. Кстати, Миша... сборка инсталлера в spt сломана похоже кардинально - её надо чинить.
Сборка installer'а в текущей версии spt уже починена. Как и cross-сборка i586 на x86_64.
Закрываю за давностью.
