Re: GRUB : listes de blocs, erreur : résolu

[andre_debian]

On Friday 13 April 2018 13:57:18 Pascal Hambourg wrote:
> Le 13/04/2018 à 11:11, andre_deb...@numericable.fr a écrit :
> > On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
> > Le 11/04/2018 à 11:38, Klaus Becker a écrit :
> >>> Pour installer grub, il faut toujours /dev/sdx :

> >> Non, c'est faux :
> > Si, c'est bien /dev/sdx soit /dev/sda

> Dans ton cas peut-être, mais pas forcément dans le cas général.

> Primo, le "disque" ne s'appelle pas toujours /dev/sd*. Seuls les disques 
> SCSI ou dont les pilotes utilisent une couche d'émulation SCSI (PATA et 
> SATA avec libata, USB...) sont nommés ainsi. Les disques IDE avec les 
> anciens pilotes IDE sont nommés /dev/hd*, les cartes flash SD ou MMC 
> dans un lecteur natif (pas un lecteur USB qui émule un support de 
> stockage USB) et les SSD eMMC sont nommés /dev/mmcblk*, les nouveaux SSD 
> NVMe sont nommés /dev/nvme*...

> Secundo, on peut installer GRUB dans le secteur d'amorce d'une partition 
> et pas forcément dans le MBR du disque. Certes il ne sera pas lancé 
> directement par le BIOS. L'intérêt est de ne pas écraser le programme 
> d'amorce actuel du MBR. Les raisons possibles sont multiples :
> 
> - L'amorce de GRUB dans le MBR n'est pas compatible avec le BIOS 
> (tatouage ou autre). On marque la partition contenant l'amorce de GRUB 
> comme active/amorçable et on laisse au programme d'amorce du MBR le soin 
> de lancer l'amorce de la partition active.

> - On veut conserver le programme d'amorce actuel du MBR comme chargeur 
> principal et chaîner le chargeur secondaire situé dans le secteur 
> d'amorce d'une partition. C'est particulièrement souhaitable si la plus 
> récente installation est provisoire, car le programme d'amorce de GRUB 
> n'est pas autonome : il a besoin du contenu de /boot/grub. Si on efface 
> la partition qui contient /boot/grub, ce qui reste de GRUB dans le MBR 
> ne sera plus capable d'afficher le menu de démarrage ni de lancer aucun 
> système d'exploitation.

> - Même si on n'a pas besoin d'installer GRUB sur le système secondaire 
> puisque le GRUB du système principal peut parfaitement démarrer le 
> système secondaire, il peut être souhaitable que le système secondaire 
> ait un fichier de configuration grub.cfg sur lequel le GRUB principal va 
> s'appuyer pour créer les entrées de menu du système secondaire. Un moyen 
> simple que ce fichier grub.cfg existe soit mis à jour est d'installer 
> GRUB, même si ce n'est pas indispensable.

Merci pour cette piqûre de rappel de Grub.

Pour un pc portable, un seul disque dur SATA (non SSD), Windows en sda1,
Linux en sda2, la commande "grub-install /dev/sda" est fonctionnelle,
(et non "grub-install /dev/sda1") qui m'affiche un msg d'erreur.
Elle permet d'amorcer grub depuis le MBR je pense.
Pour les autres solutions que tu décris, telle :
"...MBR comme chargeur principal et chaîner le chargeur secondaire",
quelle est la syntaxe de "grub-install" ?

Bonne fin de soirée.

Re: Pilote carte vidéo AMD Radeon 6550M stretch : résolu

[andre_debian]

On Friday 13 April 2018 21:25:16 Étienne Mollier wrote:
> > "/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type"
> > Pourtant, j'ai bien ce fichier dans mon répertoire /boot :
> > /boot/config-4.9.0-6-686-pae :

> À ma connaissance, la seule manière d'avoir un fichier absent,
> mais présent en apparence, est d'avoir un lien symbolique brisé,
> une sorte de raccourci vers un fichier qui n'existerait plus.  Si
> c'est le cas, ça devrait se voir en faisant un :
>   $ ls -l /boot/config-4.9.0-6-686-pae
>   $ ls -l /boot
> Dans le doute, est ce que le système de fichier hébergeant le
> /boot/ est plein ?  Chez moi il n'y a pas de problèmes, du moins
> pas apparents, et le système de fichier sous-jacent est rempli à
> 86% par exemple :
>   $ df /boot/
>   Filesystem 1K-blocks Used Available Use% Mounted on
>   /dev/sda7   13889020 11186404   1974040  86% /
> On a vu plus d'une erreur bizarre causée au final par un disque
> plein... :

Le fichier y est bel et bien évidemment :-) 

> > Y a t-il une erreur dans la commande ? :
> > grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
> > et
> > faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?
> 
> Il y a à priori pas d'erreur dans la commande, et la chaîne
> "CONFIG_DRM_RADEON=m" aurait dû être le résultat, donc pas à
> taper.  Vous avez correctement interprété le contenu de mon
> courriel initial.  :-)
> L'idée était d'utiliser "grep" pour trouver toutes les lignes
> contenant "CONFIG_DRM_RADEON=" dans le fichier de configuration
> de la compilation du noyau "/boot/config-", où la
> version était obtenue dynamiquement avec la commande "uname -r",
> injectée à la fin du nom de fichier avec la syntaxe propre à bash
> en "$(commande)".
> Avec ce genre de commande et de fichier, les quatre résultats
> possible sont :
> 1. CONFIG_DRM_RADEON=m : devrait apparaitre avec le noyau
>4.9.0-6-686-pae par défaut ;
> 2. CONFIG_DRM_RADEON=y : apparait quand pilote radeon a été
>compilé en statique, au lieu d'être un module dynamique ;
> 3. pas de résultat affiché : le noyau n'a pas été configuré pour
>embarquer le pilote ;
> 4. erreur : le fichier de configuration n'a pas pu être lu, pour
>une raison quelconque.
> Nous sommes dans le cas numéro quatre :

La commande grep CONFIG_DRM_RADEON="/boot/config-$(uname -r)"
a fini par marcher :
J'ai obtenu la ligne :  CONFIG_DRM_RADEON=m
et plein d'autres... Dnc ça doit être bon.

Merci et bonne fin de soirée.

André

Re: Pilote carte vidéo AMD Radeon 6550M stretch : résolu

[Étienne Mollier]

Bonsoir,

André, le vendredi 13 avril 2018 :
> "/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type"
> Pourtant, j'ai bien ce fichier dans mon répertoire /boot :
> /boot/config-4.9.0-6-686-pae

À ma connaissance, la seule manière d'avoir un fichier absent,
mais présent en apparence, est d'avoir un lien symbolique brisé,
une sorte de raccourci vers un fichier qui n'existerait plus.  Si
c'est le cas, ça devrait se voir en faisant un :

$ ls -l /boot/config-4.9.0-6-686-pae

Ou bien, si la commande précédente est récalcitrante :

$ ls -l /boot


Dans le doute, est ce que le système de fichier hébergeant le
/boot/ est plein ?  Chez moi il n'y a pas de problèmes, du moins
pas apparents, et le système de fichier sous-jacent est rempli à
86% par exemple :

$ df /boot/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7   13889020 11186404   1974040  86% /

On a vu plus d'une erreur bizarre causée au final par un disque
plein...


> Y a t-il une erreur dans la commande ? :
> grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
> et
> faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?

Il y a à priori pas d'erreur dans la commande, et la chaîne
"CONFIG_DRM_RADEON=m" aurait dû être le résultat, donc pas à
taper.  Vous avez correctement interprété le contenu de mon
courriel initial.  :-)

L'idée était d'utiliser "grep" pour trouver toutes les lignes
contenant "CONFIG_DRM_RADEON=" dans le fichier de configuration
de la compilation du noyau "/boot/config-", où la
version était obtenue dynamiquement avec la commande "uname -r",
injectée à la fin du nom de fichier avec la syntaxe propre à bash
en "$(commande)".

Avec ce genre de commande et de fichier, les quatre résultats
possible sont :

1. CONFIG_DRM_RADEON=m : devrait apparaitre avec le noyau
   4.9.0-6-686-pae par défaut ;

2. CONFIG_DRM_RADEON=y : apparait quand pilote radeon a été
   compilé en statique, au lieu d'être un module dynamique ;

3. pas de résultat affiché : le noyau n'a pas été configuré pour
   embarquer le pilote ;

4. erreur : le fichier de configuration n'a pas pu être lu, pour
   une raison quelconque.

Nous sommes dans le cas numéro quatre.


À plus,
-- 
Étienne Mollier 

Squid et paramétrages NTLM

[Eric Bernard]

Bonjour,
Je recherche en vain documentation(s) ou exemple(s) concret sur le 
paramétrage dans Squid >:o :


- ntlm_smb_lm_auth
- ntlm_fake_auth

Le but est de récupérer de manière transparente les identifiants de 
connexion (login et password) de la session windows ouverte dans un 
domaine Samba 3 (annuaire LDAP ) !!!


Merci de vos réponses 

Cordialement


--



  Eric BERNARD
  Responsable informatique
  et multimédia
  02 41 51 11 36

Re: Plantage bizarre

[Daniel Caillibaud]

Le 11/04/18 à 21:11, Daniel Caillibaud  a écrit :
DC> Donc je vois toujours pas…

Changer la carte réseau a réglé le souci.

Le pb se posait avec l'interface Gbps intégrée à la carte mère. Une vieille
carte 10/100 qui était branchée mais ne servait plus depuis longtemps
n'avait pas donné de meilleur résultat (et elle n'était plus reconnue
depuis ma réinstall), son clone rigoureusement du même modèle (SMC 1211)
règle le pb !

Je comprends toujours pas pourquoi un pb hardware sur une carte réseau peut
donner ces symptômes, tout marche sauf sur un host, et pas tout le temps
(en https avec le browser, j'arrivais à me logguer en insistant, mais
seulement avec chromium, quasi jamais avec firefox), et pas avec tous les
dépôts (avec certains ça marchait en forçant le cipher, pas d'autres).

Je suppose que ça dépend de la taille des paquets tcp, ou un truc du genre,
mais j'y ai laissé qq touffes de cheveux…

-- 
Daniel

Méfie-toi des proverbes chinois
Proverbe berrichon

Re: GRUB : listes de blocs, erreur : résolu

[Pascal Hambourg]

Le 13/04/2018 à 11:11, andre_deb...@numericable.fr a écrit :

On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:

Le 11/04/2018 à 11:38, Klaus Becker a écrit :

Pour installer grub, il faut toujours /dev/sdx :



Non, c'est faux :


Si, c'est bien /dev/sdx soit /dev/sda


Dans ton cas peut-être, mais pas forcément dans le cas général.

Primo, le "disque" ne s'appelle pas toujours /dev/sd*. Seuls les disques 
SCSI ou dont les pilotes utilisent une couche d'émulation SCSI (PATA et 
SATA avec libata, USB...) sont nommés ainsi. Les disques IDE avec les 
anciens pilotes IDE sont nommés /dev/hd*, les cartes flash SD ou MMC 
dans un lecteur natif (pas un lecteur USB qui émule un support de 
stockage USB) et les SSD eMMC sont nommés /dev/mmcblk*, les nouveaux SSD 
NVMe sont nommés /dev/nvme*...


Secundo, on peut installer GRUB dans le secteur d'amorce d'une partition 
et pas forcément dans le MBR du disque. Certes il ne sera pas lancé 
directement par le BIOS. L'intérêt est de ne pas écraser le programme 
d'amorce actuel du MBR. Les raisons possibles sont multiples :


- L'amorce de GRUB dans le MBR n'est pas compatible avec le BIOS 
(tatouage ou autre). On marque la partition contenant l'amorce de GRUB 
comme active/amorçable et on laisse au programme d'amorce du MBR le soin 
de lancer l'amorce de la partition active.


- On veut conserver le programme d'amorce actuel du MBR comme chargeur 
principal et chaîner le chargeur secondaire situé dans le secteur 
d'amorce d'une partition. C'est particulièrement souhaitable si la plus 
récente installation est provisoire, car le programme d'amorce de GRUB 
n'est pas autonome : il a besoin du contenu de /boot/grub. Si on efface 
la partition qui contient /boot/grub, ce qui reste de GRUB dans le MBR 
ne sera plus capable d'afficher le menu de démarrage ni de lancer aucun 
système d'exploitation.


- Même si on n'a pas besoin d'installer GRUB sur le système secondaire 
puisque le GRUB du système principal peut parfaitement démarrer le 
système secondaire, il peut être souhaitable que le système secondaire 
ait un fichier de configuration grub.cfg sur lequel le GRUB principal va 
s'appuyer pour créer les entrées de menu du système secondaire. Un moyen 
simple que ce fichier grub.cfg existe soit mis à jour est d'installer 
GRUB, même si ce n'est pas indispensable.

Re: GRUB : listes de blocs, erreur : résolu

[Michel]

Le 13/04/2018 à 11:30, Klaus Becker a écrit :
> Le vendredi 13 avril 2018, 11:11:31 CEST andre_deb...@numericable.fr a écrit :
>> On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
>> "Le système de fichiers NTFS ne prend pas en charge l'empaquetage :
>>> "empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ? :
>> Erreur de ma part, c'est bien "embarquage", désolé.
>>
>> Le 11/04/2018 à 11:38, Klaus Becker a écrit :
 Pour installer grub, il faut toujours /dev/sdx :
>>> Non, c'est faux :
>> Si, c'est bien /dev/sdx soit /dev/sda
>>
>> André
> 
> On peut installer grub sur une autre partoche,par ex sda1, mais je ne sais 
> pas 
> trop à quoi ça sert, on ne le verra pas au démarrage sur sda1.
> 
> Klaus
> 
C'est utile si tu as plusieurs installation sur la même machine par
exemple. La distribution principale installera grub sur /dev/sdx, elle.

Re: GRUB : listes de blocs, erreur : résolu

[Eric Degenetais]

Le 13 avril 2018 à 11:22, Klaus Becker  a écrit :
> On peut installer grub sur une autre partoche,par ex sda1, mais je ne
sais pas
> trop à quoi ça sert, on ne le verra pas au démarrage sur sda1.
>
> Klaus
>
Ne serais-ce pas par hasard pour le chaînage de boot ?
Par exemple, il me semble qu'à une époque on pouvait utiliser le bootloader
de W$ pour passer la main à grub installé sur une partition linux qui lui à
son tour amorçait le linux installé dans la partition.

Cordialement
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org

Re: GRUB : listes de blocs, erreur : résolu

[Klaus Becker]

Le vendredi 13 avril 2018, 11:11:31 CEST andre_deb...@numericable.fr a écrit :
> On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
>  "Le système de fichiers NTFS ne prend pas en charge l'empaquetage :
> > "empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ? :
> Erreur de ma part, c'est bien "embarquage", désolé.
> 
> Le 11/04/2018 à 11:38, Klaus Becker a écrit :
> >> Pour installer grub, il faut toujours /dev/sdx :
> > Non, c'est faux :
> Si, c'est bien /dev/sdx soit /dev/sda
> 
> André

On peut installer grub sur une autre partoche,par ex sda1, mais je ne sais pas 
trop à quoi ça sert, on ne le verra pas au démarrage sur sda1.

Klaus

Re: Conversion avi vers 3gp [HS]

[Klaus Becker]

Le vendredi 13 avril 2018, 11:02:34 CEST Yann Serre a écrit :
> Changement de format de conteneur avec VLC ?
> 3GP est proche du mp4
> 
> Le 13/04/2018 à 10:58, Klaus Becker a écrit :
> > Salut,
> > 
> > J'ai copié une vidéo au format avi sur un tél. portable. Seulement elle ne
> > s'affiche pas sous "vidéos". J'y vois seulement une vidéo que j'ai
> > enregistrée avec le tél., c'est au format 3gp.
> > 
> > Je ne connais pas ce format. Renommer la vidéo en *.3gp ne fonctionne pas.
> > Dans avidemux que j'utilise d'habitude pour changer de format vidéo, je ne
> > trouve pas 3gp.
> > 
> > Je ne sais pas comment faire.
> > 
> > Ciao
> > 
> > Klaus

Merci de la réponse ultra-rapide.

En effet, j'ai copié une vidéo mp4 sur le tél. Et je peux la lire.
Par contre j'ai transformé la vidéo en question en mp4 avec avidemux, et là le 
tél. ne l'affiche pas.

Entretemps un ami m'a conseillé d'installer vlc sur le tél. Je vais essayer 
ça, ce sera plus simple.

Bye

Klaus

Re: Pilote carte vidéo AMD Radeon 6550M stretch : résolu

[andre_debian]

On Thursday 12 April 2018 19:42:40 Étienne Mollier wrote:
> >>$ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
> >>CONFIG_DRM_RADEON=m
> > Je reçois la réponse : "aucun fichier ou dossier de ce type"

> C'est curieux que le noyau en cours d'exécution n'ait pas sa
> configuration correspondante dans /boot, mais bon, admettons, je
> suis peut-être passé à côté de la convention de nommage, à
> vouloir faire le malin avec de la détection automatique...

Bonjour, merci pour votre aide qui m'a aidé.

"/boot/config-4.9.0-6-686-pae : aucun fichier ou dossier de ce type"
Pourtant, j'ai bien ce fichier dans mon répertoire /boot :
/boot/config-4.9.0-6-686-pae

Y a t-il une erreur dans la commande ? :
grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
et
faut-il taper "CONFIG_DRM_RADEON=m" à la suite ou ensuite ?

Bonne journée,

André

Re: GRUB : listes de blocs, erreur : résolu

[andre_debian]

On Thursday 12 April 2018 00:05:29 Pascal Hambourg wrote:
 "Le système de fichiers NTFS ne prend pas en charge l'empaquetage :

> "empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ? :

Erreur de ma part, c'est bien "embarquage", désolé.

Le 11/04/2018 à 11:38, Klaus Becker a écrit :
>> Pour installer grub, il faut toujours /dev/sdx :

> Non, c'est faux :

Si, c'est bien /dev/sdx soit /dev/sda

André 

Re: Conversion avi vers 3gp [HS]

[Yann Serre]

Changement de format de conteneur avec VLC ?
3GP est proche du mp4

Le 13/04/2018 à 10:58, Klaus Becker a écrit :

Salut,

J'ai copié une vidéo au format avi sur un tél. portable. Seulement elle ne
s'affiche pas sous "vidéos". J'y vois seulement une vidéo que j'ai enregistrée
avec le tél., c'est au format 3gp.

Je ne connais pas ce format. Renommer la vidéo en *.3gp ne fonctionne pas.
Dans avidemux que j'utilise d'habitude pour changer de format vidéo, je ne
trouve pas 3gp.

Je ne sais pas comment faire.

Ciao

Klaus

Conversion avi vers 3gp [HS]

[Klaus Becker]

Salut,

J'ai copié une vidéo au format avi sur un tél. portable. Seulement elle ne 
s'affiche pas sous "vidéos". J'y vois seulement une vidéo que j'ai enregistrée 
avec le tél., c'est au format 3gp.

Je ne connais pas ce format. Renommer la vidéo en *.3gp ne fonctionne pas. 
Dans avidemux que j'utilise d'habitude pour changer de format vidéo, je ne 
trouve pas 3gp.

Je ne sais pas comment faire.

Ciao

Klaus

Re: Détection automatique d'une connection USB

[Danilo Uccelli]

Le 13 avril 2018 à 09:15, Pascal Hambourg  a écrit :

> Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :
>
>>
>> Effectivement un des problèmes était bien le manque de slash et j'ai aussi
>> bien compris la faille de sécurité que cela crée.
>>
>
> Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et
> sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin.
>
> J'ai donc donné à root la propriété du script.
>>
>
> Pas suffisant car le propriétaire non root du répertoire contenant le
> script peut toujours le supprimer, le renommer et le remplacer par ce qu'il
> veut.
>
> Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il
>> suffit d'exécuter le script une seule fois au démarrage, ensuite le
>> périphérique se monte tout seul. J'ai donc fait un crontab en root, au
>> démarrage.
>>
>
> Il y a mieux qu'un cronjob, je trouve.
> Pour charger un module au démarrage, on peut le mentionner dans le fichier
> /etc/modules.
> Pour qu'il soit chargé automatiquement lors de la détection d'identifiants
> donnés, on peut créer un alias pour modprobe (cf. man modprobe.d).
> Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendor et
> product permettant de spécifier ses propres identifiants, qui peuvent être
> ajoutés par modprobe.
>
> # modinfo -p ftdi_sio
> debug:Debug enabled or not (bool)
> vendor:User specified vendor ID (default=0x0403) (ushort)
> product:User specified product ID (ushort)
> ndi_latency_timer:NDI device latency timer override (int)
>
> Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi_sio.conf
> :
>
> alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio
> options ftdi_sio vendor=0x0403 product=0xEFE0
>
> A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les
> identifiants en hexadécimal.
>
> Pour finir, note qu tu aurais pu et pourrais encore demander à ce que tes
> identifiants personnalisés soient ajoutés au module ftdi_sio directement
> dans les sources du noyau, comme beaucoup d'autres semblent l'être déjà.
>
>
Oui, c'est vrai, il est dans /bin, cependant il maquait bien le slash.

Merci infiniment pour cette explication intéressante et détaillée, je vais
essayer tout ça.

Danilo

Re: Détection automatique d'une connection USB

[Pascal Hambourg]

Le 13/04/2018 à 07:31, Danilo Uccelli a écrit :


Effectivement un des problèmes était bien le manque de slash et j'ai aussi
bien compris la faille de sécurité que cela crée.


Quel manque de slash ? Tu veux dire qu'il manquerait un / entre /sbin et 
sh ? Sûrement pas, car /sbin/sh n'existe pas ; sh est dans /bin.



J'ai donc donné à root la propriété du script.


Pas suffisant car le propriétaire non root du répertoire contenant le 
script peut toujours le supprimer, le renommer et le remplacer par ce 
qu'il veut.



Puis, j'ai réalisé que udev n'était pas la meilleure solution puisque il
suffit d'exécuter le script une seule fois au démarrage, ensuite le
périphérique se monte tout seul. J'ai donc fait un crontab en root, au
démarrage.


Il y a mieux qu'un cronjob, je trouve.
Pour charger un module au démarrage, on peut le mentionner dans le 
fichier /etc/modules.
Pour qu'il soit chargé automatiquement lors de la détection 
d'identifiants donnés, on peut créer un alias pour modprobe (cf. man 
modprobe.d).
Et modinfo nous apprend que le module ftdi_sio a deux paramètres vendor 
et product permettant de spécifier ses propres identifiants, qui peuvent 
être ajoutés par modprobe.


# modinfo -p ftdi_sio
debug:Debug enabled or not (bool)
vendor:User specified vendor ID (default=0x0403) (ushort)
product:User specified product ID (ushort)
ndi_latency_timer:NDI device latency timer override (int)

Cela pourrait être rassemblé dans un fichier /etc/modprobe.d/ftdi_sio.conf :

alias usb:v0403pEFE0d*dc*dsc*dp*ic*isc*ip* ftdi_sio
options ftdi_sio vendor=0x0403 product=0xEFE0

A tester et vérifier. Je ne suis pas sûr s'il faut 0x devant les 
identifiants en hexadécimal.


Pour finir, note qu tu aurais pu et pourrais encore demander à ce que 
tes identifiants personnalisés soient ajoutés au module ftdi_sio 
directement dans les sources du noyau, comme beaucoup d'autres semblent 
l'être déjà.