Présentation et analyse

Si on a créé une image entière de disque (par exemple avec dd , dcfldd ou bien ddrescue), il est possible de la monter au sein du système, pour qu’elle soit détectée par le noyau, par Gparted, et même transférable (en tant que disque brut) à une machine virtuelle sous VirtualBox.

Dans mon exemple, on a le fichier /home/user/sdi.img, qui est une image complète d’un disque (avec le boot code et la table de partition, dans cet exemple au format MBR).

On vérifie la structure de l’image (qui doit être une copie du disque, donc avec une ou des partitions) : sudo fdisk -l ~/sdi.img. Chez moi, ça donne :

Disk sdi.img: 1,8 TiB, 2000399892480 bytes, 3907031040 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: 0x909b28dc

Device     Boot Start        End    Sectors  Size Id Type
sdi.img1   *     2048 3907031039 3907028992  1,8T  7 HPFS/NTFS/exFAT

J’ai bien la partition sdi.img1, formattée en NTFS.

Montage du disque complet

On utilise pour ça la commande losetup (en root).
Si on l’exécute toute seul, elle nous liste les périphériques actuellement montés. Par défaut, ce devrait être vide.
Si on l’exécute avec le paramètre -f, elle nous donne le premier périphérique disponible pour monter une image. Par défaut, ce devrait être /dev/loop0.

On monte l’image sur le périphérique loop : sudo losetup -r -P /dev/loop0 ~/sdi.img.
Note : l’option -r sert à monter le périphérique en lecture seule, pour éviter les corruptions de données, au cas où.
L’image est bien montée (vérifiable avec losetup sans argument), mais la partition n’est pour l’instant pas prise en compte par le noyau. (EDIT : plus vrai avec l’option -P)

Prise en compte de la table de partition par le noyau

EDIT : l’option losetup -P permet de faire cette étape automatiquement. Ceci dit c’est toujours bien d’avoir un peu les détails des rouages :)

Pour ceci : sudo partprobe /dev/loop0.

Ceci va dire au noyau d’aller réactualiser la table des partitions connues (en l’occurence en n’analysant que le périphérique loop0). Ceci a du créer les périphériques pour chacune des partitions de l’image (pour moi une seule). On vérifie : ls -l /dev/loop0* qui donne chez moi :

 20423171 brw-rw---- 1 root disk   7, 0 avril 27 13:56 /dev/loop0
213017956 brw-rw---- 1 root disk 259, 0 avril 27 13:56 /dev/loop0p1

J’ai bien le périphérique loop0p1 qui représente la première partition de mon image. On peut alors utiliser cette partition comme une partition physique : la monter (sudo mount /dev/loop0p1 /mnt), la fsck (sudo fsck /dev/loop0p1) etc.
On peut également manipuler l’image comme un vrai disque avec Gparted : sudo gparted /dev/loop0. Il faut spécifier manuellement l’emplacement, car Gparted sans argument ne liste que les disques physiques.

À noter, si la partition a été retrécie via GParted, l’image du disque ne le sera pas pour autant (car l’espace non-partitionné existe toujours). Pour ceci, suivant les conseils de ce billet, on peut lancer la commande sudo fdisk -l /home/user/sdi.img pour analyser la table de partition, puis utiliser la commande truncate pour couper l’image dès que la partition se finit. Pour ceci, on multiplie le numéro de secteur final de la dernière partition+1 par la taile des secteurs (logique, je suppose, en cas de différence entre physique et logique. A vérifier).

Par exemple, selon mon exemple en début d’article :

truncate --size=$[(3907031039+1)*512] /home/user/sdi.img

Accès à l’image depuis Virtualbox

VirtualBox permet l’accès depuis le système invité aux disques physiques de la machine hôte. Cela se fait via les disques virtuels VMDK.

Cette partie est grandement recopiée de ce billet.

On commence par s’assurer qu’on fait bien partie du groupe disk : sudo usermod -G disk -a `whoami` (et on pense à log out pour appliquer les modifs). Ceci permet de pouvoir accéder aux disques sans avoir besoin de lancer VB en root.

On crée le fichier vmdk avec la commande suivante : VBoxManage internalcommands createrawvmdk -filename image.vmdk -rawdisk /dev/loop0. Ceci va donner l’accès au disque complet.

Si on souhaite ne donner accès qu’à une partition, on peut utiliser l’option -partitions 2 (pour donner l’accès à la 2ème partition).
A noter que, selon ce Github, cet outil n’est capable de comprendre que les tables MBR. L’outil proposé par le github lui-même semble capable de lire le GPT aussi.

Une fois le fichier créé, il n’y a plus qu’à l’ajouter dans la configuration Stockage de la machine virtuelle.

Démontage

Une fois que l’on a fini, on peut démonter la partition de son point de montage (umount), puis démonter l’image du périphérique loop0 via la commande sudo losetup -d /dev/loop0.

[EDIT : avec l’option -P au montage, losetup supprimera les blocks partitions au démontage, l’étape suivant n’est donc pas nécessaire.]

Ceci ne supprime néanmoins pas le block /dev/loop0p1. Pour ceci : sudo delpart /dev/loop0 1.
C’est l’inverse de partprobe, cette commande dit au noyau d’oublier la partition 1 du périphérique loop0. A faire pour chaque partition.

“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.

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

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 commande xset.

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 -r -1 -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 -r -1 dit à ddrescue d’essyer indéfiniment la lecture sur les secteurs qu’il n’arrive pas à lire, avant de passer au suivant. On peut aussi passer un entier positif en argument, pour un nombre de fois (par exemple -r3).
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

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.

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