21859 2009-10-07 14:22:03 +0400 aufs module 2009-10-30 12:31:18 +0300 1 1 4 Development Sisyphus kernel-image-tmc-tc unstable all Linux CLOSED WONTFIX P3 normal --- 15333 1 enp mike aspsk boris boyarsh led mike mithraen oddity prividen rider shrek silicium sin vitty vsu zerg qa-sisyphus oldest_to_newest 100990 0 enp 2009-10-07 14:22:03 +0400 Модуль aufs тоже неплохо бы добавить ;) 100999 1 mike 2009-10-07 16:00:41 +0400 Уф. Сразу-то сложно было? :) Если несрочно, то погоди, я постараюсь добраться до проверки для начала 2.6.27-tmc-tc-alt6 на предмет регрессов. Если срочно -- скажи. 101002 2 enp 2009-10-07 16:20:23 +0400 (В ответ на комментарий №1) > Уф. Сразу-то сложно было? :) Дык не сообразил сходу, чего мне не хватает для полного счастья :) Я, кстати, даже спрашивал как-то: отчего в ALTSP для решения проблемы r/o root используется tmpfs вместо aufs - но никто не ответил :( > Если несрочно, то погоди, я постараюсь добраться до проверки для начала > 2.6.27-tmc-tc-alt6 на предмет регрессов. Если срочно -- скажи. Потерплю 101011 3 mike 2009-10-07 17:55:59 +0400 Так, alt6 у меня работает вроде бы не хуже alt5 (и с autoload тоже теперь порядок). 2 led: у тебя случайно нет готового aufs для 2.6.27? :) 101012 4 led 2009-10-07 18:00:40 +0400 (В ответ на комментарий №3) > Так, alt6 у меня работает вроде бы не хуже alt5 (и с autoload тоже теперь > порядок). > > 2 led: у тебя случайно нет готового aufs для 2.6.27? :) Есть конечно. И aufs, и unionfs. И работают они они и по очереди, и одновременно. 101171 5 enp 2009-10-09 18:01:36 +0400 Ожидается ли к понедельнику прогресс? 101348 6 enp 2009-10-12 18:39:46 +0400 ping 2 led: а что значит есть? Я совсем не умею собирать альтовские ядра, но git-clone/gear-hsh я выполнить в состоянии. Есть ли, собственно, что выполнять или как сделать, чтоб было? 101350 7 led 2009-10-12 18:53:36 +0400 (В ответ на комментарий №6) > ping > > 2 led: а что значит есть? Я отвечал на вопрос: "...у тебя случайно нет...?" Мой ответ: "у меня есть". > Я совсем не умею собирать альтовские ядра, но > git-clone/gear-hsh я выполнить в состоянии. Есть ли, собственно, что выполнять > или как сделать, чтоб было? Я так думаю, что обратится к мейнтейнеру, обосновав необходимость aufs именно в tc-ядре (я, напрмер, не знаю зачем оно вам там) 101373 8 mike 2009-10-12 23:50:20 +0400 (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 и никак иначе? Только отошёл от проведения конференции (это ещё очень быстро) и разгрёб чуточку хвостов по работе. 101388 9 enp 2009-10-13 13:24:45 +0400 (В ответ на комментарий №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 - да вот незадача ... ;) 101398 10 led 2009-10-13 14:11:59 +0400 (В ответ на комментарий №9) > ядро std-def, как ни странно, на имеющемся железе ведет себя в > целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;) Зачем "съезжать" на tmc-tc? Это не универсальное ядро. 101401 11 enp 2009-10-13 14:27:45 +0400 (В ответ на комментарий №10) > (В ответ на комментарий №9) > > > ядро std-def, как ни странно, на имеющемся железе ведет себя в > > целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;) > > Зачем "съезжать" на tmc-tc? Это не универсальное ядро. Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно отдельно собранный аналогичным образом (mkimage) чрут. 101403 12 led 2009-10-13 14:31:36 +0400 (В ответ на комментарий №11) > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно > отдельно собранный аналогичным образом (mkimage) чрут. Так при чём тут ядро? Почему специализированное (причём специализированное явно не для ваших задач) tmc-tc, а не std-def? 101404 13 enp 2009-10-13 14:47:44 +0400 (В ответ на комментарий №12) > (В ответ на комментарий №11) > > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно > > отдельно собранный аналогичным образом (mkimage) чрут. > > Так при чём тут ядро? Почему специализированное (причём специализированное явно > не для ваших задач) tmc-tc, а не std-def? 101405 14 enp 2009-10-13 14:50:42 +0400 (В ответ на комментарий №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 - но потом, видимо, отпустило :) Меня же пока еще нет (тем более что пропагатор - не причина) ;) 101406 15 led 2009-10-13 14:56:48 +0400 (В ответ на комментарий №14) > Ну почему же специализированное не для моих задач? Тогда возвращаемся к нашим (или вашим?) баранам: ядро tmc - для тонких бездисковых клиентов. Зачем вам aufs на тонких бездисковых клиентах? Это просто вопрос, чтобы уточнить потребности - не более того. > Я бы так не сказал судя по > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. А что по этому можно судить? 101407 16 enp 2009-10-13 15:16:35 +0400 (В ответ на комментарий №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. > > А что по этому можно судить? Пожалуй, ничего - это так, напомнить мечтавшему :) 101408 17 enp 2009-10-13 15:18:20 +0400 > > > Я бы так не сказал судя по > > > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. > > > > А что по этому можно судить? > > Пожалуй, ничего - это так, напомнить мечтавшему :) Э ... попутал ссылку :) 101409 18 enp 2009-10-13 15:20:38 +0400 > > Я бы так не сказал судя по > > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. > > А что по этому можно судить? Ну как что - отключенные и включенные фичи по сравнению std-def 101425 19 led 2009-10-13 16:57:55 +0400 (В ответ на комментарий №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 не только безсполезно, но и вредно 101427 20 enp 2009-10-13 17:11:55 +0400 Ох, у нас с вами хроническое непонимание друг друга ... Устраивают меня цели tmc-tc и use case у меня в данном случае аналогичный. Не хватает всего лишь aufs. Проблема (о которой я "не говорю" :) ) - это перемонтирование корня из r/o в r/w, и проблема она потому, что способ, используемый в ALTSP, может и эффективнее с точки зрения экономии ресурсов, но мне неудобен. 101428 21 mike 2009-10-13 17:18:16 +0400 (In reply to comment #9) > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > собирать отдельно средствами mkimage. Вообще есть желание втащить сборку чрута под mkimage, поскольку иначе не сделать livecd'шку, да и каждый раз при установке делать одно и то же (инвариантное относительно пакетной базы) смысла большого нет -- кроме разве реюза RPMS.main и экономии сотни или двух мегабайт в образе. Что уже CD не спасёт, если openoffice оттуда не грохнуть, а на DVD запас пока есть. Так что если что это получится обобщить -- буду рад, а раз тебе по сути не особо-то и надо именно tmc-tc -- может, ну его? :) (In reply to comment #19) [да] > Т.о. если у вас запускается что-то кроме вышеперечисленного, > то ядро tmc-tc не только безсполезно, но и вредно А вот с последним словом как $PACKAGER не могу согласиться. Работает -- и ладно, специального вреда туда не закладывалось -- только отсутствие потенциальной пользы. И кстати, ты ещё pulseaudio как минимум забыл упомянуть. :) 101429 22 led 2009-10-13 17:25:05 +0400 (В ответ на комментарий №21) > (In reply to comment #9) > > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > > собирать отдельно средствами mkimage. > > Т.о. если у вас запускается что-то кроме вышеперечисленного, > > то ядро tmc-tc не только безсполезно, но и вредно > А вот с последним словом как $PACKAGER не могу согласиться. Это твоё право - не соглашаться. Но использовать tmc-tc в качестве универсального - вредно. В том числе и из-за того, что пользователи начинают требовать от него универсальности и развешывать баги об отсутствующей в нём функциональности. > Работает -- и > ладно, специального вреда туда не закладывалось -- только отсутствие > потенциальной пользы. И кстати, ты ещё pulseaudio как минимум забыл упомянуть. > :) Не забыл. Читай внимательнее - "...и минимального набора сервисов" 101431 23 mike 2009-10-13 17:32:43 +0400 Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и client/initramfs/scripts/ltsp_nbd. Другое дело, что я сейчас NBD как штатный корень всё равно не использую... PS: despam CC: 101432 24 led 2009-10-13 17:38:28 +0400 (В ответ на комментарий №23) > Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и > client/initramfs/scripts/ltsp_nbd. Другое дело, что я сейчас NBD как штатный > корень всё равно не использую... nbd вместо nfs для корня - абсолютно ортогонально к aufs 101433 25 enp 2009-10-13 17:48:34 +0400 (В ответ на комментарий №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 как минимум забыл упомянуть. > :) да - мне оно пока не надо, но может позже и пригодится 101434 26 enp 2009-10-13 17:49:57 +0400 (В ответ на комментарий №24) > (В ответ на комментарий №23) > > Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и > > client/initramfs/scripts/ltsp_nbd. Другое дело, что я сейчас NBD как штатный > > корень всё равно не использую... > > nbd вместо nfs для корня - абсолютно ортогонально к aufs Именно - в моем случае aufs необходим и для загрузки с nfs 101435 27 enp 2009-10-13 17:52:23 +0400 (В ответ на комментарий №22) > (В ответ на комментарий №21) > > (In reply to comment #9) > > > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > > > собирать отдельно средствами mkimage. > > > Т.о. если у вас запускается что-то кроме вышеперечисленного, > > > то ядро tmc-tc не только безсполезно, но и вредно > > А вот с последним словом как $PACKAGER не могу согласиться. > > Это твоё право - не соглашаться. Но использовать tmc-tc в качестве > универсального - вредно. В том числе и из-за того, что пользователи начинают > требовать от него универсальности и развешывать баги об отсутствующей в нём > функциональности. Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;) 101440 28 led 2009-10-13 18:40:48 +0400 (В ответ на комментарий №26) > Именно - в моем случае aufs необходим и для загрузки с nfs Использование nbd или nfs в качестве RO-корня в этом плане ничем не отличается. Более того, я тестировал и nfs и nbd RO-корня - никаких отличий, которые могли бы потребовать aufs 101441 29 led 2009-10-13 18:42:16 +0400 (В ответ на комментарий №27) > Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;) Использовать aufs на тонком бездисковом клиенте - дорого. И нецелесообразно. Вы так и не указали, для чего не хватает mount, mount --bind 101443 30 enp 2009-10-13 18:54:12 +0400 (В ответ на комментарий №29) > (В ответ на комментарий №27) > > Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;) > > Использовать aufs на тонком бездисковом клиенте - дорого. И нецелесообразно. Вы > так и не указали, для чего не хватает mount, mount --bind В принципе хватает, только слишком много mount, mount --bind нужно. Все они локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите место локализации (я сходу не нашел, но возможно плохо искал) - и я подумаю, насколько трудоемко мне будет использовать аналогичный механизм (правда не только для бездисковых клиентов - aufs-то я выбрал именно как универсальный способ превращения r/o в r/w). 101444 31 led 2009-10-13 19:24:22 +0400 (В ответ на комментарий №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" - не есть задача в рамках "тонкий бездисковый клиент" 101448 32 mike 2009-10-13 21:29:20 +0400 (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. 101454 33 led 2009-10-13 21:49:20 +0400 (В ответ на комментарий №32) > > Использовать aufs на тонком бездисковом клиенте - дорого. > А там не просто модуль, а ещё и статиком что-то зацепится? (для общего > образования) Ну, вообще-то изначально только статиком, но я начил его собираться и работать модулем. Дорого - в runtime. Зачем лишний оверхэд, когда можно обойтись обычным тривиальным стандартным bind'ом? > > И нецелесообразно. > Скажем так -- лично я бы всё равно предпочёл обождать, пока aufs в ядро примут > (и для такого ядра будет доступен vm_deadlock patch или каким-то чудом его тоже > интегрируют), поскольку сейчас есть и работает tmpfs. Ты путаешь: tmpfs в любом случае придётся использовать - иначе куда ты будешь биндить тем же aufs'ом? Вот поэтому я и спрашиваю: почему не биндить с помощью стандартного mount --bind/--rbind, а заюзывать для этого ещё одну лишнюю сущность? чего не хватает в mount --bind? 101485 34 prividen 2009-10-14 11:43:12 +0400 (В ответ на комментарий №25) > А насчет обобщить - до того надо, как уже led@ упоминал, разрезать ltsp-server > на собственно ltsp-server и ltsp-chroot-build c выделением некоего ltsp-common. хочешь попилить? ;> http://git.altlinux.org/people/prividen/packages/ltsp.git 101669 35 enp 2009-10-16 15:59:39 +0400 > Зачем "много 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@ 101670 36 enp 2009-10-16 16:20:15 +0400 > > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий > > бездисковый клиент" > > Пожалуй. Но сейчас полезнее ... Уточню, что мне полезнее :) 101672 37 led 2009-10-16 16:35:16 +0400 (В ответ на комментарий №35) > > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий > > бездисковый клиент" > > Пожалуй. Но сейчас полезнее иметь _универсальный_ способ превращения r/o в r/w, Тогда вам нужно универсальное ядро. > который в т.ч. можно (пусть и с некоторыми накладными расходами) использовать и > для бездискового тонкого клиента. Уриверсальное ядро добавляет "некоторые накладные расходы" при использовании на бездисковых тонких коиентах. "серебряной пули" нет :( 101676 38 enp 2009-10-16 17:15:30 +0400 Насколько я понимаю, тащить 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? 101688 39 led 2009-10-16 19:10:59 +0400 (В ответ на комментарий №38) > Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в > универсальное ядро будет труднее. > > Впрочем, утащить ваш feat-fs-aufs в tmc-tc у меня тоже сходу не вышло. Потому что нужны ещё fix-fs-splice и fix-security. Без них не соберётся. 101690 40 led 2009-10-16 19:17:20 +0400 (В ответ на комментарий №38) > Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в > универсальное ядро будет труднее. А зачем его тащить? fix-vm_deadlock нужен только для клиентов с сетевым свопом. Вы всё-таки пытаетесь на^Wобмануть судьбу и отлить "серерянную пулю" (сделать одно ядро и для экспериментов, и для надёжной работы тонких бездисковых клиентов)?:) Удачи! Но я здесь вам не помошник. 101863 41 enp 2009-10-20 14:58:21 +0400 Собрал в http://git.altlinux.org/people/enp/packages/kernel-image.git, однако обмануть судьбу и вправду пока не выходит - все глюки, что я списывал было на дедлоки при сетевом свопе, на месте :( Собственно, сами глюки: * Невозможно переключиться из Х обратно на любую из виртуальных консолей * Зависание при выключении с руганью вида "/sbin/halt: Input/output error" - наблюдается исключительно в случаях загрузки с nbd Причем и то, и другое зависит непонятно от чего - то воспроизводится, то нет. 102369 42 mike 2009-10-30 12:31:18 +0300 В общем, фичреквест понятен, но смыслу его реализовывать не обнаружено. Спасибо вам обоим за терпение и понимание.