Re: Проблемы с USB мышкой
Evening, Victor.
"Victor B. Wagner" <vitus@45.free.net> 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: adept@umc.com.ua
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
Reply to: