Поэтому я хотел попробовать собрать 2.6.39-4. Я следовал процедуре наСтраница вики Ubuntu "GitKernelBuild".
Короче говоря, скачайте tar.bz2, распакуйте, скопируйте мой старый конфиг, сделайте oldconfig, а затем
fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers
Все прошло отлично, я сейчас использую это ядро, за исключением одной маленькой вещи: я не могу собирать другие модули, собирать dkms и т. д. Дополнительная информация приведена ниже:
Создано два deb-файла:
linux-image-2.6.39.4-custom_2.6.39.4-custom-10.00.Custom_amd64.deb
linux-headers-2.6.39.4-custom_2.6.39.4-custom-10.00.Custom_amd64.deb
Меня это немного сбивает с толку.
В обычных ядрах ubuntu, даже в mainline-ppa, установлено три deb-файла. Например, для того же ядра изосновная линия ppaсуществуют следующие пакеты:
linux-image-2.6.39-02063904-generic_2.6.39-02063904.201108040905_amd64.deb
linux-headers-2.6.39-02063904-generic_2.6.39-02063904.201108040905_amd64.deb
linux-headers-2.6.39-02063904_2.6.39-02063904.201108040905_all.deb
Как вы видите, есть два разных заголовочных пакета. Действительно, после их установки основные пакеты ppa создают каталог в /lib/modules:
/lib/modules/2.6.39-02063904-generic
В этом каталоге существует символическая ссылка, указывающая на заголовки -generic в /usr/src.
/lib/modules/2.6.39-02063904-generic/build -> /usr/src/linux-headers-2.6.39-02063904-generic
В /usr/src для этого ядра существуют два разных каталога
/usr/src/linux-headers-2.6.39-02063904-generic
/usr/src/linux-headers-2.6.39-02063904
А вот проблема с моими двумя пакетами:
В /usr/src есть только одна папка,
/usr/src/linux-headers-2.6.39.4-custom
А в /lib/modules есть папка
/lib/modules/linux-headers-2.6.39.4-custom
Настоящая проблема и причина, по которой я пишу этот пост, — это символическая ссылка, которая создается в указанном выше каталоге:
/lib/modules/linux-headers-2.6.39.4-custom/build -> /home/nickped/projects/kernel/linux-2.6.39.4
Как вы видите, он ссылается на каталог, где я собрал ядро - которое, конечно, может не существовать впоследствии. Это приводит к тому, что другие модули (например, vmware, virtualbox и т. д.) не собираются, так как не могут найти важные вещи.
Почему это происходит? Как это можно исправить? Почему создается два, а не три deb-файла? Каково назначение этих трех различных deb-файлов, которые есть в официальных релизах, и как их могут создавать другие?
решение1
Чтобы ответить на первый вопросПочему всего две упаковки?илиПочему нет двух заголовочных файлов?-- когда они кросс-компилируются, они упаковываются для обработки каждого варианта использования. Разделив заголовки на более крупныевсепакет и меньший архитектурно-специфичный, вы экономите пропускную способность, отправляя их пользователям. Когда вы делаете это сами, вам это нужно только для одной архитектуры, поэтому подойдет один файл заголовков.
Что касается символической ссылки на исходное местоположение, у меня была та же проблема. Я не нашел хорошего решения, кроме как сгенерировать пакет linux_source(просто добавить его после kernel_image kernel_headers), а затем вручную исправить символическую ссылку.
На самом деле естьвопрос все об этой стороне вещей уже. Долгосрочным решением, по-видимому, является взлом скрипта, который запускается после каждой установки ядра и просто исправляет symink.