French/français : Bienvenue sur le logiciel de suivi du projet LibraZiK. Après vous être inscrit, vous pouvez commenter les tâches ouvertes, créer de nouvelles tâches, voter pour des tâches, vous inscrire à des tâches pour être tenu au courant des évolutions,… Pensez à être le plus précis possible dans vos messages. D'avantage d'information concernant le logiciel de suivi du projet LibraZiK.
Anglais/english : Welcome to the LibraZiK project tracking software. After registering, you can comment open tasks, create new tasks, vote for tasks, register for tasks to be kept informed of developments,… Remember to be as precise as possible in your messages. More information about the LibraZiK project tracking software. Feel free to write in French or in English.
- Status Closed
- Percent Complete
- Task Type Demande fonctionnalité / Feature request
- Category distribution → bogue distribution / distribution bug
-
Assigned To
Olivier Humbert - Operating System
- Severity Low
- Priority Very Low
- Reported Version version 2 20171028
- Due in Version version 4 prochaine
-
Due Date
Undecided
-
Votes
3
- Julien Taverna (04.08.2019)
- Erwan Lerale (19.11.2018)
- Olivier Humbert (12.12.2017)
- Private
Opened by Olivier Humbert - 30.11.2017
Last edited by Olivier Humbert - 10.08.2019
FS#275 - noyaux linux-image-4.9 librazik BL et RT - headers-common
Ce soucis a été reporté par "alasic" sur le canal IRC de #librazik qui tentait d'installer un pilote wifi pour une carte BCM43228 par l'intermédiaire du paquet non-free (des dépôts Debian) du nom de broadcom-sta-dkms . L'installation de ce paquet semble demander l'installation de paquets linux-headers (les entête de développement du noyau permettant de compiler un module pour le noyau).
Ceci échoue lorsque (par exemple) on demande à synaptic d'installer le paquet linux-headers-4.9.0-4-lzk-bl-amd64, car synaptic renvoie alors une erreur disant que celui-ci dépend du paquet linux-headers-4.9.0-4-lzk-bl-common (=4.9.51-1) mais que ce dernier n'est pas installable.
Il semble que j'ai oublié de fabriquer les paquets linux-headers-4.9.0-4-lzk-bl-common et linux-headers-4.9.0-4-lzk-rt-common lors de la fabrication des noyaux de LZK-2, et que ceci empêche donc un utilisateur de construire un module pour ce noyau.
Il me faut donc fabriquer ces paquets et les mettre sur le dépôt "users".
Après investigation préliminaire, il me faut revoir le process de construction des noyaux.
La méthode que j'utilisais et qui construisait les linux-headers-common nécessaires ne les construit plus.
Il doit probablement y avoir eu un changement du côté de la méthode de construction des noyaux chez Debian.
Je suis bon pour me retaper le http://kernel-handbook.alioth.debian.org/ !
Youpi \o/
Soucis reporté par nomsys sur le canal de dogmazic :
nomys : en fait le noyau librazik n'est pas compatible avec optimus (il n'arrive pas à charger les linux-headers correspondant)
nomys : … zip … je pensais que l'install des drivers optimus c'était bien passé, mais en fait non j'avais juste booté sur le mauvais kernel (foutu config de grub que j'ai baclé)
olinuxx : pour info, c'est quoi "optimus" nomys ?
nomys : optimus c'est une techno nvidia, qui permet de n'utiliser la carte graph qua quand il y en a vraiment besoin, c'est géré sous gnu/linux avec le paquet 'bumblebee' (non-free)
nomys : le truc c'est que c'est pas désactivable, donc si tu passes pas par bumblebee ta carte sert à rien
J'intuitionne que le fameux paquet blumblebee fabrique un module noyau et qu'il a donc besoin du paquet de dev linux-headers-…-common
Voir également : https://www.debian.org/releases/stretch/amd64/ch08s06.html.fr
rapporté également par ledufakademy sur le canal IRC de debian-facile qui en avait besoin pour construire un module pour un pilote broadcom (bc43228) avec dkms
J'ai mis une note dans la page http://librazik.tuxfamily.org/doc2/manuel/noyau#les_differents_noyaux_chez_librazik-2 qu'il faudra enlever lorsque ça sera réglé.
Bonjour,
J'ai testé l'installation de librazik 2 sous Virtualbox.
L'installation des virtualbox-guest-dkms, depuis apt ou depuis l'iso fournie par virtualbox est impossible à cause de ce problème.
Problème relevé ici également http://linuxmao.org/forumthread85507 avec un 4.9.0-6-lzk-bl-amd64
Ici aussi : http://linuxmao.org/forumthread86256
Ici également : https://debian-facile.org/viewtopic.php?id=21401
Et ici : http://librazik.tuxfamily.org/flyspray/index.php?do=details&task_id=521
Copie du message de "Lo Cicero Pierre (pierrotlo)" :
Titre : Installation driver WIFI BCM 43142
Toujours présent avec les noyaux 4.9.0-7 .
http://librazik.tuxfamily.org/flyspray/index.php?do=details&task_id=545
Voir aussi : http://linuxmao.org/forumthread88522
Pour info, ce bogue est toujours présent avec les noyaux 4.9.0-8.
J'essaie de compiler cela https://github.com/umlaeute/v4l2loopback et ça foire.
Le même soucis du manque de header pour ce kernel, je présume :)
J'ai réussi à sortir des paquets -bl en utilisant la méthode officielle, dont j'ai l'impression qu'elle est réservée aux mainteneurs de Debian, et n'est pas véritablement documentée en détail.
A partir du document «kernel handbook», la seule procédure documentée pour une noyau personnalisée fait appel aux règles make dans les sources Linux.
J'ai donc noté la marche à suivre que j'ai déduite en analysant les sources "4.9.168-1+deb9u4" pour en dériver la version -bl. Une entrée changelog pour LibraZiK et ça devrait rouler.
(J'imagine que le procédé doit être semblable pour -rt.)
Voir linux-bl.txt
Bonjour tout le monde,
J'ai fait les choses suivantes sur ma LZK2 à jour :
dans ~
$ mkdir kernel
$ cd kernel
$ tar -xaf /usr/src/linux-source-4.9.tar.xz
$ cd linux-source-4.9/
$ cp /boot/config-4.9.0-9-lzk-bl-amd64 ./.config
$ make deb-pkg LOCALVERSION=-juju KDEB_PKGVERSION=$(make kernelversion)-1
Voici le résultat :
julien@Acer-i3:~/kernel/linux-source-4.9$ ls ../*.deb
../linux-headers-4.9.168-juju_4.9.168-1_amd64.deb
../linux-image-4.9.168-juju_4.9.168-1_amd64.deb
../linux-libc-dev_4.9.168-1_amd64.deb
Je viens de placer une nouvelle construction des noyaux 4.9.168 dans le dépôt utilisateur ainsi que les fameux paquets headers-common.
Le problème devrait être donc résolu ici, et les utilisateurs de ces noyaux devraient être en capacité de construire des modules noyaux à présent.
Si quelqu'un pouvait confirmer cela, je pourrai alors fermer cette tâche.
J'ai prévenu nomsys sur le canal IRC de dogmazic et ai mis des messages dans :
jpcima a confirmé sur IRC que ça fonctionnait pour lui (virtualbox).
J'ai donc retiré la note concernant ce bogue dans https://librazik.tuxfamily.org/doc2/manuel/noyau
Je laisse ce sujet encore ouvert au cas où, et le fermerai lors de la prochaine mise à jour de LibraZiK-2.
Billet publié : https://librazik.tuxfamily.org/dotclear/blog/?post/Noyaux-am%C3%A9lior%C3%A9s