10069 2006-10-02 10:01:33 +0400 spt не работает на x86_64 для i586 2007-02-12 15:50:14 +0300 1 1 4 Development Sisyphus spt unstable all Linux CLOSED FIXED P5 blocker --- 1 rider mike greycat ldv mike zerg qa-sisyphus oldest_to_newest 40987 0 rider 2006-10-02 10:01:33 +0400 spt при создании образов на x86_64 системе для i586 копирует внутрь чрута запускаемые файлы с хост-системы (mksquashfs, например). Соответственно они там не запускаются (чрут получается i586), что приводит к невозможности создавать какие-либо образы на x86_64 для i586. Крайне желательно сделать так, что бы spt был полностью независим от окружения. Например - устанавливать всё что ему необходимо для работы с "нуля" в отдельный чрут и использовать уже оттуда. так же просьба проверить SPT на работоспособность внутри виртуальных серверов без CAP_MKNOD. Устройства вполне можно создавать с помощью fakeroot. 40995 1 ldv 2006-10-02 13:39:32 +0400 По первому пункту я присоединяюсь - копировать динамически слинкованных ELFов из хост-системы в chroot нельзя. По второму пункту я думаю, что spt не занимается устройствами, их, наверное, создаёт hasher-priv. 40999 2 rider 2006-10-02 14:14:59 +0400 2Lakostis: пунт 1 - в твоём GIT не исправлено. Я там сейчас наблюдаю "cp -a /sbin/mksquashfs $chroot/.host/". И это относится ко многим другим утилитам. И забери плз из моего репозитария мелкие фиксы на предмет юзабилити аргументов командной строки. Без бутылки не смог разобраться, что для инициализации профайла нужно дать парамет -P (написано что он дефолтный в "default"). Там ещё пару ляпов исправлено (например запуск без параметров - сразу вывод help) 2ldv: spt сейчас экспортирует переменную makedev_console, наверное это она и управляет поведением hasher-priv. Если честно, я не проверял на результат работы spt без выставления этой переменной. Подозреваю что что-то работать не будет. 41070 3 mike 2006-10-03 11:15:56 +0400 Гражжне, а это не дуп ли #10047? 41076 4 rider 2006-10-03 11:39:26 +0400 Да, дуп.. но IMHO здесь более корретный репорт. т.е. - ту можно закрыть как дуп этой. 41078 5 rider 2006-10-03 11:40:02 +0400 *** Bug 10047 has been marked as a duplicate of this bug. *** 41089 6 greycat 2006-10-03 15:29:37 +0400 > так же просьба проверить 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 и нельзя ли сделать его чуть менее непонятным? 41092 7 lakostis 2006-10-03 16:10:03 +0400 (In reply to comment #6) > > так же просьба проверить SPT на работоспособность внутри виртуальных серверов > > без CAP_MKNOD. > > Антон, мы потратили весь вечер пятницы на выяснения этого вопроса. Вкратце если > - виновата довольно странная (скажем мягко) реализация xmknod в hasher-priv. > а что в ней странного? Реализация блокировок на основе CAP_ в vserver просто идиотская. 41093 8 ldv 2006-10-03 16:21:51 +0400 2greycat: ничего странного в работе xmknod в hasher-priv я не вижу, а вот описание этой работы мне понравилось, если не трудно, отформатируй его для включения в документацию, пожалуйста. Что касается /dev/console, то это устройство потребовалось mouse'у для live cd. Если оно не нужно, то не надо экспортировать makedev_console, но оно, скорее всего, нужно. Что касается OpenVZ vs VServer, то они применяют разные подходы к проверке прав доступа: ovz проверяет права при попытке работать через файл устройства, а vs - при попытке создать файл устройства. Подход ovz более удобен, позволяя создавать файлы устройств, не используемые для open(). 41094 9 lakostis 2006-10-03 16:43:05 +0400 (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. 41097 10 rider 2006-10-03 17:39:48 +0400 И всё-таки /dev/console - это вторично. Первично - работа на x86_64 для i586. Кстати, Миша... сборка инсталлера в spt сломана похоже кардинально - её надо чинить. 41716 11 lakostis 2006-10-26 02:01:07 +0400 Сборка installer'а в текущей версии spt уже починена. Как и cross-сборка i586 на x86_64. 45262 12 lakostis 2007-02-12 00:47:56 +0300 Закрываю за давностью.