| [SOLVED] openvz на LiveCD -- что-то с правами MS_NOUSER [message #10607] |
Sat, 24 February 2007 03:50  |
|
|
При попытке использовать openvz-028.015 как ядро для загрузки с ISO столькнулся с проблемой, что UNIONFS не может вывести перечень каталогов, объединенных в одно целое.
То есть команда
cat /proc/mounts
вызывает oops внутри unionfs. Раскопки показали, что проблема в функии __d_path() файла dcache.c ядра openvz. А именно в строчках
if (!(oldvfsmnt->mnt_sb->s_flags & MS_NOUSER))
return ERR_PTR(-EINVAL);
Если их вырезать, то все работает.
UNIONFS на livecd используется в качестве корневой FS.
Вопрос: что сия прооверка означает и как поправить unionfs чтоб она правильно флаги выставляла?
[Updated on: Sun, 04 March 2007 07:11] Report message to a moderator |
|
|
|
|
|
|
|
| Re: openvz на LiveCD -- что-то с правами MS_NOUSER [message #10680 is a reply to message #10607] |
Mon, 26 February 2007 13:06  |
Vasily Tarasov
Messages: 1345
Registered: January 2006
|
Senior Member |
|
|
Здравствуйте, Сергей,
Если я правильно понимаю, вы подпатчили OpenVZ ядро, чтобы оно поддерживало unionfs. А код внутри unionfs не делает проверку на возврат функции __d_path(.), в результате, когда выполняется условие !(oldvfsmnt->mnt_sb->s_flags & MS_NOUSER) происходит Oops.
Я вас правильно понял?
Если да, то вам, во-первых, стоит сообщить разработчикам unionfs об этой досадной ошибке =) Они должны проверять возврат этой функции.
Во-вторых, что касается проверки:
oldvfsmnt->mnt_sb->s_flags & MS_NOUSER
там есть такой коммент:
+ * We traversed the tree upward and reached a root, but the given
+ * lookup terminal point wasn't encountered. It means either that the
+ * dentry is out of our scope or belongs to an abstract space like
+ * sock_mnt or pipe_mnt. Check for it.
+ *
+ * There are different options to check it.
+ * We may assume that any dentry tree is unreachable unless it's
+ * connected to `root' (defined as fs root of init aka child reaper)
+ * and expose all paths that are not connected to it.
+ * The other option is to allow exposing of known abstract spaces
+ * explicitly and hide the path information for other cases.
+ * This approach is more safe, let's take it. 2001/04/22 SAW
+ */
Т.е. из VE разрешены быть видимыми только ФС:
1) примонтированные в VE
2) те, у которых ноги растут не из VE и при этом они "особые" (ramfs, shmemfs, ramfs, libfs...)
[Updated on: Mon, 26 February 2007 13:07] Report message to a moderator |
|
|
|
| Re: openvz на LiveCD -- что-то с правами MS_NOUSER [message #10739 is a reply to message #10678] |
Tue, 27 February 2007 16:42 |
|
|
| dev wrote on Mon, 26 February 2007 07:43 |
сия проверка
как правильно пофиксить: подпереть unionfs код, чтобы он проверял код ошибки d_path() и пропускал такой mount.
|
Приделать в код UNIONFS проверку на предмет валидности указателя -- святое. Однако что смущает: пропускаем мы такой mount и в выводимой информации отсутствует инфа о подмонтированной squashfs (reas-only система). А выкидывает из ядра OPENVZ указанную проверку -- и все показывается как надо и проблем нет.
Мож проверка не совсем корректна?
|
|
|
|
|
|
| Re: openvz на LiveCD -- что-то с правами MS_NOUSER [message #10742 is a reply to message #10680] |
Tue, 27 February 2007 16:59 |
|
|
Т.е. из VE разрешены быть видимыми только ФС:
1) примонтированные в VE
2) те, у которых ноги растут не из VE и при этом они "особые" (ramfs, shmemfs, ramfs, libfs...)
До использования VE вроде дело не доходит. Просто openvz используется как обычное ядро при загрузке с CDROM. При этом происходят манипуляции с путями ранее подмонтированных систем. Сама UNIONFS становится корневой, а подмонтированные системы уходят куда-то вглубь.
Может стартовая squashfs тоже особая? Или Unionfs неправильно с флагами манипулирует?
Да, unionfs я практически не правил: только то что здесь в форуме уже пролетало
- if (!permission(hidden_dir, MAY_WRITE | MAY_EXEC, NULL))
+ if (!permission(hidden_dir, MAY_WRITE | MAY_EXEC, NULL, NULL))
|
|
|
|
|
|
| Re: openvz на LiveCD -- что-то с правами MS_NOUSER [message #10744 is a reply to message #10741] |
Tue, 27 February 2007 17:16 |
|
|
|
Чисто squashfs без unionfs прооблем не вызывает (когда корень / остается в initramfs). Проблема -- когда unionfs станоится корнем, то есть / есть на самом деле unionfs с ФС внутри. Подозреваю, что с ramdisk внутри unionfs тоже бы проблемы были но он проскакивает проверку как "особая система"
|
|
|
|
| Re: openvz на LiveCD -- что-то с правами MS_NOUSER [message #10745 is a reply to message #10743] |
Tue, 27 February 2007 17:30 |
|
|
| dev wrote on Tue, 27 February 2007 12:14 |
полагаю что u
Вы готовите LiveCD? надеюсь, можно будет на него взглянуть :@)
|
LiveCD стандарный гентушный (GENTOO mini-cd), только ядро не gentoo-sources, а openvz-sources.
Если указанную проверку выкинуть -- внутри VE мы сможем увидать не только свое ?
|
|
|
|
|
|
|
|
|
|
| [SOLVED] openvz на LiveCD -- что-то с правами MS_NOUSER [message #10812 is a reply to message #10678] |
Sun, 04 March 2007 07:08 |
|
|
Как выяснилось, проблема с initramfs от GENTOO. Точнее как там на данный момент реализована поддержка UNIONFS. SQUASHFS образ сначала монтируется на каталоге /newroot/mnt/live (точно не помню), а потом корнем делается unionfs, в которой /newroot каталога уже нет.
В SLAX squashfs доступен и после того, как корнем становится UNIONFS, причем по тому же пути.
RESUME:
openvz только помог выявить такую странную реализацию. К разработчикам unionfs отправлен рапорт об необходимости проверять код возврата функции d_path()
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
