07 Nov 2018, 00:00

Réinitialiser le mot de passe BIOS sur certains portables HP

HPBR

Un outil nommé HP Bios Reset permet, sur certains modèles, notamment des Probook et des Elitebook, de réinitialiser le mot de passe du bios. Lien vers le thread mydigitallife.
Et un exemplaire de HPBR mirroré chez moi

Il faut déjà créer la clé bootable.
Depuis Windows, il suffit de lancer l’exécutable, de brancher la clé (qui sera effacée), la sélectionner, cliquer sur Restore, choisir le fichier image fourni dans l’archive.
Sous Linux, je n’ai pas testé, mais je présume que l’image se dumpe simplement sur la clé avec dd.

On boote l’ordinateur sur la clé. Au lancement, il faut en trer les commandes suivantes :

cd ..
HPBR

Dans “reprogram” on peut sauvegarder les informations actuelles (fichiers .sav dans le répertoire HPBR).
Dans “first run” on peut lancer la réinit du mot de passe du bios en choisissant le bon modèle.

Forcer l’upgrade du bios

Dans mon cas, le bios était trop vieux, et n’était pas supporté par HPBR. J’ai donc du faire la mise à jour, mais la procédure standard me demandait le mot de passe, que je n’avais toujours pas.

Pour ceci, des indications données sur ce post peuvent être utiles. Les images et signatures de BIOS sont stockées dans le dossier Hewlett-Packard/BIOS/Current. L’image HPBR en contient certains, mais pas tous. On peut donc rajouter celui d’un autre modèle.
J’ai donc récupéré le bios le plus récent sur le site de support de HP.
J’ai extrait le fichier exe, puis le fichier rom.cab.
Dedans, il y’a un fichier “ver.txt”, on trouve dedans le numéro de la ROM, par exemple _ROM_ 68PDD v0F.20 12/07/2011 ROLL_BACK_WARNING
Dans ce cas, c’est “68PDD”. On renomme rom.bin par 68PDD.bin et efibios.sig par 68PDD.sig, on copie ces 2 fichiers dans “Current” (à noter que sur un clé usb vierge en fat32, l’arborescence et ces 2 fichiers suffisent pour la MAJ du BIOS, pas besoin de HPBR).
On éjecte la clé proprement.

Ensuite, il faut faire booter l’ordi sur la clé, mais pas par le boot habituel. Il faut, ordi éteint, brancher la clé, maintenir Super+B, allumer le pc en maintenant les touches enfoncées, normalement la LED de VerrMaj clignote, puis le voyant de la clé usb (s’il y’en a un…) va commencer à clignoter. C’est le moment de relacher les touches.

Normalement l’écran reste noir, pendant au maximum 2 minutes (selon le readme), puis devrait redémarrer tout seul et informer du succès de la mise à jour. Il est alors possible de reset le mot de passe via HPBR
Si rien ne se passe au bout de 10 minutes (soyons précautionneux…) ,c’est que la MAJ n’a pas réussi, et il faut redémarrer le poste.

29 Oct 2018, 00:00

Utilisation de ddrutility pour identifier les secteurs contenant de la données NTFS pour une utilisation optimale de ddrescue

Cet article se penche sur l’utilisation de ddrutility pour créer un fichier de carte de domaine à utiliser avec ddrescue, afin de focaliser ce dernier sur les secteurs qui contiennent effectivement des données. Dans cet exemple, je ne parle que du ntfs.

L’ensemble d’utilitaires ddrutility peut être installé depuis les dépôts Debian à partir de Buster, ou bien compilé depuis la source disponible ici.

L’utilitaire qui nous intéresse : ddru_ntfsbitmap qui va créer un fichier “domain_mapfile”, c’est-à-dire une liste des secteurs à lire sur la partition ntfs (secteurs effectivement utilisés).
Ceci ne fonctionnera que si ddrescuelog est présent dans la release de ddrescue (à partir de la version 1.15, normalement)

Création du fichier de délimitation du domaine

Voici la syntaxe pour une partition seule :

sudo ddru_ntfsbitmap /dev/sdX1 ./domain_ntfs.log

Dans mon cas, j’ai l’habitude de dumper le disque en entier, y compris la table de partitions. Pour ceci, il faut calculer l’offset de la partition (en octets) avec des maths assez simples : multiplier le secteur de démarrage de la partition par la taile d’un secteur en octets. Pour ceci : sudo fdisk -lu /dev/sdX qui nous donne par exemple :

Disk /dev/sdX: 465,7 GiB, 500074283008 bytes, 976707584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a183

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdX1        2048 976707583 976705536 465,7G  7 HPFS/NTFS/exFAT

On voit que la partition démarre au secteur 2048, et que chaque secteur pèse 512 bytes (octets). On multiplie donc : 2048*512 = 1048576, puis on passe l’argument -i à ddrutility, ce qui donne la commande

sudo ddru_ntfsbitmap /dev/sdX ./domain_ntfs.log -i 1048576

Ceci va aller lire le secteur de boot de la partition ntfs, puis la section bitmap afin de déterminer quels sont les clusters sur lesquels des données sont stockées. Selon la doc de ddrutility, si des secteurs du bitmap sont illisibles, alors ddrutility va les remplir avec le motif 0xFF (soit uniquement des 1), ce qui signifie que les secteurs en question sont utlisés pour stocker des données. Ainsi, en l’absence de certitude (grâce à la lecture correcte du bitmap) qu’un secteur est inutilisé, alors il sera extrait par ddrescue. On a ainsi le “risque” de lire des secteurs inutilisés, mais beaucoup moins de risque de sauter des secteurs sur lesquels des données sont effectivement stockées !

On obtient plusieurs fichiers en résultat :

  • __bootsec qui est un dump du secteur de boot de la partition (et est utilisé pour trouver l’emplacement de la MFT
  • __bootsec.log : la mapfile ddrescue utilisée pour l’extraction du secteur de boot

  • __mftshort : dump de la MFT

  • __mftshort.log : mapfile utilisée par ddrescue pour dumper la MFT

  • __bitmapfile : dump du fichier $BitMap de la partition

  • _partX__bitmapfile.log : fichier mapfile utilisé par ddrescue pour dumper le fichier $BitMap. Il est possible qu’il y en ait plusieurs si le fichier $BitMap est fragmenté

  • ntfsbitmap_rescue_report.log : résumé des différentes passes de ddru

  • domain_ntfs.log : le fichier à donner à ddrescue lors de la réelle tentative de récupération de données. Le nom dépend de la ligne de commande invoquée.

Utilisation de ce fichier avec ddrescue

Il faut impérativement penser à accorder la ligne de commande ddrescue avec celle utilisée par ddrutility pour obtenir le fichier domaine. Notamment déterminer si on dumpe une partition ou bien un disque entier. Dans mon cas, c’est un disque entier.
Une fois le fichier obtenu, on peut lancer la récupération de données avec ddrescue avec l’option -m, comme ceci :

sudo ddrescue -m ./domain_ntfs.log /dev/sdX ./disk_image.img mapfile.img

Si on souhaite suivre l’avancement en graphique avec ddrescueview, il est possible dans le menu de ce dernier d’ouvrir une mapfile de domaine (et séléctionner domain_ntfs.log). Ainsi, le secteurs hors domaine seront coloriés en grisé.

À noter qu’il est possible de combiner cette méthode avec ddrescue sans carte de domaine, en utilisant le même fichier source (disque défectueux), la même destination et la même mapfile. Après avoir laissé tourner ddrescue séquentiellement sur le disque, et une récupération extremement lente (quelques ko/s), j’ai repris l’avancement en cours en rajoutant l’argument de la carte de domaine. Il est également possible de reprendre le dump du disque sans carte de domaine une fois que tous les secteurs sur la carte de domaine ont été correctement récupérés (même si cevrait théoriquement être inutile).

18 Dec 2017, 00:00

Divers imprimantes

“Envoyé vers l’imprimante”

Sur un Windows Server 2012, les travaux restaient bloqués dans la file d’attente avec le statut “Envoyé vers l’imprimante”, bien qu’ils soient imprimés correctement. La solution qui semble bien marcher est de passer à un port type IP (au lieu d’un port WSD par exemple).

Outlook et les paramètres d’impression par défaut

Outlook 2016 a certains paramètres définis dans les “styles d’impression” (le style de base étant Mémo) qui outrepassent les réglages par défaut de l’imprimante (par exemple le choix du bac de sortie). Il faut les modifier directement dedans pour qu’il soient respectés.

14 Sep 2017, 00:00

Carte SD non reconnue si branchement à chaud

J’ai sur ma tour un lecteur de carte SD USB qui, depuis Stretch, ne monte plus automatiquement les cartes SD à la volée. Celles-ci sont bien lisibles lorsqu’elles sont déjà insérées lors du boot, mais l’ejection du media est définitive.

La solution, trouvée ici est d’ajouter le paramètre suivant à la ligne GRUB_CMDLINE_LINUX_DEFAULT= du fichier /etc/default/grub :
GRUB_CMDLINE_LINUX_DEFAULT="block.events_dfl_poll_msecs=2000"

Il faut ensuite lancer sudo update-grub pour actualiser le fichier de conf.

Si on veut appliquer le changement sans rebooter, on peut aussi entrer le paramètre 2000 au fichier /sys/module/block/parameters/events_dfl_poll_msecs

06 Dec 2016, 00:00

Mise en veille de l'écran récalcitrante

Il arrive, sous Linux, particulièrement après une install neuve ou bien une upgrade du système, que l’écran se mette en veille au bout d’un certain temps d’inactivité, quand bien même l’économiseur d’écran et l’extinction d’écran sont désactivés. Ceci est dû à la fonction DPMS de l’écran, qui se gère de manière distincte des 2 réglages précédents.

Pour la gérer, on utilise le programme xset. Pour sonder les paramètres actuellent en usage, on utilise xset q. Il est assez probable que les lignes suivantes apparaissent :

DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

Si on souhaite simplement désactiver dpms, il suffit de lancer xset -dpms, et les soucis de mise en veille intempestive de l’écran devraient disparaître ! Il est bien sûr possible de gérer les paramètres plus finement avec la sommande xset.

18 Sep 2016, 00:00

Utilisation de ddrescue pour dumper un disque en train de lâcher.

GNU ddrescue est un utilitaire conçu pour dumper intelligemment des disques ou partitions (ou autres périphériques de bloc), en sautant de zone, repartant de la fin du disque lorsqu’il rencontre une erreur ou des zones lentes, et y revenant plus tard, lorsque les secteurs encore lisibles ont été récupérés. Ce paragraphe de la page de man explique en détail l’algorithme utilisé (trimming, scraping etc).

Je dois beaucoup de ma compréhension du logiciel à ce très bon thread sur linuxfr

On commence par installer le soft, et l’interface graphique qui permet de surveiller l’avancement, avec des jolis petits carrés de couleur.

sudo aptitude install gddrescue ddrescueview

On réfléchit à si on souhaite dumper le disque complet, ou bien une partition. Dans cet exemple, une partition. Le support qui recevra le dump doit bien sûr être plus gros que le support source.

Première passe :

sudo ddrescue -n -f -b 512 /dev/sdi1 ./file.img mapfile

L’option -n dit à ddrescue de ne pas scraper les secteurs qu’il n’arrive pas à lire. Si j’ai bien compris, ça permet en gros de ne pas s’acharner maintenant sur ce qui n’est pas lisible.
L’option -f est inutile ici, car on écrit dans un fichier. Elle est cependant nécessaire si l’output est un block device (disque ou partition), c’est un garde-fou pour éviter d’écraser une partition par erreur.
L’option -b sert à spécifier la taille physique de secteurs du dique. C’est souvent 512, et c’esla valeur par défaut, mais il faut vérifier sur le disque en question (fdisk -l).
Le journal de la récupération est écrit dans le fichier mapfile précisé (on peut mettre le nom qu’on souhaite).

Si on veut cibler la récupération de données, par exemple si on a peu de données sur un gros disque, et qu’on suspecte qu’elles soient au début du disque, on peut spécifier une position de départ avec -i et une taille à couvrir par la recherche avec l’option -s. Par exemple :

sudo ddrescue -n -f -b512 -i0 -s30GiB /dev/sdi1 ./file.img mapfile

pour forcer le départ du début du disque et ne tester que les 30 premiers gibioctets.

On peut surveiller l’avancement grace à ddrescueview, si on ouvre mapfile.

Une fois que c’est fini, on lance la 2ème passe :

sudo ddrescue -d -r3 -f /dev/sdi1 ./file.img mapfile

L’option -d dit à ddrescue d’utiliser des accès directs au disque, en shuntant le cache du noyau, permettant dans certains cas une meilleure lecture. L’option -r3 dit à ddrescue d’essyer 3 fois la lecture sur les secteurs qu’il n’arrive pas à lire, avant de passer au suivant. Lors de cette phase, les secteurs seront “scrapés”, permettant soit leur récupération, soit leur classement en secteurs defectueux.

Durant la récupération de donées qui sert de support à cet article, j’ai été conronté à un autre problème : bien que toujours branché et detecté par l’OS (sdi), le disque s’est complètement arrêté de répondre. J’avais donc récupéré environ 100 Go de la partition, dont quelques secteurs en état “non-trimmed”, mais les 400 Go restant ont été classés d’office “failed”, chouette surprise au réveil.
Après avoir débranché le disque, l’avoir laissé reposer quelques minutes, je l’ai branché et il est redevenu lisible. Dans le but de limiter les accès, j’ai voulu conserver les 100 Go de données récupérées, tout en forçant ddrescue à repasser sur les zones marquées “failed”. Le paramètre -M sert dans ce cas, en marquant les blocs “failed” comme “non-trimmed”, et ils seront donc relus lors du processus. Ça donne :

sudo ddrescue -M -n -f /dev/sdi1 ./file.img mapfile

On peut aussi utiliser le paramètre -A, qui marque tous les blocs qui n’ont pas été lus avec succès comme “non-tried”. Ceci aurait cependant fait relire les secteurs sur lesquels il avait déjà buté avant que le disque arrête de répondre et qui avaient été marqués “non-trimmed” à raison.

Enfin, j’ai eu le cas d’un disque qui avait très peu de secteurs défectueux, mais dont la lecture était extrêmement lente, entre 6 et 10ko/s, probablement à cause de défaillances électroniques. Suite à la lecture de ce post, j’ai pu réduire le timeout et le error-handling timout du disque grâce aux commandes suivantes, en root :

echo 1 > /sys/block/<deviceName>/device/timeout
echo 1 > /sys/block/<deviceName>/device/eh_timeout

Ce qui m’a fait passer à une moyenne de 30ko/s, avec seulement 10 jours de récupération de données :D

03 Oct 2013, 00:00

Forcer l'actualisation des serveurs Orange pour la VoIP en cas de changement de Livebox

Lorsqu’une Livebox est remplacée, il faut qu’elle fasse une actualisation auprès des serveurs H323 (ou SIP selon le protocole) d’Orange. Ceci est fait automatiquement sous 24h.

On peut cependant souhaiter réactiver plus rapidement cet accès à la téléphonie. Il faut pour ceci redémarrer 3 fois la Livebox, à environ 5 minutes d’écart (s’assurer que la connexion au net se soit bien rétablie entre 2 redémarrages), en maintenant la Box débranchée au moins 1 minutes à chaque fois. À chaque redémarrage, elle forcera l’opération suivante d’actualisation du serveur (qui se fait normalement automatiquement toutes les 6 à 8h).

Ainsi, au bout du 3ème redémarrage au max, les informations entre la Livebox et les différents serveurs H323 seront cohérentes, et la connexion au réseau VoIP sera opérationnelle (le voyant téléphonique s’allume environ 2 minutes après que la connexion au net soit effective, c’est à dire que le voyant @ est allumé)

Source : un technicien du 3901 - méthode appliquée avec succès sur une Livebox Pro V2.

12 Jul 2011, 00:00

CPL

Normes CPL : Homeplug (14MBpS)

Homeplug Turbo (85)

Homeplug AV (200) | DS2 (200, beaucoup moins répandue)

(IEEE) P1901 (500)

Tout incompatible sauf P1901 qui est rétrocompatible avec Homeplug AV.

Peu importe la marque, l’important est la norme.

Les boitiers “HD” des FAI (Homeplug AV) pour la télé ont géneralement une encryption désactivée. Possible de la réactiver. Opération irréversible (?)

Prog de Devolo dLan cockpit.

Si le boitier a un bouton, il peut servir à l’appairage de plusieurs boitiers non vendus ensemble. Un peu plus dinfos ici :

http://r.orange.fr/r?ref=entraide_fil&url=http%3A//assistance.orange.fr/telechargement/notices/Guide_liveplug_HD_Solo.pdf

http://assistance.orange.fr/appairer-vos-liveplug-2966.php