Projet

Général

Profil

Task - Tâche #463

LENOVO S10-3 P/N : 0647

Ajouté par Stéphane Hays il y a plus de 14 ans. Mis à jour il y a environ 14 ans.

Statut:
Fixed - Corrigé - Implémenté
Priorité:
Normale
Assigné à:
Catégorie:
Double amorçage Linux/Windows
Version cible:
-
Début:
02/08/2010
Echéance:
26/08/2010
% réalisé:

100%

Temps estimé:
8.00 h

Description

10.1"
CPU intel Pineview N450 1.66G
1024 RAM
250Go DD
Lan 10/100

Attention, il existe au moins deux versions de S10-3 avec des puces wifi différentes:
  • maquette réalisée avec la puce broadcom
  • "correctif" sur apt.ryxeo.com/maquettes sous forme de scripts horizon.postrestaure + horizon-reconfigure.local pour les modèles à base d'atheros (pas de correctif pour la partie windows où le revendeur installe le driver manuellement pour l'instant)

Historique

#1 Mis à jour par Eric Seigne il y a plus de 14 ans

Vu avec stéphane en ssh sur ce poste pour la prise en charge du wifi, c'est une puce broadcom référence PCIid: 14e4:4727.

Normalement il suffit de télécharger les drivers broadcom et de les compiler, ça donne un module "wl" qui doit remplacer celui qui est fournis par le kernel officiel.

Mes tests rapides n'ont rien donnés. Les sources compilés sont dans /root du S10-3 (linux).

Peut-être faut il en complément un firmware ou tout simplement, après avoir fait le make && make install je n'ai pas fait de update-initramfs -u ça serait à tester (puis reboot).

Références (pour info mais il y a beaucoup de conneries dites sur ce forum): http://www.uluga.ubuntuforums.org/showthread.php?p=8992826

#2 Mis à jour par Eric Seigne il y a plus de 14 ans

  • % réalisé changé de 0 à 50

Bon, crétin que je suis hier j'ai pas pensé à supprimer le module wl.ko fournis par le kernel debian, je ne sais pas pourquoi (fatigue sans doute) je pensais que le make install des sources broadcom allait écraser le module existant.

Bref, un rm /lib/modules/2.6.28-19-generic/volatile/wl.ko a tout réglé, le module se charge bien et eth1 est disponible.

Par contre, je teste mais il semblerait que ça ne soit pas si utilisable que ça ...

#3 Mis à jour par Eric Seigne il y a plus de 14 ans

Bon,
finalement un reboot plus tard + quelques minutes tout semble bien marcher, je note tout de même au passage que j'ai fait un
  • iwconfig eth1 txpower on
  • iwlist eth1 txpower
  • iwlist eth1 scanning

Ensuite, pour éviter que le kernel ne se mette à jour et apporte un noyau qui ne gère pas le wifi, je supprime les paquets gênants:

apt-get remove linux-generic linux-headers-generic linux-image-generic linux-restricted-modules-generic

Reste à faire une image, déployer et tester la partie wifi avec la borne autoconfigurée et tout le trallala

#4 Mis à jour par Eric Seigne il y a plus de 14 ans

En attendant de trouver le fin mot de l'histoire, il faut faire un iwconfig eth1 txpower on si on veut que la puce wifi marche ... je l'ai ajouté temporairement dans /etc/rc.local pour voir mais je vais surtout chercher dans la doc & sur le net pour voir s'il n'y a pas une solution plus propre.

#5 Mis à jour par Stéphane Hays il y a plus de 14 ans

Se fige au boot. Message en mode "recovery" :

Error for wireless request "set Tx power" (8B27)
GET failed on device eth1 : no such device.
Error for wireless request "set Tx power" (8B27)
GET failed on device eth1 : no such device.

Le poste ne démarre pas X et reste au prompt.
Il "fige" en mode normal.
Je tente de renseigner /etc/network/interfaces => ça ne fonctionne pas, j'enlève.

#6 Mis à jour par Eric Seigne il y a plus de 14 ans

Pour information, le /lib/modules/<version>/volatile/wl.ko revient à chaque boot ... après recherche il s'avère que le répertoire volatile (son nom aurait du me faire tilter) contient en réalité tous les modules "restricted" et qu'il est en fait monté à chaque boot.

La commande "mount" indique que le répertoire volatile est un file system ...

lrm on /lib/modules/2.6.28-19-generic/volatile type tmpfs (rw,mode=755)

Et donc en réalité au boot il va chercher tout ce qui se trouve dans /lib/linux-restricted-modules/2.6.28-19-generic/ pour peupler le volatile ... j'ai donc viré tout ce qui parle du driver wl ubuntu dans ce répertoire rebooté le poste pour vérifier que le pb est bien terminé ...

Verdict dans 10 secondes ou 10 minutes en fonction de la vitesse de boot du poste.

C'est de la haute technicité et on en apprends tous les jours !

#7 Mis à jour par Stéphane Hays il y a plus de 14 ans

Le driver réseau realtek est déconfiguré lors du déploiement de l'image, ce qui interdit la jonction du domaine automagique.
Solution profitable pour d'autres types de drivers (SATA AHCI entre autres) :

1) Créer un dossier C:\i386\drivers lors de l'installation Xp
2) Créer les sous-dossiers C:\i386\drivers\lan ... video ... sata ... etc.
3) Ajouter les lignes au fichier sysprep section [Unattended] :

OemPnpDriversPath=i386\drivers\lan;i386\drivers\video
DriverSigningPolicy=Ignore

DriverSigningPolicy désactive la question concernant la signature des pilotes.

=> note ça ne fonctionne pas pour ce soucis précis mais je laisse pour info
=> sisi ça fonctionne mais avec la procédure suivante en complément !

#8 Mis à jour par Stéphane Hays il y a plus de 14 ans

Les pilotes en question ne sont pas signés.
Quand c'est le cas, il faut activer l'option -pnp de sysprep, sinon les drivers devront être installés manuellement par l'administrateur.

http://support.microsoft.com/kb/256204 dit : "_La stratégie de signature pour l'installation en mode graphique et l'Assistant de mini-installation Sysprep est la valeur «Warn.» Même si le paramètre «DriverSigningPolicy» a la valeur "Ignorer" dans le fichier Sysprep.inf, l'installation pilote non signé est repoussée jusqu'à ce que la première ouverture de session au cours de l'Assistant Mini-installation._"

Malgrès les recommandations du chef ;) il est donc conseillé d'exécuter sysprep avec les options suivants :

sysprep -reseal -mini -pnp

Et youpi ça fonctionne ! et en plus ça met même pas beaucoup plus de temps qu'un déploiement habituel.

Cette procédure n'annule pas la précédente mais la complète.

#9 Mis à jour par Eric Seigne il y a environ 14 ans

Stéphane,
je voulais te planter un coup de fil mais bon, je n'ai pas trouvé les images de sda1 et sda2 à recompresser en LZMA pour que ça rentre dans un DVD comme on en avait parlé avant tes congés, es-ce que t'aurais ça sous le coude qqpart ?

Éric

#10 Mis à jour par Stéphane Hays il y a environ 14 ans

  • Statut changé de New - Nouveau à Fixed - Corrigé - Implémenté
  • % réalisé changé de 50 à 100

#11 Mis à jour par Eric Seigne il y a environ 14 ans

  • Echéance mis à 26/08/2010
  • Statut changé de Fixed - Corrigé - Implémenté à Assigned - En cours
  • Assigné à changé de Stéphane Hays à Eric Seigne
  • % réalisé changé de 100 à 90

Stéphane,
ne pas oublier de m'affecter le ticket à la fin pour que je pense a envoyer l'image sur le serveur de téléchargement ...

#12 Mis à jour par Eric Seigne il y a environ 14 ans

  • Statut changé de Assigned - En cours à Fixed - Corrigé - Implémenté
  • % réalisé changé de 90 à 100

Tout est OK.

#13 Mis à jour par Stéphane Hays il y a environ 14 ans

Manque les fichiers horizon-postrestaure et sysprep dans l'iso du site maquette !!!
Je les ai dans mon disque USB.

#14 Mis à jour par Stéphane Hays il y a environ 14 ans

Fait sur l'école du val d'ornain (ingecom) qui a des S10-3 avec puce Atheros:
  • installation du paquet ubuntu module backports et validation
  • création d'un correctif sous forme de script de post-déploiement de clonezilla + script de reconfiguration locale spécifique de ce type de poste qui verrouille le noyau en version 2.6.28-19-generic et installe le paquet backports qui inclus le support de cette carte

Note: il ne faut pas installer ne paquet backports modules sur les S10-3 ayant une puce broadcom, ça provoque un conflit de module ...

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux