Evening, Victor. "Victor B. Wagner" <[EMAIL PROTECTED]> 21:29 9/4/2003 wrote:
>> Я пытаюсь спорить? Боже упаси, я лишь пытаюсь _намекнуть_, что для сборки >> ядра (особенно нынешнего, где напортачить что-то в конфигурации и остаться >> у разбитого корыта - раз плюнуть) лучше иметь чуть побольше оснований, чем VBW> Какого такого разбитого корыта? А со старого ядра загрузиться? VBW> Пакеты сделанные make-kpkg аккуратно оставляют его в меню lilo Начальное письмо не содержало ни намека на make-kpkg. Скорее, наоборот. Впрочем, это не особенно важно. Перечисляю "корыта" (точнее - грабли) виданные мною в эпсилон-окрестности меня за последнее время: * Конфиг не меняли, собрали ядро, не сделали новый initrd -> ide, ext2 в модулях, ничего не грузится. Все пропало, идем жаловаться всем подряд. * Пробовали собрирать так и сяк, в процессе переключили поддержку SMP с yes на no (или наоборот - не важно), не сделали make mrproper -> все валится при сборке. Все пропало, идем жаловаться всем подряд. Все вышеприведенное лечится make-kpkg, согласен. И не приводит к необратимым изменениям. Но - является следствем того, что человек не читает док, и, по возможности, и не собирается их читать... Я с этим пытаюсь бороться по мере сил :) Едем дальше ... * Собирали ядро, отключали все "ненужно". Отключили unix domain sockets. Дальше, думаю, можно не продолжать :) * Собирали ядро, отключали ненужные модули, все остальное включали в ядро монолитно. Результат - неработающее USB/несобирающееся ядро/ядро не лезет в bzImage/... * Начитавшись гугла, собирали с appen-to-version=-686, получили ядро, "такое же как в дистрибутиве", только более новой версии. dpkg успешно сделал апгрейд, старое ядро ушло на свалку, новое не грузится... * Отдельной строкой идет включение DMA на buggy чипсетах без включения поддержки чипсетов, установка unstable версий ядра, которые разносят ext2/reiserfs/whatever. Тут уже не поможет даже make-kpkg... VBW> как Linux.OLD На худой конец можно с дистрибутивного сидюка VBW> загрузиться в режиме rescue. VBW> На машине всегда должно быть установлено минимум три (в вырожденных VBW> случаях - два) ядра - текущее рабочее, предыдущее рабочее и VBW> дистрибутивное. От последнего в основном нужны модули на случай загрузки VBW> в режиме rescue. VBW> Наличие трех ядер спасает даже от двух подряд совершенных ошибок. Да, согласен. Это, кстати, тоже есть где-то в документации. Которую надо читать :) >> Мда? А мне почему-то казалось, что традицией является "dont fix unless >> broken" & "dont fiddle unless you want it broken"... VBW> Традицией является то, что если ты знаешь, что делаешь, и самое главное VBW> - что ты будешь делать, когда оно сломается - можешь спокойно VBW> это крутить. Тоже согласен. >> И что такое "пересобрать под систему"? Мне кажется, что это глупое >> заблуждение - пересобирать "под систему" без веских причин, т.к. ухудшается VBW> Ну, например - SMP + >1Gb памяти. Ну, например, хитрая железяка с хитрым VBW> драйвером. Вот это называется "веская причина", согласен. >> сопровождаемость, гомогенность конфигурации в случае >1 компьютера, >> появляется вредная привычка ставить софт "мимо" менеджера пакетов и т.п. VBW> Вот эта привычка - действительно вредная. Благо разработчики пакета VBW> kernel-package сделали все возможное, чтобы можно было самособранные VBW> ядра ставить не мимо менеджера пакетов. Кстати, да. После того, что я видел в redhat (правда, это было лет эдак 5 тому назад, но не думаю, что что-то радикально поменялось) - просто не нарадуешься. >> Так что я в некотором смысле ратую за best practices. VBW> Использовать дистрибутивные ядра - ни разу не best practices. Как насчет такой формулировки "использовать дистрибутивное ядро, если нет посылок для того, чтобы его пересобрать - best practice"? :) VBW> workstation. А вот для ноутбуков приходится таки индивидуально VBW> выкобениваться. У 45.free.net тоже ядро уникальное - ибо это и сервер, Кстати про ноутбуки... Не было ли опыта собирания 2.4.20 из woody + swsusp? У меня почему-то все последнии версии валятся в panic где-то в дебрях драйвера ide при hibernat-е, причем чуть ли не каждый раз по-разному ... -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
