Forum Linux.mandriva Mandriva 2005LE vers 2006 : pb souris USB

• # Essayons toujours...

  Posté par clearstream le 24 septembre 2006 à 05:57. Évalué à 1.

  

  > Je redémarre mais il ne détecte pas les ports USB au démarrage contrairement à la 2005LE qui faisait un :
  > > Initializing USB Controller (uhci-hcd)
  > > Initializing USB Controller (ehci-hcd)
  > > Mount USB filesystem
  
  Si c'est comme sous Fedora,normalement uhci-hcd et ehci-hcd sont chargés avec initrd.
  
  Au cas où tu ne connais pas initrd, je redonne la séquence de boot de linux dans les très très grandes lignes:
  -> grub/lilo
  -> chargement de initrd
  -> noyau
  -> Exécution du /init dans initrd
  -> montage partition root
  -> le processus init lance la suite
  
  Ce qui faut bien noter ici, c'est que lorsque le noyau et initrd sont chargés, on a un OS fonctionnel (certe il ne peut pas faire grand chose vu le peut de place disponible dans initrd) et on y fait des choses.
  
  Sous Fedora [ue]hci-hcd sont chargés via initrd. Ça permet d'avoir une clée USB en root entre autre.
  Via initrd, ces modules sont chargées avec le script init qui est dans initrd.
  Voilà la séquence (j'ai viré quelques lignes):

  echo "Loading uhci-hcd.ko module"
  insmod /lib/uhci-hcd.ko
  echo "Loading ohci-hcd.ko module"
  insmod /lib/ohci-hcd.ko
  echo "Loading ehci-hcd.ko module"
  insmod /lib/ehci-hcd.ko
  mount -t usbfs /proc/bus/usb /proc/bus/usb
  echo "Loading scsi_mod.ko module"
  insmod /lib/scsi_mod.ko
  echo "Loading sd_mod.ko module"
  insmod /lib/sd_mod.ko
  echo "Loading usb-storage.ko module"
  insmod /lib/usb-storage.ko
  echo Waiting for driver initialization.
  stabilized /proc/bus/usb/devices

  
  
  Ce script est uniquement lu par nash (un petit programme développé par Red Hat mais que Mandriva utilise très probablement).
  Les lignes "insmod ......ko" charge des modules qui sont dans initrd.
  Peut-être qu'il te manque les lignes relatives à uhci-hcd et peut-être aussi le module dans initrd.
  
  Si c'est le car, il te faut refaire ton initrd (crée en un nouveau et n'écrase pas l'actuel, initrd est critique dans le boot dans système).
  
  Le mieux est de remplace l'initrd actuel. Pour l'exemple, je vais éditer le mien (/boot/initrd-2.6.18-1.2689.fc6.img) et en créer un nouveau.

  [root@localhost ~]# cd /boot/
  [root@localhost boot]# mkdir tmp
  [root@localhost boot]# cd tmp/
  [root@localhost tmp]# zcat ../initrd-2.6.18-1.2689.fc6.img | cpio -i -m
  6664 blocks
  [root@localhost tmp]# ll
  total 9
  drwx------ 2 root root 1024 sep 24 05:39 bin
  drwx------ 3 root root 1024 sep 24 05:39 dev
  drwx------ 2 root root 1024 sep 22 21:53 etc
  -rwx------ 1 root root 1843 sep 22 21:53 init
  drwx------ 2 root root 1024 sep 24 05:39 lib
  drwx------ 2 root root 1024 sep 22 21:53 proc
  lrwxrwxrwx 1 root root 3 sep 24 05:39 sbin -> bin
  drwx------ 2 root root 1024 sep 22 21:53 sys
  drwx------ 2 root root 1024 sep 22 21:53 sysroot
  [root@localhost tmp]# vim init # ajout de uhci-hcd
  [root@localhost tmp]# cp -p /lib/modules/2.6.18-1.2689.fc6/kernel/drivers/usb/host/uhci-hcd.ko lib/ # copie de uhci pour l'intégrer dans initrd
  [root@localhost tmp]# find * -print0 | cpio -o -c --null | gzip -9 > ../initrd-2.6.18-1.2689.fc6_custom.img
  6664 blocks
  [root@localhost tmp]# cd ..
  [root@localhost boot]# rm -r -f tmp/
  [root@localhost boot]# # Et voilà

  
  Après j'ajoute une entrée dans grub (il n'y a pas lilo sous Fedora) pour utiliser ce nouveau initrd. Donc je vais avoir deux entrées pour le même noyau :

  title Fedora Core (2.6.18-1.2689.fc6)
  root (hd0,0)
  kernel /vmlinuz-2.6.18-1.2689.fc6 ro root=LABEL=small_fs quiet
  initrd /initrd-2.6.18-1.2689.fc6.img
  
  title Fedora Core (2.6.18-1.2689.fc6) avec uhci-hcd dans initrd
  root (hd0,0)
  kernel /vmlinuz-2.6.18-1.2689.fc6 ro root=LABEL=small_fs quiet
  initrd /initrd-2.6.18-1.2689.fc6_custom.img

  
  
  Normalement on peut aussi faire ça via la commande mkinitrd. Par exemple avec : mkinitrd --with=uhci-hcd /boot/initrd-2.6.18-1.2689.fc6_custom.img 2.6.18-1.2689.fc6
  
  
  A toi de jouer :-)

  • [^] # Re: Essayons toujours...

    Posté par XiaoKe le 27 septembre 2006 à 07:50. Évalué à 1.

    

    Merci clearstream pour ta réponse. Malheureusement, j'ai deux problèmes:

    1. Je n'ai pas nash et je n'arrive pas à lire /boot/initrd.img avec vi. Je n'ai pas trouvé nash à télécharger sur Internet. Et j'aimerais bien pouvoir voir ce qu'il y a dans ce fichier!
    2. J'aimerais que tu m'expliques ce que tu fais pour les opérations suivantes :

    [root@localhost tmp]# zcat ../initrd-2.6.18-1.2689.fc6.img | cpio -i -m
    6664 blocks

    [root@localhost tmp]# ll
    total 9
    drwx------ 2 root root 1024 sep 24 05:39 bin
    drwx------ 3 root root 1024 sep 24 05:39 dev
    drwx------ 2 root root 1024 sep 22 21:53 etc
    -rwx------ 1 root root 1843 sep 22 21:53 init
    drwx------ 2 root root 1024 sep 24 05:39 lib
    drwx------ 2 root root 1024 sep 22 21:53 proc
    lrwxrwxrwx 1 root root 3 sep 24 05:39 sbin -> bin
    drwx------ 2 root root 1024 sep 22 21:53 sys
    drwx------ 2 root root 1024 sep 22 21:53 sysroot

    [root@localhost tmp]# find * -print0 | cpio -o -c --null | gzip -9 > ../initrd-2.6.18-1.26
    89.fc6_custom.img
    6664 blocks

    histoire d'avancer avec GNU/Linux ;-)

    Merci d'avance et encore merci de m'avoir répondu!

    • [^] # Re: Essayons toujours...

      Posté par XiaoKe le 28 septembre 2006 à 08:22. Évalué à 1.

      

      clearstream, j'ai fait comme tu m'as indiqué mais j'ai le résultat suivant:

      [root@tu053053 tmp]# zcat ../initrd-2.6.11-6mdk.img | cpio -i -m
      cpio: warning: skipped 355840 bytes of junk
      cpio: ./dev/pts: No such file or index
      cpio: invalid head: verification and error
      
      zcat: ../initrd-2.6.11-6mdk.img: decompression OK, trailing garbage ignored
      cpio: file unusual termination 
      [root@tu053053 Tmp]# ll
      Total volume 0
      [root@tu053053 tmp]#

      Donc, je ne sais pas quoi faire... Merci d'avance pour vos conseils avisés.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.