Bonjour,

j'ai dû recompiler le noyau (2.6.27.25-170.2.72.fc10.x86_64) pour passer USB_HID en module dynamique (nécessaire pour faire fonctionner l'écran OLED de mon portale asus G50v).
J'ai fait cela en suivant la doc :
http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora

tout marche très bien sauf que je n'arrive pas à installer le pilote nvidia pour ma carte graphique.

Comme il s'agit du même noyau qu'au départ (à USB_HID près), j'ai essayé en copiant simplement le fichier /lib/modules/2.6.27.25-170.2.72.fc10.x86_64/extra/nvidia/nvidia.ko dans le répertoire des modules de mon nouveau noyau mais X ne se lance pas :
au démarrage j'ai bien le status [OK] pour ce qui concerne nvidia mais ensuite X ne peut pas se lancer, il fait des tentatives en boucle.


Bref, je pense que c'est dû au fait que j'ai modifié le noyau (si peu !) du fait de la recompilation et je voudrais pouvoir recompiler le pilote nvidia.ko.

Mais comment faire ?
Jusqu'à présent j'utilisais le kmod-nvidia qui contient directement le binaire compilé pour le noyau fedora officiel.


Merci par avance pour vos réponses.


PS : je pense entre autres à DKMS à qui j'avais affaire quand j'utilisais mandriva. C'était vraiment très pratique : peu importe le kernel, perso ou officiel, le pilote nvidia (et autres modules) était recompilé tout seul au démarrage du PC. Pourquoi cela n'est-il pas utilisé dans fedora au lieu des rpm kmod-nvidia qui sont propres à chaque noyau ?
Bonjour,

il y a bien plus simple... le paquet akmod-nvidia est fait (aussi) pour les noyaux "customisés". Le système akmods, qui fonctionne comme dkms, se chargera simplement de recompiler le pilote pour le noyau démarré ; n'embarquant pas de module précompilé, les paquets akmod-* sont indépendants du noyau (modulo les changements d'API affectant le pilote).
Installe le paquetage kernel-devel qui a été généré avec ton noyau customisé, ainsi que le paquet akmod-nvidia sur RPM Fusion, puis redémarre...
Si le akmod ne marche pas il y a toujorus la possibilité d'utiliser le binaire de nvidia sur leur site.
MarbolanGos wrote:Si le akmod ne marche pas il y a toujorus la possibilité d'utiliser le binaire de nvidia sur leur site.
Surtout pas. Si l'akmod échoue à compiler, il y a peu de chance que l'installeur de Nvidia s'en sorte mieux. Par ailleurs, ce même installeur a tendance à écraser certaines bibliothèques graphiques installées par Fedora (voir la doc. NVidia à ce sujet).
tout d'abord merci pour votre aide !

Je ne connaissais pas akmod, ça marche nickel avec le noyau officiel mais avec mon noyau modifié dkms m'affiche une erreur au démarrage :
files needed for building modules against kernel 2.6-hid could not be found as the following directories are missing :

/usr/src/kernel/2.6.27.25-hid
/lib/modules/2.6.27.25-hid/build
J'imagine que ça vient du fait que je n'ai pas installé le rpm kernel-devel (pourtant j'ai mis les sources complètes dans /usr/src/kernel, et avec les liens symboliques dans le répertoire /lib/modules)
En suivant le instructions de la doc, le rpm kernel-devel n'est pas créé et je bataille depuis plusieurs heures pour le faire.

Vous pouvez me dire quelle est la commande pour le créer ?
Jusqu'à présent j'ai essayé
rpmbuild --target x86_64 -ba kernel.spec
et
les variantes avec -bb et -bp
je n'ai mis que le début du fichier (avec les options à modifier d'après la doc) car il ne passe pas complet.
Summary: The Linux kernel

# For a stable, released kernel, released_kernel should be 1. For rawhide
# and/or a kernel built from an rc or git snapshot, released_kernel should
# be 0.
%define released_kernel 1

# Versions of various parts

# Polite request for people who spin their own kernel rpms:
# please modify the "buildid" define in a way that identifies
# that the kernel isn't the stock distribution kernel, for example,
# by setting the define to ".local" or ".bz123456"
#
#% define buildid .local

# fedora_build defines which build revision of this kernel version we're
# building. Rather than incrementing forever, as with the prior versioning
# setup, we set fedora_cvs_origin to the current cvs revision s/1.// of the
# kernel spec when the kernel is rebased, so fedora_build automatically
# works out to the offset from the rebase, so it doesn't get too ginormous.
#
%define fedora_cvs_origin   1036
%define fedora_build_string %(R="$Revision: 1.1206.2.72 $"; R="${R%% \$}"; R="${R#: 1.}"; echo $R)
%define fedora_build_origin %(R=%{fedora_build_string}; R="${R%%%%.*}"; echo $R)
%define fedora_build_prefix %(expr %{fedora_build_origin} - %{fedora_cvs_origin})
%define fedora_build_suffix %(R=%{fedora_build_string}; R="${R#%{fedora_build_origin}}"; echo $R)
%define fedora_build        %{fedora_build_prefix}%{?fedora_build_suffix}

# base_sublevel is the kernel version we're starting with and patching
# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
# which yields a base_sublevel of 21.
%define base_sublevel 27

## If this is a released kernel ##
%if 0%{?released_kernel}

# Do we have a -stable update to apply?
%define stable_update 25
# Is it a -stable RC?
%define stable_rc 0
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev .%{stable_update}
%define stable_base %{stable_update}
%if 0%{?stable_rc}
# stable RCs are incremental patches, so we need the previous stable patch
%define stable_base %(expr %{stable_update} - 1)
%endif
%endif
%define rpmversion 2.6.%{base_sublevel}%{?stablerev}

## The not-released-kernel case ##
%else
# The next upstream release sublevel (base_sublevel+1)
%define upstream_sublevel %(expr %{base_sublevel} + 1)
# The rc snapshot level
%define rcrev 0
# The git snapshot level
%define gitrev 0
# Set rpm version accordingly
%define rpmversion 2.6.%{upstream_sublevel}
%endif
# Nb: The above rcrev and gitrev values automagically define Patch00 and Patch01 below.

# What parts do we want to build?  We must build at least one kernel.
# These are the kernels that are built IF the architecture allows it.
# All should default to 1 (enabled) and be flipped to 0 (disabled)
# by later arch-specific checks.

# The following build options are enabled by default.
# Use either --without <opt> in your rpmbuild command or force values
# to 0 in here to disable them.
#
# standard kernel
%define with_up        0
# kernel-smp (only valid for ppc 32-bit, sparc64)
%define with_smp       1
# kernel-PAE (only valid for i686)
%define with_pae       0
# kernel-kdump
%define with_kdump     0
# kernel-debug
%define with_debug     0
# kernel-doc
%define with_doc       0
# kernel-headers
%define with_headers   1
# kernel-firmware
%define with_firmware  %{?_with_firmware:  1} %{?!_with_firmware:  0}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
%define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1}
# Want to build a the vsdo directories installed
%define with_vdso_install %{?_without_vdso_install: 0} %{?!_without_vdso_install: 1}

# Build the kernel-doc package, but don't fail the build if it botches.
# Here "true" means "continue" and "false" means "fail the build".
#% define with_doc 0
%if 0%{?released_kernel}
%define doc_build_fail false
%else
%define doc_build_fail true
%endif

# Additional options for user-friendly one-off kernel building:
#
# Only build the base kernel (--with baseonly):
%define with_baseonly  %{?_with_baseonly:     1} %{?!_with_baseonly:     0}
# Only build the smp kernel (--with smponly):
%define with_smponly   %{?_with_smponly:      1} %{?!_with_smponly:      0}
# Only build the pae kernel (--with paeonly):
%define with_paeonly   %{?_with_paeonly:      1} %{?!_with_paeonly:      0}

# should we do C=1 builds with sparse
%define with_sparse    %{?_with_sparse:      1} %{?!_with_sparse:      0}
Juste une question... As-tu mis en place un environnement de construction de RPM sain en mode utilisateur ? Dans quel répertoire a été généré ton RPM ?
je me suis couché un peu tôt hier ...

j'ai tout repris depuis le début tout à l'heure mais c'est le même problème :
- je n'arrive pas à générer le paquetage kernel-devel
- le pilote nvidia.ko n'est pas compilé au démarrage même en plaçant les sources complètes du noyau dans /usr/src/kernels

@Pikatchu_2014
"sain", je ne peux pas le certifier mais j'ai suivi à la lettre les instructions de la doc et j'avais déjà fais un rpm de ffmpeg avec succès.

Le seul rpm généré est kernel-headers. Il se trouve dans ~/rpmbuild/RPMS/x86_64/
J'installe le noyau et ses modules "à la main" avec
make modules_install
make install
Curieux, mes empaquetages de kernel me créaient toujours par défaut les devel et même les debug; peut-être les paramètres par défaut ont changé ces derniers temps. Que donne alors l'option --with=debug ? Autrement dit:
rpmbuild  --with=debug --target=`uname -m` -ba kernel.spec
Je n'ai jamais testé --with=devel, mais ce devrait être qq chose comme ça.

Petites remarques additionnelles:

- tu n'as pas modifié la ligne
#% define buildid .local
comme il est recommandé de le faire.

- puisque tu as construit les rpm, pourquoi ne les installes-tu pas par yum ou rpm ?

Phil.
uname -a pour le target est faux, c'est uname -m
Phiphi69 wrote:- tu n'as pas modifié la ligne
#% define buildid .local
comme il est recommandé de le faire.
quand je modifie cette ligne, rpmbuild m'affiche une erreur.
J'avais mis ceci :
% define buildid .hdi
Phiphi69 wrote:- puisque tu as construit les rpm, pourquoi ne les installes-tu pas par yum ou rpm ?

Phil.
En suivant le tuto de la doc, il n'est pas question de générer les rpm binaires du noyau, seulement le répertoire des sources du noyau fedora et ses patchs dans ~/rpmbuild/BUILD/linux.2.6.27...

(dans le fichier kernel.spec, j'ai modifié certaines variables comme indiqué dans la doc, pour ne produire que pour une architecture smp : ci-dessous)
# standard kernel
%define with_up        0
# kernel-smp (only valid for ppc 32-bit, sparc64)
%define with_smp       1
# kernel-PAE (only valid for i686)
%define with_pae       0
# kernel-kdump
%define with_kdump     0
# kernel-debug
%define with_debug     0
# kernel-doc
%define with_doc       0
# kernel-headers
%define with_headers   1
De là, je modifie l'extraversion dans le Makefile et je passe USB_HID=m dans le .config.
Ensuite je compile et j'installe avec make.


Est-il possible de générer directement le rpm binaire (et kernel-devel) en prenant en compte que je veux compiler USB_HID en tant que module dynamique ?
fab64 wrote:quand je modifie cette ligne, rpmbuild m'affiche une erreur.
J'avais mis ceci :
% define buildid .hdi
Il ne faut pas garder l'espace entre % et define:
%define buildid .hdi
fab64 wrote:Est-il possible de générer directement le rpm binaire (et kernel-devel) en prenant en compte que je veux compiler USB_HID en tant que module dynamique ?
Oui, c'est expliqué au moins ici, au 1.6 Configure kernel options. Non ?

Phil
5 jours plus tard
Merci pour votre aide, je viens d'installer F11 sur mon portable mais je ne lâche pas l'affaire.
J'indiquerai prochainement ce qui l'en est ...