|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Alex Korchmar 2:5020/400 04 Dec 2006 01:00:14 To : Alexey Vissarionov Subject : Re: ТВ-тюнеp -------------------------------------------------------------------------------- Alexey Vissarionov <Alexey.Vissarionov@f545.n5020.z2.fidonet.org> wrote: AK>> беда в том, что лично я уже давно не тестирую ядреные патчи - мне AK>> нужно просто чтоб работало. Так вот чтоб работало - оно у RHEL/FC AK>> делается методом yum update. AV> Брррр... при чем здесь update, когда речь идет о пересборке AV> ядра, исходники которого поставляются в дистрибутиве? Hеужели update _обычно_ решает проблему, которую ты собираешься решать пересборкой. AV> `make menuconfig && make` уже считается "очень сильным колдунством"? просто бесполезной потерей времени (да еще чреватой риском вляпаться) AK>> (насколько я помню, цель затеи где я наступил на грабли была как AK>> раз обратная - штатное ядро оказалось собрано без поддержки himem AK>> вообще, что на четырехгиговой машине выглядело как-то не в кассу) AV> Hу дык это как раз упомянутый мной случай - патчить ничего не AV> надо, только пересобрать. ну да, только я этот случай интерпретирую иначе: не надо ставить дебиан. Во всяком случае, на более-менее серьезное железо. А то будешь, как лох, ядра пересобирать, пока настоящие пацаны уже бухают. AV> Хм... ну, свое отношение к дебилиану (ага!) и аналогичным поделкам я уже AV> неоднократно озвучивал - именно за offtopic way я их и не люблю. какой же это offtopic? (хотя, да, XP же тоже только в 64бит версии может что-то разумное сделать в 4G) AV>>> Какой нахрен пакет? Ядро - не userland, его в пакет засовывать не AV>>> надо. AK>> почему не надо-то? Чтобы потом вместо rpm -F AV> Кстати, рекомендую пользовать -U, ибо в этом случае меньше шансов угробить не вижу разницы. F интересна тем, что не ставит то, чего у тебя нет. AV> существующий пакет, если новый накатится криво (например, при смене major AV> version number). в RHEL/FC не принято менять не то что major, а даже и minor version. Hайденные дырки затыкают путем бэкпорта. Опять таки - на то оно и дистрибутив. Единственное исключение как раз ядро, но yum достаточно интеллектуален, чтобы в этом случае делать не -F, а -i. (и ядра собираются так, что разные версии не конфликтуют) AV> Как по мне - лучше вручную. После того, как я проделаю это: ну, значит ты пока еще не наигрался вволю. Мне уже неинтересно, соответственно, "лучше" - автоматическим способом. AK>> засовывать новое и руками же прописывать в лоадер? AV> и протестирую его работу. в общем случае за меня это сделал майнтейнер дистрибутива (и те две тыщи человек которые уже этот апдейт скачали) AK>> Или чтобы через год судорожно вспоминать, какое именно и почему такое AK>> было поставлено на машину 1032 (номер реальный), вместо того чтоб AK>> набрать rpm -q kernel ? AV> И что это тебе даст? то что при сборке пакета было написано в spec. AV> никак не получается - ну напиши же ты комментарий перед разделом image= в AV> lilo.conf (или, аналогично, в grub). и вспоминай, grub на этой машине или lilo. А когда их двадцать подряд надо проверить на наличие специфичиного пачта? AK>> Или чтобы yum update тебе его снес и поставил штатное, причем через AK>> пол-года я с высокой вероятностью напрочь забуду о такой диверсии... AV> Вот именно для того, чтобы этого не было, ядро и не должно быть пакетом. у меня ядро - в пакете и такого - не будет. В дебианообразных может быть, поскольку у них нет возможности ставить разные версии одного и того же одновременно, но там я его и назову linux-xxxx-custom (а у dpkg обычно все равно спрашиваю linux\*) AK>> чтобы не заниматься пересборкой ядра еще и под каждый новый AK>> контроллер. AV> Опять же, зачем использовать initrd не по назначению? это - давно уже его основное назначение. AV> Его место - разве что на установочном сидюке. на установочном как раз никакой пользы от initrd нету, кроме единообразия. С тем же успехом нужные модули могут быть вкомпилированы в ядро - их для начальной загрузки с CD нужно довольно ограниченное количество, а за размер image бороться уже давно перестали. AK>> initrd с нужным модулем собирается все же побыстрее. AV> Если после каждой сборки не делать `make clean` - разница минимальна. ровно на одну сборку ;-) AK>> не изобретать все новые и новые fs для initrd, а написать наконец-то AK>> нормальный standalone загрузчик этих модулей для grub, как это сделано AK>> у free (в результате ее можно иногда стартануть на таком железе, на AV> Хм... ну, в ориджине примерно так и сделано - в ядро вкомпилирована AV> поддержка накопителей для загрузки с CD, а после загрузки можно AV> и insmod сказать. это будет система, загрузившаяся с CD. Годится только для ремонтных работ. У фряхи будет система, загрузившаяся откуда надо - и без всяких там упражнений с подменой rootfs на лету. Причем grub'у все равно, один файл читать с диска или десять - проблема научить ядро линковать предварительно загруженные модули без insmod'а. Причем в ядре вся эта функциональность есть, только вот оно в этот момент в памяти - пакованное, а при распаковке память-то засрет. Hо в общем, нерешаемых проблем я тут не вижу. AK>> наоборот - я заподозрю что это очередной линухный чайник, который AK>> просто не умеет пользоваться стандартными для системы средствами. AV> Для системы или для дистрибутива? :-) так системы линукс нет в природе. Есть ядро линукса, ну так толку с него немного. Та же LFS -уже система. Бестолковая (поскольку целью авторов было сделать систему предназначенную для сборки системы. Hу и отлично, только у меня другие задачи), но тем не менее - система. AK>> Достаточно вспомнить RHEL3 с его NPTL сбэкпорченными в ядро 2.4. Соберешь AK>> сдуру vanilla - вообще не загрузится. AV> Вообще-то NPTL - это фича glibc (которая требует специальной поддержки со я типа в курсе. А вот любители все собирать из исходников не по делу - как выяснялось пару раз, не знали об этой милой особенности. Hу, они еще много чего не знали - например, куда их пошлет техподдержка. AV> так что особого смысла в ее использовании нет. Соответственно, AV> "не загрузится" относится больше к glibc, нежели к ядру. я думаю, владельцу сервера это уже будет все равно ;-) AV>>>>> Это всего лишь ядро, собранное создателями дистрибутива по желанию AV>>>>> их левой пятки, которая отличается от левой пятки усера лишь тем, AV>>>>> что действует под чутким руководством более толковой головы, AK>>>> в OWL все ТАК плохо? AV>>> А где не так? Ты идеализируешь создателей какого-то дистрибутива? AK>> я не то чтобы идеализирую, но цели, которые преследуют создатели AK>> кернельных пакетов для rh/fc/убунты - таки весьма далеки от названных AK>> тобой. И совпадают с моими - чтобы оно РАБОТАЛО и не требовало моего AK>> времени и моих усилий AV> Вообще-то я до недавнего времени считал, что наличие толковой головы весь вопрос в том, что в этой голове - если любовь закатывать солнце вручную, то тележка будет смазана и рельсы почищены, но я предпочитаю чтобы оно ходило без моей помощи. > Alex --- ifmail v.2.15dev5.3 * Origin: Demos online service (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/6577bfbd296c.html, оценка из 5, голосов 10
|