Summary: | spt не работает на x86_64 для i586 | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Anton Farygin <rider> |
Component: | spt | Assignee: | Michael Shigorin <mike> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | blocker | ||
Priority: | P5 | CC: | greycat, ldv, mike, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Anton Farygin
2006-10-02 10:01:33 MSD
По первому пункту я присоединяюсь - копировать динамически слинкованных ELFов из хост-системы в chroot нельзя. По второму пункту я думаю, что spt не занимается устройствами, их, наверное, создаёт hasher-priv. 2Lakostis: пунт 1 - в твоём GIT не исправлено. Я там сейчас наблюдаю "cp -a /sbin/mksquashfs $chroot/.host/". И это относится ко многим другим утилитам. И забери плз из моего репозитария мелкие фиксы на предмет юзабилити аргументов командной строки. Без бутылки не смог разобраться, что для инициализации профайла нужно дать парамет -P (написано что он дефолтный в "default"). Там ещё пару ляпов исправлено (например запуск без параметров - сразу вывод help) 2ldv: spt сейчас экспортирует переменную makedev_console, наверное это она и управляет поведением hasher-priv. Если честно, я не проверял на результат работы spt без выставления этой переменной. Подозреваю что что-то работать не будет. Да, дуп.. но 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. Закрываю за давностью. |