Caméra non reconnue

Nan, c’est rien de compiler un noyau:
https://www.debian.org/releases/stable/i386/ch08s06.html.fr

1 J'aime

ca fait plus d’un an que je suis sur cet ordi
: j’ai essayé des distributions dont je n’avais jamais entendu le nom, j’ai même - au final - essayé d’y remettre un windows tellement j’étais ecoeuré.
Alors un downgrade, au moins, ca m’apprendra quelque chose :slight_smile:

d’aillerus c’est dit sur cette page :

Nayez pas peur de compiler un nouveau noyau. C’est amusant et très instructif

mais j’ai quand même un problème : pour compiler, il me faut le module ; je le trouve où?

bon aller je commence
apt-cache policy linux-image-4.19.0-4-686 me dit “500 http://deb.debian.org/debian buster/main i386 Packages” donc que c 'est du main
je télécharge donc http://ftp.debian.org/debian/pool/main/l/linux/ :
wget http://ftp.debian.org/debian/pool/main/l/linux/ -O a.html
puis
wget -c $(egrep '\.deb"' a.html |egrep '386|686' |sed 's#.*href="\(.*\.deb\)".*#http://ftp.debian.org/debian/pool/main/l/linux/\1#')
puis
find ~/mt9m114-camera/kernel/ -type f -exec dpkg-deb -c {} \; |grep mt9m114

re
je pars de la proposition de mattotop :
kernel 4.14.114 sur kernel.org
et cette page : https://computerz.solutions/kernel-4-debian-8/
un peu gêné de travailler avec un 4.19 mais j’y vais :

sudo apt-get install git build-essential libncurses5-dev xz-utils libelf-dev bc libssl-dev
tar xvf linux-4.14.114.tar.xz && cd linux-4.14.114 && cp /boot/config-4.19.0-4-686-pae .config
make nconfig

là il faut trouver mt9m114 avec F8 : on repère alors le chemin jusqu’au driver avec F8, puis on le suit avec ENTREE et on sélectionne avec espace ; puis save et exit
le fichier .config contient alors la référence cherchée :
grep -i atomisp .config
CONFIG_INTEL_ATOMISP=y
make clean && make deb-pkg
au premier coup : fatal error: openssl/opensslv.h d’où l’installation de libssl-dev

Gné ?
Le module c’est:
CONFIG_VIDEO_MT9M114

686… Tu es en 32 bits ?
Ca existe encore ?

pae, là, tu as un noyau patché, il faut réappliquer le patch pae sur ton noyau, sinon, il est probable que tes erreurs de compil viennent de là.

Ca ne passe pas mieux avec make-kpkg --initrd kernel_image kernel_headers ?

Bonjour,

Je pensais qu’il fallait les deux :
CONFIG_INTEL_ATOMISP et CONFIG_VIDEO_MT9M114

édit : je t’ai mal lu

Chapeau pour ta démarche dindoun :wink:

Je comprends, généralement on fait un upgrade avec.

salut
merci pour vos retours
ca n’a pas marché , à chaqur fois il me demande un nouveau module ( ici certs/x509_certificate_list

c’est lui qui a écrit dans le fichier : quand je cherche mt9t114 il me donne une arborescence pour choisir le driver, je l’ai fait . Et ca m’a parut acceptable vu le post de r2mi

exactement ca me donne ça :
Symbol: VIDEO_MT9M114 [=n] │
│ Type : tristate │
│ Prompt: Aptina mt9m114 sensor support │
│ Location: │
│ -> Device Drivers │
│ -> Staging drivers (STAGING [=y]) │
│ -> Media staging drivers (STAGING_MEDIA [=y]) │
│ -> Enable support to Intel MIPI camera drivers (INTEL_ATOMISP [=n]) │
│ Defined at drivers/staging/media/atomisp/i2c/Kconfig:51 │
│ Depends on: STAGING [=y] && STAGING_MEDIA [=y] && MEDIA_SUPPORT [=m] && INTEL_ATOMISP [=n] && I2C [=y] && VIDEO_V4L2 [│
│ │

en fait cette machine “asus de mierda” est un mélange de 32bits et 64bits : il a fallut installer un 32bits

dans le lien de mattotop https://www.debian.org/releases/stable/i386/ch08s06.html.fr il est proposé d’installer un kernel-package : il n’existe plus et surtout je ne trouve pas son remplaçant.

ca n’existe pas : peut etre en zsh ?
une recherche internet - sans gogol - semble dire que c’est inutilisable depuis l’abandon de kernel-package, ce qui est confirmé par le paragraphe 8.10.1 du handbook

De fait, ça faisait longtemps que je n’avais pas compilé de noyau.
Effectivement, l’instruction de compil, c’est bien make deb-pkg.
Par contre, plutôt que de recopier la config avant le menuconfig, il y a l’instruction make localmodconfig qui te fabrique une config spécifique à tes sources en se basant sur la config du noyau actif.

“comment out the lines CONFIG_SYSTEM_TRUSTED_KEY and CONFIG_MODULE_SIG_KEY”
trouvé dans https://unix.stackexchange.com/questions/293642/attempting-to-compile-any-kernel-yields-a-certification-error

j’essaie juste avec ça ( sans make localmodconfig )
sed “s/CONFIG_SYSTEM_TRUSTED_KEYS=/#CONFIG_SYSTEM_TRUSTED_KEYS=/” -i .config
sed “s/CONFIG_MODULE_SIG_KEY/#CONFIG_MODULE_SIG_KEY/” -i .config

Rappel : sed "s/truc/machin/" -i fichier rempalce la première occurrence de truc dans chaque ligne de ficheir et le remplace par machin
make clean && make deb-pkg
mais il pose des questions - je fais juste entrée

Généralement, lors de la première compilation d’un noyau il faut renseigner et désactiver beaucoup de paramètres du .config pour faire correspondre au matériel et choisir les fonctionnalités du noyau, que ce soit en mode texte, dialog / ncurses ou graphique. Avec les choix (Y/N/Module)

La toute première compilation est particulièrement difficile car il faut bien renseigner le .config
Sans laisser toutes les options mises par défaut.

Mais avec

Cela devrait simplifier grandement la tâche, si ça fonctionne bien pour une downgrade.

Après un premier amorçage réussi,
c’est beaucoup plus facile de peaufiner la config et compiler à nouveau.
Bien souvent, des options activées pour un maximum de compatibilité ne sont pas nécessaires.

Ok
c’est bien ce que j’avais cru comprendre
mais dans le tuto que j’ai vu ils proposent de faire un
cp /boot/config-$(uname -r) .config
ce qui doit faire à peu près pareil
et surtout, c’est plus rapide :slight_smile:
d’autant plus que la wifi et le son furent très compliqués à configurer
ensuite on verra

pour l’instant ca compile depuis 16h
ca fait des trucs comme

 CC [M]  sound/firewire/fireworks/fireworks_hwdep.o
  CC [M]  sound/firewire/fireworks/fireworks.o
  LD [M]  sound/firewire/fireworks/snd-fireworks.o
  AR      sound/firewire/motu/built-in.o
  CC [M]  sound/firewire/motu/motu.o
  CC [M]  sound/firewire/motu/amdtp-motu.o
  CC [M]  sound/firewire/motu/motu-transaction.o
  CC [M]  sound/firewire/motu/motu-stream.o

en particulier cette ligne :
CC [M] drivers/staging/media/atomisp/i2c/mt9m114.o

Oui, exactement pareil même (au final).
Faut voir ce que vont donner ces paramètres en 4.19 pour la compil du 4.14.114

C’est pas une bête de course ton Asus ! Au moins tu n’as pas eu d’erreur jusque là :wink:
Les messages sont tout à fait normaux.

Compilation C de la source mt9m114.o pour faire un module [M]

snif : No space left on device

il n’est pas drôle ton petit bijou !
c’est kwick là :woozy_face:

il devait rester pleins de trucs dans le .config dont ton T100TA n’a pas besoin.
même après 7 années avec Gentoo, je n’ai pas vraiment épuré le noyau.

mais pas grave c’était une bonne journée :

  • une de mes élèves qui part de très très loin vient de se payer 19 et 16 consécutivement .
  • j’ai demandé leur habilitation à deux contrôleurs qui ne l’avait pas

ouai c’est le plus important.

Au collège, pour l’épreuve du Brevet, quand j’ai vu l’alignement au cordeau des tables et chaises dans la grande salle de restaurant… J’ai fait demi-tour illico !

salut

cela signifie qu’il faudra d’autres compilations?

La compilation qui a échoué faute de place a quand même créé des fichiers .ko .o … Par erreur je les ai détruit mais ne serait-il pas possible de les utiliser sur mon noyau 4.19 ? Et sur les suivants ce qui permettrait de faire les upgrade ? avec genre un
sudo modprobe machin.ko

Si tu veux un noyau épuré et plus petit en taille.
Il peut aussi te manquer au premier essai une fonctionnalité ou un pilote.

Une recompilation est souvent plus rapide quand tout a été conservé ;
(pas de make clean ou équivalent ; sauf peut-être en cas d’échec)

Si ton .config est bien réussi, ce n’est pas une obligation.
Et il n’y aura probablement pas de kernel upgrade à faire après.

Je pense que les modules compilés sont “versionnés” avec la version du noyau qui est compilée.
C’est à vérifier cependant. (CONFIG_MODVERSIONS)

root@n40l:~# grep CONFIG_MODVERSIONS /boot/config-4.9.0-9-amd64
CONFIG_MODVERSIONS=y
rem@n40l:~$ 

Donc, je ne pense pas que tu puisses les utiliser avec ton noyau 4.19
et les mettre à jour avec ce dernier.

Tu peux essayer, mais le 4.19 peut te jeter ou ton système ne pas apprécier.
Et compiler avec un 4.19 des modules pour les charger sur un 4.14.114 posera le même problème.

root@n40l:/lib/modules/3.16.0-4-amd64/kernel/drivers/media/tuners# uname -a
Linux n40l 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 GNU/Linux
root@n40l:/lib/modules/3.16.0-4-amd64/kernel/drivers/media/tuners# ls
it913x.ko  m88rs6000t.ko  msi001.ko  mxl301rf.ko  qm1d1c0042.ko
root@n40l:/lib/modules/3.16.0-4-amd64/kernel/drivers/media/tuners# modprobe ./it913x.ko 
modprobe: FATAL: Module ./it913x.ko not found in directory /lib/modules/4.9.0-9-amd64
root@n40l:/lib/modules/3.16.0-4-amd64/kernel/drivers/media/tuners#

Comment tu vas augmenter l’espace dispo nécessaire pour compiler le 4.14.114 ?
Je ne sais même pas dans quel emplacement l’occupation disque augmente pour cette compilation.

facile :
le disque démarrait sur un 30 Go - j’avais oublié depuis le temps
il y a un deuxième disque 500 Go mais j’avais laissé windows dessus vu les problèmes
j’ai donc décidé de diminuer la partition windows , puis un ext4 (/dev/sdb2) +swap
puis
mv /home /home0 && mkdir /home
création d’un point de montage dans fstab de sdb2 vers /home
mount -a
cp -a /home0/caro /home/
et c’est fait

1 J'aime

Salut

Donc la compilation va se faire dans le nouveau /home/caro sur sdb2 ?
Et tu as préservé une sauvegarde dans /home0/caro ?

Tu as quel espace libre dans sdb2 ?

Je pense qu’il doit exister une possibilité de compiler sur une machine A un noyau - ou toute autre source - destiné pour une machine B ; pour profiter de la puissance de la machine A.
Je n’en sais pas plus.

Alors ? la compilation est lancée ?
Ou tu peaufines le .config ?
Tu as trouvé facilement l’option pour l’écran tactile ?

Après réflexion, perso, je n’aurais pas repris les options du noyau 4.19
mais j’aurai fait avec ce que le 4.14.114 propose.