Bug 10069 - spt не работает на x86_64 для i586
: spt не работает на x86_64 для i586
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/spt)
: unstable
: all Linux
: P5 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2006-10-02 10:01 by
Modified: 2007-02-12 15:50 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-10-02 10:01:33
spt при создании образов на x86_64 системе для i586 копирует внутрь чрута
запускаемые файлы с хост-системы (mksquashfs, например). Соответственно они там
не запускаются (чрут получается i586), что приводит к невозможности создавать
какие-либо образы на x86_64 для i586.

Крайне желательно сделать так, что бы spt был полностью независим от окружения.
Например - устанавливать всё что ему необходимо для работы с "нуля" в отдельный
чрут и использовать уже оттуда.
так же просьба проверить SPT на работоспособность внутри виртуальных серверов
без CAP_MKNOD. 

Устройства вполне можно создавать с помощью fakeroot.
------- Comment #1 From 2006-10-02 13:39:32 -------
По первому пункту я присоединяюсь - копировать динамически слинкованных ELFов
из
хост-системы в chroot нельзя.

По второму пункту я думаю, что spt не занимается устройствами, их, наверное,
создаёт hasher-priv.
------- Comment #2 From 2006-10-02 14:14:59 -------
2Lakostis:
пунт 1 - в твоём GIT не исправлено. Я там сейчас наблюдаю "cp -a
/sbin/mksquashfs $chroot/.host/". 
И это относится ко многим другим утилитам.


И забери плз из моего репозитария мелкие фиксы на предмет юзабилити аргументов
командной строки. Без бутылки не смог разобраться, что для инициализации
профайла нужно дать парамет -P (написано что он дефолтный в "default"). Там ещё
пару ляпов исправлено (например запуск без параметров - сразу вывод help)

2ldv: 
spt сейчас экспортирует переменную makedev_console, наверное это она и управляет
поведением hasher-priv. Если честно, я не проверял на результат работы spt без
выставления этой переменной. Подозреваю что что-то работать не будет.

------- Comment #3 From 2006-10-03 11:15:56 -------
Гражжне, а это не дуп ли #10047?
------- Comment #4 From 2006-10-03 11:39:26 -------
Да, дуп.. но IMHO здесь более корретный репорт. 

т.е. - ту можно закрыть как дуп этой.
------- Comment #5 From 2006-10-03 11:40:02 -------
*** Bug 10047 has been marked as a duplicate of this bug. ***
------- Comment #6 From 2006-10-03 15:29:37 -------
> так же просьба проверить 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 и нельзя ли сделать его чуть менее непонятным?
------- Comment #7 From 2006-10-03 16:10:03 -------
(In reply to comment #6)
> > так же просьба проверить SPT на работоспособность внутри виртуальных серверов
> > без CAP_MKNOD. 
> 
> Антон, мы потратили весь вечер пятницы на выяснения этого вопроса. Вкратце если
> - виновата довольно странная (скажем мягко) реализация xmknod в hasher-priv.
>
а что в ней странного? Реализация блокировок на основе CAP_ в vserver просто
идиотская.
------- Comment #8 From 2006-10-03 16:21:51 -------
2greycat: ничего странного в работе xmknod в hasher-priv я не вижу, а вот
описание этой работы мне понравилось, если не трудно, отформатируй его для
включения в документацию, пожалуйста.

Что касается /dev/console, то это устройство потребовалось mouse'у для live cd.
Если оно не нужно, то не надо экспортировать makedev_console, но оно, скорее
всего, нужно.

Что касается OpenVZ vs VServer, то они применяют разные подходы к проверке прав
доступа: ovz проверяет права при попытке работать через файл устройства, а vs -
при попытке создать файл устройства.  Подход ovz более удобен, позволяя
создавать файлы устройств, не используемые для open().
------- Comment #9 From 2006-10-03 16:43:05 -------
(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.
------- Comment #10 From 2006-10-03 17:39:48 -------
И всё-таки /dev/console - это вторично. Первично - работа на x86_64 для i586.

Кстати, Миша... сборка инсталлера в spt сломана похоже кардинально - её надо
чинить.
------- Comment #11 From 2006-10-26 02:01:07 -------
Сборка installer'а в текущей версии spt уже починена. Как и cross-сборка i586
на
x86_64.
------- Comment #12 From 2007-02-12 00:47:56 -------
Закрываю за давностью.