Le Forum
Vous n'êtes pas identifié.
#1 08 Dec 2014 17:45:02
- antoine.sibold
- Équipe Why!
- Date d'inscription: 27 Aug 2013
- Messages: 70
Qui m'aiderait pour un kernel bisect avec git ?
Depuis la version du noyau 3.8.0-19.28 (Ubuntu 12.10), il n'est plus possible d'enclencher Bluetooth avec FN + F12 sur nos why W253EU.
Conséquence nous ne pouvons pour le moment livrer ces machines qu'avec la version 12.04 d'Ubuntu.
J'ai ouvert un Bug sur Launchpad.
Pour résoudre ce problème il faut effectuer un kernel bisect comme indiqué dans cet article.
J'ai testé des dizaines de noyaux pour repérer la dernière version non boguée. En fait le problème se situe entre les noyaux 3.50-51.76 (bon) et 3.8.0-19.28.
Voilà où cela coince: https://bugs.launchpad.net/ubuntu/+sour … omments/35
Je dois dire que je nage un peu, surtout qu'il ne s'agit pas du cas simple.
Merci d'aider un non-développeur ...
Dernière modification par antoine.sibold (09 Dec 2014 07:31:15)
Hors ligne
#2 02 Feb 2015 09:37:44
- antoine.sibold
- Équipe Why!
- Date d'inscription: 27 Aug 2013
- Messages: 70
Re: Qui m'aiderait pour un kernel bisect avec git ?
Bonjour à tous,
Comme j'ai passé de nombreuses heures à effectuer ce travail et comme j'ai finalement obtenu un résultat j'aimerais en faire profiter le plus grand nombre.
Point de départ :
J'ai ouvert un Bug sur Launchpad.
Et voici le bisect qui en a résulté.
Tout d'abord c'est quoi un bisect?
Un bisect est la procédure la plus rapide pour trouver le point central entre la version d'un logiciel repéré comme fonctionnant correctement et la version du logiciel repéré comme ne fonctionnant pas correctement. On continue avec cette procédure jusqu'à ce que la bonne et la mauvaise version du logiciel se suivent.
Exemple :
Admettons que nous savons que la bonne version connue du logiciel est 1.0 et que la première version défaillante connue du logiciel est 1.10. Dans le pire des cas 1.9 étant la mauvaise version il faudrait tester 9 versions de ce logiciel pour trouver la version défaillante à savoir (1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9)
En utilisant la méthode du point central (bisecting) on procède de la manière suivante :
Sachant que 1.0 et 1.10 sont les extrémités connues (bonne version, version défaillante) on commence par tester la version 1.5. Si celle-ci est bonne nous savons maintenant que la version défaillante du logiciel se trouve entre la version 1.5 et 1.10.
La prochaine version à tester est donc la version 1.7. Si celle-ci est toujours bonne nous savons maintenant que la version défaillante se trouve entre 1.8 et 1.10.
La prochaine version à tester est donc la 1.8. Si celle-ci est bonne nous savons maintenant que la version défaillante se trouve entre 1.9 et 1.10.
La prochaine version à tester est donc 1.9. Si celle-ci est défaillante nous avons alors trouvé les deux versions consécutives 1.8 la bonne 1.9 la défaillante.
Les différents type de bisect
Bisecting Ubuntu releases
C'est appliquer la méthode du point central aux releases de Ubuntu.
Exemple :
Enclencher Bluetooth par les touches Fn+F12 sur la machine W253EU de why !
En créant le Ubuntu 14.04 LTS pour la W253EU nous nous sommes aperçus qu'enclencher Bluetooth à l'aide des touches Fn+F12 n'était plus possible alors que c'était tout à fait possible avec la version Ubuntu 12.04 LTS.
Les extrémités au niveau des releases de Ubuntu sont donc 12.04 LTS le bon release et 14.0 4LTS le release défaillant. Nous avons donc la situation suivante :
12.04 Ubuntu Precise (noyau v3.2) Bon release
12.10 Ubuntu Quantal (noyau v3.5)
13.04 Ubuntu Raring (noyau v3.8)
13.10 Ubuntu Saucy (noyau v3.11)
14.04 Ubuntu Trusty (noyau v3.13) Release défaillant
De plus des clients nous ont rapporté que depuis l'installation de Ubuntu Raring (13.04) il n'était plus possible d'enclencher Bluetooth à l'aide des touches Fn+F12.
Le premier release défaillant n'est donc plus Ubuntu 14.04 mais Ubuntu Raring (13.04).
Les extrémités au niveau des releases Ubuntu se sont donc rétrécis. Nous avons donc la situation suivante :
12.04 Ubuntu Precise (noyau v3.2) Bon release
12.10 Ubuntu Quantal (noyau v3.5)
13.04 Ubuntu Raring (noyau v3.8) Release défaillant
Bisecting Ubuntu Kernel Versions
C'est appliquer la méthode du point central aux versions de noyaux Ubuntu
Exemple :
Enclencher Bluetooth par les touches Fn+F12 sur la machine W253EU de why !
En consultant les sites,
https://launchpad.net/ubuntu/précise/+source/linux
https://launchpad.net/ubuntu/quantal/+source/linux
https://launchpad.net/ubuntu/raring/+source/linux
nous avons pu tirer les éléments suivants :
Le release Ubuntu Precise a été publié avec le noyau version
linux 3.2.0-23.36
La dernière version du noyau du release Ubuntu Precise (12.0
4) était
linux 3.2.0-74.109
Le release Ubuntu Quantal (12.10) a été publié avec le noyau version
linux 3.5.0-17.28
La dernière version du noyau du release Ubuntu Quantal (12.10) était
linux 3.5.0-51.76
Le release Ubuntu Raring (13.04) a été publié avec le noyau version
linux 3.8.0-19.29
La dernière version du noyau du release Ubuntu Raring (12.10) était
linux 3.8.0-35.50
Nous savons maintenant que la version du noyau défaillant se trouve entre la dernière version du release Ubuntu Raring et la première version du noyau Ubuntu Precise. Nous avons donc la situation suivante :
linux 3.2.0-23.36 (première version du noyau de Ubuntu Precise 12.04) Bonne Version
-
linux 3.2.0-74.190 (dernière version du noyau de Ubuntu Precise 12.04)
linux 3.5.0-17.28 (première version du noyau de Ubuntu Quantal 12.10)
-
linux 3.5.0-51.76 (dernière version du noyau de Ubuntu Quantal 12.10)
linux 3.8.0-19.29 (première version du noyau de Ubuntu Raring 13.04)
-
linux 3.8.0-35.50 (dernière version du noyau de Ubuntu Raring 13.04) Version défaillante
Obtenir les sources des noyaux d'un release Ubuntu avec git
GIT est l'outil de gestion du code source utilisé par la communauté des développeurs du noyau Linux. Cet outil a été adopté par Ubuntu.
Commençons par tester la première version du noyau de Ubuntu Raring 13.04
Pour cela utilisons Git
Afin de pouvoir utiliser git il vous faut installer le paquet git sur votre système.
1. Dans un terminal saisissez pour cela la commande
Code:
$ sudo apt-get install git
Tout le code source du noyau Ubuntu est maintenu sous git. Le code source de chaque release est maintenu dans son propre git repository sous kernel.ubuntu.com.
Afin d'obtenir une copie locale d'une source de logiciels des noyaux d'un release Ubuntu donné, effectuez un clone avec la commande suivante :
Code:
$ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
(si le release est encore supporté)
ou
Code:
$ git clone git://kernel.ubuntu.com/ubuntu-archive/ubuntu-raring.git
(si le release n'est plus supporté et par conséquent archivé)
Obtenir une liste des noyaux pour un Ubuntu release donné
Pour obtenir une liste de toutes les versions de noyaux contenus dans ce release utilisez les commandes :
Code:
$ cd ubuntu-raring $ git tag -l Ubuntu-*
Travailler avec un release de noyau donné
Afin de pouvoir travailler avec un release de noyau donné effectuez la commande :
Code:
$ git checkout -b temp1 Ubuntu-3.8.0-19.29
En comparant la version du noyau Ubuntu-3.8.0-19.29 avec la liste obtenue par la commande précédente Nous constatons qu'il en fait partie.
Nous allons maintenant créer le noyau à partir des sources ainsi obtenues dans la branche temp1
Créer son propre noyau
Afin de pouvoir créer un noyau il faut d'abord installer un certain nombre de paquets.
Utilisez à cet effet dans un terminal les commandes suivantes :
Code:
$ sudo apt-get build-dep linux-image-$(uname -r) $ sudo apt-get install fakeroot
La première commande installe les paquets en fonction du release du noyau actuellement installé. En effet $(uname -r) signifie résultat retourné par la commande uname -r. Et cette commande retourne le release de noyau actuellement installé.
La seconde installe le paquet fakeroot
Afin de pouvoir créer le code exécutable et installable d'une version de noyau donné procédez de la manière suivante :
1. Dans un Terminal allez à la racine du dossier contenant le code source du noyau.
2. Puis exécutez les 2 commandes suivantes :
Code:
$ fakeroot debian/rules clean $ fakeroot debian/rules binary-headers binary-generic
Si le processus de création de noyau se déroule avec succès alors des paquets binaires .deb sont créés dans le répertoire parent.
Vous pouvez les visualisez de la manière suivante :
Code:
$ cd .. $ ls * .deb
Tester le noyau
Installez le set de paquets avec la commande
Code:
$ sudo dpkg -i linux* 3.8.0-19.29*.deb
Redémarrez avec le noyau précédemment installé avec la commande
Code:
$ sudo reboot
Une fois ce noyau installé le test d'enclenchement de bluetooth avec Fn+F12 a échoué
Conclusion la version du noyau 3.8.0-19.29 est défaillante.
Les extrémités se rétrécissent. Nous avons maintenant la situation suivante :
linux 3.2.0-23.36 (première version du noyau de Ubuntu Precise 12.04) Bonne Version
-
linux 3.2.0-74.190 (dernière version du noyau de Ubuntu Precise 12.04)
linux 3.5.0-17.28 (première version du noyau de Ubuntu Quantal 12.10)
-
linux 3.5.0-51.76 (dernière version du noyau de Ubuntu Quantal 12.10)
linux 3.8.0-19.29 (première version du noyau de Ubuntu Raring 13.04) Version défaillante
Testons la dernière version du noyau de Ubuntu Quantal 12.10
Nous procédons de manière analogue au noyau précédent.
Afin d'obtenir une copie locale d'une source de logiciels des noyaux d'un release Ubuntu donné, effectuez un clone avec la commande suivante :
Code:
$ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
(si le release est encore supporté)
ou
Code:
$ git clone git://kernel.ubuntu.com/ubuntu-archive/ubuntu-quantal.git
(si le release n'est plus supporté et par conséquent archivé)
Obtenir une liste des noyaux pour un Ubuntu release donné
Afin de pouvoir travailler avec un release de noyau donné effectuez la commande :
Code:
$ cd ubuntu-quantal $ git tag -l Ubuntu-*
Travailler avec un release de noyau donné
Afin de pouvoir travailler avec un release de noyau donné effectuez la commande :
Code:
$ git checkout -b temp2 Ubuntu-3.5.0-51.76
En comparant la version du noyau Ubuntu-3.5.0-51.76 avec la liste obtenue par la commande précédente Nous constatons qu'il en fait partie.
Nous allons maintenant créer le noyau à partir des sources ainsi obtenues dans la branche temp2
Créer son propre noyau
Afin de pouvoir créer un noyau il faut d'abord installer un certain nombre de paquets.
Utilisez à cet effet dans un terminal les commandes suivantes :
Code:
$ sudo apt-get build-dep linux-image-$(uname -r) $ sudo apt-get install fakeroot
Afin de pouvoir créer le code exécutable et installable d'une version de noyau donné procédez de la manière suivante :
3. Dans un Terminal allez à la racine du dossier contenant le code source du noyau.
4. Puis exécutez les 2 commandes suivantes :
Code:
$ fakeroot debian/rules clean $ fakeroot debian/rules binary-headers binary-generic
Si le processus de création de noyau se déroule avec succès alors des paquets binaires .deb sont créés dans le répertoire parent.
Si le processus de création de noyau se déroule avec succès alors des paquets binaires .deb sont créés dans le répertoire parent.
Vous pouvez les visualisez de la manière suivante :
Code:
$ cd .. $ ls * .deb
Tester le noyau
Installez le set de paquets avec la commande
Code:
$ sudo dpkg -i linux* 3.5.0-51.76*.deb
Redémarrez avec le noyau précédemment installé avec la commande
Code:
$ sudo reboot
Une fois ce noyau installé le test d'enclenchement de bluetooth avec Fn+F12 a réussi
Conclusion la version du noyau 3.5.0-51.76 est bonne
Les extrémités se rétrécissent. Nous avons maintenant la situation suivante :
linux 3.5.0-51.76 (dernière version du noyau de Ubuntu Quantal 12.10) Bonne Version
-
linux 3.8.0-19.29 (première version du noyau de Ubuntu Raring 13.04) Version défaillante
Comme ces deux noyaux ne se trouvent pas dans le même git repository il faut switcher au
commit bisecting the mainline kernel.
A cet effet nous allons utiliser la table de conversion entre les version de noyau Ubuntu et Mainline
http://people.canonical.com/~kernel/inf … n-map.html
La version Ubuntu 3.5.0-51.76 correspond à la version Mainline 3.5.7.33 Bonne Version
La version Ubuntu 3.8.0-19.29 correspond à la version Mainline 3.8.8. Version défaillante
Noyaux Mainline
1. Obtenir les sources des noyaux Mainline stable (répertoire git local) avec git (linux-stable):
Code:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable
2. Obtenir une liste des versions de noyaux Mainline
Code:
$ cd linux-stable $ git tag -l
D'après cette liste nous pouvons voir que les versions contenues les plus proches de v3.5.7.33 et v.3.8.8 sont :
v.3.5.7
et
v3.8.8
Les extrémités des versions de noyaux Mainline (up-stream) sont donc
v.3.5.7 Good
et
v3.8.8 Bad
Commit bisecting the mainline kernels
Testons d'abord ces deux noyaux et préparons la machine pour les tests.
Pour cela procédons de la manière suivante :
Préparons notre machine pour pouvoir créer les versions des noyaux Mainline en fonction des commits
Code:
$ sudo apt-get install git build-essential kernel-package fakeroot libncurses5-dev
Allons au répertoire contenant le répertoire git local des sources de noyaux Mainline
Code:
$ cd linux-stable
Isolons la version v.3.5.7
Code:
$ git checkout v3.5.7
Copions le fichier de configuration du système existant dans l'arbre du noyau.
Code:
$ cp /boot/config-`uname -r` .config
Mettons à jour ce fichier de configuration
Code:
$ yes '' | make oldconfig
Nettoyons le répertoire source du noyau
Code:
$ make clean
Créons les paquets .deb du noyau à tester
Code:
$ make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom
Installons le noyau à tester
Code:
$ cd .. $ sudo dpkg -i linux*.deb
Redémarrons le système tout en faisant attention de bien démarrer le noyau qui vient d'être créé.
Code:
$ sudo reboot
Après l'installation tester la fonction Fn+F12. Le test est OK
Ceci confirme que le noyaux Mainline v3.5.7 est une bonne version
Répétition de la procédure avec le noyau v3.8.8
Code:
$ cd linux-stable $ git checkout v3.8.8 $ cp /boot/config-`uname -r` .config $ yes '' | make oldconfig $ make clean $ make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom $ cd .. $ sudo dpkg -i linux*.deb $ sudo reboot
Après l'installation tester la fonction Fn+F12. Le test n'est pas bon
Ceci confirme que le noyaux Mainline v3.8.8 est une version défaillante
Démarrons maintenant le bisect
Code:
$ git bisect start git bisect good v3.5.7 git bisect bad v3.8.8
Résultat:
[…] a merge base must be tested Linux 3.5
Répétition de la procédure avec le noyau v3.5
Code:
$ cd linux-stable $ git checkout v3.5 $ cp /boot/config-`uname -r` .config $ yes '' | make oldconfig $ make clean $ make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom $ cd .. $ sudo dpkg -i linux*.deb $ sudo reboot
Après l'installation tester la fonction Fn+F12. Le test est OK
Ceci confirme que le noyaux Mainline v3.5 est une bonne version
Indiquons git que le test s'est déroulé avec succès
Code:
$ cd linux-stable git bisect good
Résultat:
[…] texte correspondant au commit
Créons maintenant le prochain noyau à tester en fonction du commit affiché
$ cp /boot/config-`uname -r` .config
$ yes '' | make oldconfig
$ make clean
$ make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom
Installons-le
Code:
$ cd .. $ sudo dpkg -i linux*.deb $ sudo reboot
Testons le et indiquons à bisect s'il est OK ou pas.
Code:
$ cd linux-stable git bisect good
ou
Code:
git bisect bad
Résultat:
[…] texte correspondant au commit
Procédons de cette façon jusqu'au message indiqué ci-dessous
xx....xx is the first bad commit
Nous sommes ainsi arrivé à la fin de la procédure.
Dernière modification par antoine.sibold (02 Feb 2015 11:04:36)
Hors ligne
#3 19 May 2015 23:53:10
- François Marthaler
- Modérateur
- Lieu: Prilly
- Date d'inscription: 07 Sep 2013
- Messages: 2967
- Site web
Re: Qui m'aiderait pour un kernel bisect avec git ?
C'était laborieux, mais la solultion a enfin été trouvée: http://www.swisslinux.org/forum/viewtop … 647#p20647
laptop why! NV41MZ, Intel Core i7-1165G7, RAM 16 Gb, Ubuntu 22.04 LTS
Hors ligne
#4 20 May 2015 06:52:12
- jean@adimp.ch
- Illuminé(e)
- Lieu: Marly
- Date d'inscription: 10 Mar 2005
- Messages: 1233
- Site web
Re: Qui m'aiderait pour un kernel bisect avec git ?
Salut,
C'est déjà bien que ce soit possible.
A+.
Jean.
--------------------------------------------------------
Jean Tinguely Awais
Ma vie sur twitter : http://www.twitter.com/tservi
Hors ligne
#5 05 Sep 2015 23:58:12
- Battant
- Gourou(e) du libre
- Date d'inscription: 06 Aug 2013
- Messages: 286
Re: Qui m'aiderait pour un kernel bisect avec git ?
Bonjour,
Pour palier au problème de bluetooth sur les ordinateur why, j'utilise pour ma part la clef bluetooth Targus dont l'identifiant matériel est le suivant
Code:
[ Bus 001 Device 010: ID 0a5c:2100 Broadcom Corp. Bluetooth 2.0+eDR dongle
Au passsage, je vous signal avoir pu faire marché le clavier universel logitech k480 en le réglant sous chrome os au via se doodle avec linux 4.1.5 avec les module chrome os
En éspérent avoir été utile, je vous adresse mes meilleures salutation
Battant
Hors ligne
#6 13 May 2016 17:41:07
- Battant
- Gourou(e) du libre
- Date d'inscription: 06 Aug 2013
- Messages: 286
Re: Qui m'aiderait pour un kernel bisect avec git ?
Bonjour,
Aujourd'hui, je remarque que le bloototh interne de ma machine fonctionne de nouveau Quelle chance !
Version du noyeau :
Code:
mparchet@mparchet-W240EU-W250EUQ-W270EUQ:~$ uname -a Linux mparchet-W240EU-W250EUQ-W270EUQ 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Essayez donc installer ubuntu 16.04 LTS ou au moins la même version du noyeau que moi
ça m'intéresserait d'avoir vos commentaire à ce sujet.
Avec mes meilleures salutations
Battant
Hors ligne
#7 03 Nov 2016 15:34:28
- Battant
- Gourou(e) du libre
- Date d'inscription: 06 Aug 2013
- Messages: 286
Re: Qui m'aiderait pour un kernel bisect avec git ?
Bonjour,
Mauvaise nouvelle. depuis quelque temps, je bluetooth ne marche plus sur ma machine..
Ma configuration est :
Code:
lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial
Avec le noyau :
Code:
uname -r 4.4.0-45-generic 64 bit
Plus de détail ici (en anglais)
https://bugs.launchpad.net/ubuntu/+sour … ug/1322068
A noter que j'ai installé ubuntu depuis un dvd et non depuis l'image clonezila fournit par why.
Est-ce que cela change quelque chose ?
Meilleures salutations
Battant
Dernière modification par Battant (03 Nov 2016 15:37:21)
Hors ligne