Bug 21859

Уф.  Сразу-то сложно было? :)

Если несрочно, то погоди, я постараюсь добраться до проверки для начала 2.6.27-tmc-tc-alt6 на предмет регрессов.  Если срочно -- скажи.

(В ответ на комментарий №1)
> Уф.  Сразу-то сложно было? :)

Дык не сообразил сходу, чего мне не хватает для полного счастья :)

Я, кстати, даже спрашивал как-то: отчего в ALTSP для решения проблемы r/o root используется tmpfs вместо aufs - но никто не ответил :(

> Если несрочно, то погоди, я постараюсь добраться до проверки для начала
> 2.6.27-tmc-tc-alt6 на предмет регрессов.  Если срочно -- скажи.

Потерплю

Так, alt6 у меня работает вроде бы не хуже alt5 (и с autoload тоже теперь порядок).

2 led: у тебя случайно нет готового aufs для 2.6.27? :)

(В ответ на комментарий №3)
> Так, alt6 у меня работает вроде бы не хуже alt5 (и с autoload тоже теперь
> порядок).
> 
> 2 led: у тебя случайно нет готового aufs для 2.6.27? :)

Есть конечно. И aufs, и unionfs. И работают они они и по очереди, и одновременно.

Ожидается ли к понедельнику прогресс?

ping

2 led: а что значит есть? Я совсем не умею собирать альтовские ядра, но git-clone/gear-hsh я выполнить в состоянии. Есть ли, собственно, что выполнять или как сделать, чтоб было?

(В ответ на комментарий №6)
> ping
> 
> 2 led: а что значит есть?

Я отвечал на вопрос: "...у тебя случайно нет...?"
Мой ответ: "у меня есть".

> Я совсем не умею собирать альтовские ядра, но
> git-clone/gear-hsh я выполнить в состоянии. Есть ли, собственно, что выполнять
> или как сделать, чтоб было?

Я так думаю, что обратится к мейнтейнеру, обосновав необходимость aufs именно в tc-ядре (я, напрмер, не знаю зачем оно вам там)

(In reply to comment #6)
> ping
pong

> 2 led: а что значит есть? Я совсем не умею собирать альтовские ядра
Вот мои рабочие заметки, по которым всё и собиралось:
http://www.altlinux.org/Kernelnotes/mike

Модули: http://www.altlinux.org/Сборка_модулей_ядра

(In reply to comment #5)
> Ожидается ли к понедельнику прогресс?
Смотря какого года...

PS: тебе точно aufs и никак иначе?  Только отошёл от проведения конференции (это ещё очень быстро) и разгрёб чуточку хвостов по работе.

(В ответ на комментарий №8)
> (In reply to comment #6)
> > ping
> pong
> 
> > 2 led: а что значит есть? Я совсем не умею собирать альтовские ядра
> Вот мои рабочие заметки, по которым всё и собиралось:
> http://www.altlinux.org/Kernelnotes/mike
> 
> Модули: http://www.altlinux.org/Сборка_модулей_ядра

Спасибо, как припрет - попробую

> (In reply to comment #5)
> > Ожидается ли к понедельнику прогресс?
> Смотря какого года...
> 
> PS: тебе точно aufs и никак иначе?  Только отошёл от проведения конференции
> (это ещё очень быстро) и разгрёб чуточку хвостов по работе.

Угу, у меня довольно специфические чруты получаются, которые мне удобнее собирать отдельно средствами mkimage. Большая часть кода ALTSP при этом не используется (но я поглядываю туда временами), проблема r/o root решается с помощью aufs, ядро std-def, как ни странно, на имеющемся железе ведет себя в целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;)

(В ответ на комментарий №9)

> ядро std-def, как ни странно, на имеющемся железе ведет себя в
> целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;)

Зачем "съезжать" на tmc-tc? Это не универсальное ядро.

(В ответ на комментарий №10)
> (В ответ на комментарий №9)
> 
> > ядро std-def, как ни странно, на имеющемся железе ведет себя в
> > целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;)
> 
> Зачем "съезжать" на tmc-tc? Это не универсальное ядро.

Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно отдельно собранный аналогичным образом (mkimage) чрут.

(В ответ на комментарий №11)
> Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно
> отдельно собранный аналогичным образом (mkimage) чрут.

Так при чём тут ядро? Почему специализированное (причём специализированное явно не для ваших задач) tmc-tc, а не std-def?

(В ответ на комментарий №12)
> (В ответ на комментарий №11)
> > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно
> > отдельно собранный аналогичным образом (mkimage) чрут.
> 
> Так при чём тут ядро? Почему специализированное (причём специализированное явно
> не для ваших задач) tmc-tc, а не std-def?

(В ответ на комментарий №12)
> (В ответ на комментарий №11)
> > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно
> > отдельно собранный аналогичным образом (mkimage) чрут.
> 
> Так при чём тут ядро? Почему специализированное (причём специализированное явно
> не для ваших задач) tmc-tc, а не std-def?

Ну почему же специализированное не для моих задач? Я бы так не сказал судя по http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. Повторюсь: задачи аналогичны задачам, решаемым с помощью ALTSP, но клиентский чрут формируется другим (более удобным мне) способом. Этот способ некоторым даже снился - http://lists.altlinux.org/pipermail/ltsp-server/2008-May/001492.html - но потом, видимо, отпустило :) Меня же пока еще нет (тем более что пропагатор - не причина) ;)

(В ответ на комментарий №14)
> Ну почему же специализированное не для моих задач?

Тогда возвращаемся к нашим (или вашим?) баранам: ядро tmc - для тонких бездисковых клиентов. Зачем вам aufs на тонких бездисковых клиентах? Это просто вопрос, чтобы уточнить потребности - не более того.

> Я бы так не сказал судя по
> http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog.

А что по этому можно судить?

(В ответ на комментарий №15)
> (В ответ на комментарий №14)
> > Ну почему же специализированное не для моих задач?
> 
> Тогда возвращаемся к нашим (или вашим?) баранам: ядро tmc - для тонких
> бездисковых клиентов. Зачем вам aufs на тонких бездисковых клиентах? Это просто
> вопрос, чтобы уточнить потребности - не более того.

aufs мне для перемонтирования корня из r/o в r/w. Я в курсе, что в ALTSP обошлись без aufs, используя, как я понял, дополнительное монтирование нужных каталогов, размещенных на tmpfs - верно? Я уже спрашивал (в т.ч. чуть выше) о причинах этого решения - оно экономит какие-то ресурсы? Для быстрого решения проблемы и для последующей отладки aufs мне оказалось удобнее, тем более, что в live и rescue из m-p-d этот способ уже используется.

> > Я бы так не сказал судя по
> > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog.
> 
> А что по этому можно судить?

Пожалуй, ничего - это так, напомнить мечтавшему :)

> > > Я бы так не сказал судя по
> > > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog.
> > 
> > А что по этому можно судить?
> 
> Пожалуй, ничего - это так, напомнить мечтавшему :)

Э ... попутал ссылку :)

> > Я бы так не сказал судя по
> > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog.
> 
> А что по этому можно судить?

Ну как что - отключенные и включенные фичи по сравнению std-def

(В ответ на комментарий №16)
> (В ответ на комментарий №15)
> aufs мне для перемонтирования корня из r/o в r/w. Я в курсе, что в ALTSP
> обошлись без aufs, используя, как я понял, дополнительное монтирование нужных
> каталогов, размещенных на tmpfs - верно?

Не совсем.

> Я уже спрашивал (в т.ч. чуть выше) о
> причинах этого решения - оно экономит какие-то ресурсы?

Да.

> Для быстрого решения
> проблемы

Какой проблемы? Почему вы не указываете, в чём именно проблема?

> и для последующей отладки aufs мне оказалось удобнее, тем более, что в
> live и rescue из m-p-d этот способ уже используется.

Это не аргумент. Ещё раз повторяю: tmc-tc - это СПЕЦИАЛИЗИРОВАННОЕ ядро для ТОНКИХ БЕЗДИСКОВЫХ клиентов. Для других случаев стОит использовать ДРУГИЕ специализированное ядро или, за неимением такового, универсальное ядро.

Цели tmc-tc:
1) Минимальный размер (даже в ущерб 5% падения производительности)
2) Образание всего, что не нужно для поставленной задачи (для достижения п.1)
3) Избежание дэдлоков при сетевом свопе

Ядро tmc используется для запуска ТОЛЬКО X-сервера и минимального набора сервисов. Т.о. если у вас запускается что-то кроме вышеперечисленного, то ядро tmc-tc не только безсполезно, но и вредно

Ох, у нас с вами хроническое непонимание друг друга ... 

Устраивают меня цели tmc-tc и use case у меня в данном случае аналогичный. Не хватает всего лишь aufs. Проблема (о которой я "не говорю" :) ) - это перемонтирование корня из r/o в r/w, и проблема она потому, что способ, используемый в ALTSP, может и эффективнее с точки зрения экономии ресурсов, но мне неудобен.

(In reply to comment #9)
> Угу, у меня довольно специфические чруты получаются, которые мне удобнее
> собирать отдельно средствами mkimage.
Вообще есть желание втащить сборку чрута под mkimage, поскольку иначе не
сделать livecd'шку, да и каждый раз при установке делать одно и то же
(инвариантное относительно пакетной базы) смысла большого нет -- кроме разве
реюза RPMS.main и экономии сотни или двух мегабайт в образе.  Что уже CD не
спасёт, если openoffice оттуда не грохнуть, а на DVD запас пока есть.

Так что если что это получится обобщить -- буду рад, а раз тебе по сути не
особо-то и надо именно tmc-tc -- может, ну его? :)

(In reply to comment #19)
[да]

> Т.о. если у вас запускается что-то кроме вышеперечисленного,
> то ядро tmc-tc не только безсполезно, но и вредно
А вот с последним словом как $PACKAGER не могу согласиться.  Работает -- и ладно, специального вреда туда не закладывалось -- только отсутствие потенциальной пользы.  И кстати, ты ещё pulseaudio как минимум забыл упомянуть. :)

(В ответ на комментарий №21)
> (In reply to comment #9)
> > Угу, у меня довольно специфические чруты получаются, которые мне удобнее
> > собирать отдельно средствами mkimage.
> > Т.о. если у вас запускается что-то кроме вышеперечисленного,
> > то ядро tmc-tc не только безсполезно, но и вредно
> А вот с последним словом как $PACKAGER не могу согласиться.

Это твоё право - не соглашаться. Но использовать tmc-tc в качестве универсального - вредно. В том числе и из-за того, что пользователи начинают требовать от него универсальности и развешывать баги об отсутствующей в нём функциональности.

> Работает -- и
> ладно, специального вреда туда не закладывалось -- только отсутствие
> потенциальной пользы.  И кстати, ты ещё pulseaudio как минимум забыл упомянуть.
> :)

Не забыл. Читай внимательнее - "...и минимального набора сервисов"

Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и client/initramfs/scripts/ltsp_nbd.  Другое дело, что я сейчас NBD как штатный корень всё равно не использую...

PS: despam CC:

(В ответ на комментарий №23)
> Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и
> client/initramfs/scripts/ltsp_nbd.  Другое дело, что я сейчас NBD как штатный
> корень всё равно не использую...

nbd вместо nfs для корня - абсолютно ортогонально к aufs

(В ответ на комментарий №21)
> (In reply to comment #9)
> > Угу, у меня довольно специфические чруты получаются, которые мне удобнее
> > собирать отдельно средствами mkimage.
> Вообще есть желание втащить сборку чрута под mkimage, поскольку иначе не
> сделать livecd'шку, да и каждый раз при установке делать одно и то же
> (инвариантное относительно пакетной базы) смысла большого нет -- кроме разве
> реюза RPMS.main и экономии сотни или двух мегабайт в образе.  Что уже CD не
> спасёт, если openoffice оттуда не грохнуть, а на DVD запас пока есть.
> 
> Так что если что это получится обобщить -- буду рад, а раз тебе по сути не
> особо-то и надо именно tmc-tc -- может, ну его? :)

Ну как это ну его? ;) Я понимаю и не тороплю, собственно и сам может когда сделаю и проверю ощущения, если ты не доберешься. Просто сейчас на std-def есть проблемы с несколькими экземплярами Х и потреблением памяти nxclient'ом - просто пока вроде придумали, как обойтись без того и другого. 

А насчет обобщить - до того надо, как уже led@ упоминал, разрезать ltsp-server на собственно ltsp-server и ltsp-chroot-build c выделением некоего ltsp-common. 

И какие, кстати, технические причины делать livecd средствами mkimage? Делается ведь почти это сейчас без mkimage? Или цель - унификация инструментов и кода?

> (In reply to comment #19)
> [да]
> 
> > Т.о. если у вас запускается что-то кроме вышеперечисленного,
> > то ядро tmc-tc не только безсполезно, но и вредно
> А вот с последним словом как $PACKAGER не могу согласиться.  Работает -- и
> ладно, специального вреда туда не закладывалось -- только отсутствие
> потенциальной пользы.  И кстати, ты ещё pulseaudio как минимум забыл упомянуть.
> :)

да - мне оно пока не надо, но может позже и пригодится

(В ответ на комментарий №24)
> (В ответ на комментарий №23)
> > Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и
> > client/initramfs/scripts/ltsp_nbd.  Другое дело, что я сейчас NBD как штатный
> > корень всё равно не использую...
> 
> nbd вместо nfs для корня - абсолютно ортогонально к aufs

Именно - в моем случае aufs необходим и для загрузки с nfs

(В ответ на комментарий №22)
> (В ответ на комментарий №21)
> > (In reply to comment #9)
> > > Угу, у меня довольно специфические чруты получаются, которые мне удобнее
> > > собирать отдельно средствами mkimage.
> > > Т.о. если у вас запускается что-то кроме вышеперечисленного,
> > > то ядро tmc-tc не только безсполезно, но и вредно
> > А вот с последним словом как $PACKAGER не могу согласиться.
> 
> Это твоё право - не соглашаться. Но использовать tmc-tc в качестве
> универсального - вредно. В том числе и из-за того, что пользователи начинают
> требовать от него универсальности и развешывать баги об отсутствующей в нём
> функциональности.

Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;)

(В ответ на комментарий №26)
> Именно - в моем случае aufs необходим и для загрузки с nfs

Использование nbd или nfs в качестве RO-корня в этом плане ничем не отличается. Более того, я тестировал и nfs и nbd RO-корня - никаких отличий, которые могли бы потребовать aufs

(В ответ на комментарий №27)
> Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;)

Использовать aufs на тонком бездисковом клиенте - дорого. И нецелесообразно. Вы так и не указали, для чего не хватает mount, mount --bind

(В ответ на комментарий №29)
> (В ответ на комментарий №27)
> > Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;)
> 
> Использовать aufs на тонком бездисковом клиенте - дорого. И нецелесообразно. Вы
> так и не указали, для чего не хватает mount, mount --bind

В принципе хватает, только слишком много mount, mount --bind нужно. Все они локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите место локализации (я сходу не нашел, но возможно плохо искал) - и я подумаю, насколько трудоемко мне будет использовать аналогичный механизм (правда не только для бездисковых клиентов - aufs-то я выбрал именно как универсальный способ превращения r/o в r/w).

(В ответ на комментарий №30)
> > так и не указали, для чего не хватает mount, mount --bind
> 
> В принципе хватает, только слишком много mount, mount --bind нужно.

Зачем "много mount"? Достаточно одного.
А mount --bind - столько, сколько нужно.

> Все они
> локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите
> место локализации (я сходу не нашел, но возможно плохо искал)

/etc/rc.d/scripts/ltsp-client-bind-mounts - собственно, сам монтировщик
/etc/default/ltsp-client-setup - конфиг к нему

 - и я подумаю,
> насколько трудоемко мне будет использовать аналогичный механизм (правда не
> только для бездисковых клиентов - aufs-то я выбрал именно как универсальный
> способ превращения r/o в r/w).

"универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий бездисковый клиент"

(In reply to comment #25)
> И какие, кстати, технические причины делать livecd средствами mkimage?
Да сам livecd-то я сделать могу.  А вот ltsp-build-client как раз и сняли с использования hasher, поскольку выглядела установка пару лет назад "под капотом" как: создаём левого юзера, hasher-useradd, потом им собираем чрут, потом (кажется) растариваем с нужными правами.  То есть у нас на руках всё равно рут, а мы бегаем огородами через псевдопользователя.  Ну и во времена собирания образа при помощи spt пытаться это туда интегрировать хорошей идеей не показалось.

> Делается ведь почти это сейчас без mkimage?
Сейчас инсталятор (не livecd с LTSP) собирается mkimage, а вот чрут собирается после установки пакетной базы (каждый раз).

> Или цель - унификация инструментов и кода?
И это тоже.

(In reply to comment #29)
> Использовать aufs на тонком бездисковом клиенте - дорого.
А там не просто модуль, а ещё и статиком что-то зацепится? (для общего образования)

> И нецелесообразно.
Скажем так -- лично я бы всё равно предпочёл обождать, пока aufs в ядро примут (и для такого ядра будет доступен vm_deadlock patch или каким-то чудом его тоже интегрируют), поскольку сейчас есть и работает tmpfs.

(В ответ на комментарий №32)
> > Использовать aufs на тонком бездисковом клиенте - дорого.
> А там не просто модуль, а ещё и статиком что-то зацепится? (для общего
> образования)

Ну, вообще-то изначально только статиком, но я начил его собираться и работать модулем.

Дорого - в runtime. Зачем лишний оверхэд, когда можно обойтись обычным тривиальным стандартным bind'ом?

> > И нецелесообразно.
> Скажем так -- лично я бы всё равно предпочёл обождать, пока aufs в ядро примут
> (и для такого ядра будет доступен vm_deadlock patch или каким-то чудом его тоже
> интегрируют), поскольку сейчас есть и работает tmpfs.

Ты путаешь: tmpfs в любом случае придётся использовать - иначе куда ты будешь биндить тем же aufs'ом? Вот поэтому я и спрашиваю: почему не биндить с помощью стандартного mount --bind/--rbind, а заюзывать для этого ещё одну лишнюю сущность? чего не хватает в mount --bind?

(В ответ на комментарий №25)

> А насчет обобщить - до того надо, как уже led@ упоминал, разрезать ltsp-server
> на собственно ltsp-server и ltsp-chroot-build c выделением некоего ltsp-common. 

хочешь попилить? ;>
http://git.altlinux.org/people/prividen/packages/ltsp.git

> Зачем "много mount"? Достаточно одного.
> А mount --bind - столько, сколько нужно.
> 
> > Все они
> > локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите
> > место локализации (я сходу не нашел, но возможно плохо искал)
> 
> /etc/rc.d/scripts/ltsp-client-bind-mounts - собственно, сам монтировщик
> /etc/default/ltsp-client-setup - конфиг к нему

спасибо

>  - и я подумаю,
> > насколько трудоемко мне будет использовать аналогичный механизм (правда не
> > только для бездисковых клиентов - aufs-то я выбрал именно как универсальный
> > способ превращения r/o в r/w).
> 
> "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий
> бездисковый клиент"

Пожалуй. Но сейчас полезнее иметь _универсальный_ способ превращения r/o в r/w, который в т.ч. можно (пусть и с некоторыми накладными расходами) использовать и для бездискового тонкого клиента.

Поэтому я попробую прикрутить aufs и с вопросами пойду в devel-newbies@

> > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий
> > бездисковый клиент"
> 
> Пожалуй. Но сейчас полезнее ...

Уточню, что мне полезнее :)

(В ответ на комментарий №35)
> > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий
> > бездисковый клиент"
> 
> Пожалуй. Но сейчас полезнее иметь _универсальный_ способ превращения r/o в r/w,

Тогда вам нужно универсальное ядро.

> который в т.ч. можно (пусть и с некоторыми накладными расходами) использовать и
> для бездискового тонкого клиента.

Уриверсальное ядро добавляет "некоторые накладные расходы" при использовании на бездисковых тонких коиентах. "серебряной пули" нет :(

Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в универсальное ядро будет труднее.

Впрочем, утащить ваш feat-fs-aufs в tmc-tc у меня тоже сходу не вышло. Я втянул его из people/led/packages/kernel-image-2.6.27-tmc.git, добавил генерацию и использование соответствующего патча в .gear/rules в спеке, обновил kernel-source (из вашего же upstream) и бранчи патчей (fix-vm_deadlock и feat-fs-squashfs), перегенерил тэги, и в результате сборки получил:

fs/aufs/vfsub.c: In function 'vfsub_splice_to':
fs/aufs/vfsub.c:404: error: implicit declaration of function 'vfs_splice_to'
fs/aufs/vfsub.c: In function 'vfsub_splice_from':
fs/aufs/vfsub.c:417: error: implicit declaration of function 'vfs_splice_from'

Боюсь, что в devel-newbies@ мне предложат тянуть aufs из апстрима, а я уж было позарился на возможность сборки модулем, а не статиком. Может вы подскажете, чего ему может не хватать и собирается ли оно вообще так просто с 2.6.27.37?

(В ответ на комментарий №38)
> Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в
> универсальное ядро будет труднее.
> 
> Впрочем, утащить ваш feat-fs-aufs в tmc-tc у меня тоже сходу не вышло.

Потому что нужны ещё fix-fs-splice и fix-security. Без них не соберётся.

(В ответ на комментарий №38)
> Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в
> универсальное ядро будет труднее.

А зачем его тащить? fix-vm_deadlock нужен только для клиентов с сетевым свопом.

Вы всё-таки пытаетесь на^Wобмануть судьбу и отлить "серерянную пулю" (сделать одно ядро и для экспериментов, и для надёжной работы тонких бездисковых клиентов)?:) Удачи! Но я здесь вам не помошник.

Собрал в http://git.altlinux.org/people/enp/packages/kernel-image.git, однако обмануть судьбу и вправду пока не выходит - все глюки, что я списывал было на дедлоки при сетевом свопе, на месте :(

Собственно, сами глюки:

* Невозможно переключиться из Х обратно на любую из виртуальных консолей
* Зависание при выключении с руганью вида "/sbin/halt: Input/output error" - наблюдается исключительно в случаях загрузки с nbd

Причем и то, и другое зависит непонятно от чего - то воспроизводится, то нет.

В общем, фичреквест понятен, но смыслу его реализовывать не обнаружено.

Спасибо вам обоим за терпение и понимание.