GuiGui's show

Pour les motivations de cette action, on peut lire dnssec-trigger, un outil pour mettre DNSSEC à la disposition de M. Toutlemonde sur le blog de Stéphane Bortzmeyer.

Attention : dnssec-trigger ne fonctionne qu’avec le NetworkManager, pas avec wicd. Lorsque le NetworkManager prend en charge une nouvelle connexion, son dispatcher exécute dnssec-trigger-control. dnssec-trigger teste alors les résolveurs DNS passés via DHCP. Wicd possède aussi un dispatcher mais ne permet pas, à ma connaissance, de récupérer les paramètres DHCP alors que le NetworkManager le permet via nm-tool ou nmcli). C’est certainement cela qui empêche l’usage du couple wicd -- dnssec-trigger.

Ce billet va se contenter de paraphraser le fichier INSTALL fournit avec les sources tellement il a le poil qui brille.

1. On installe les dépendances nécessaires.
   dnssec-trigger nous demande : gcc, openssl-dev (libssl-dev sous Debian), gtk2-dev (libgtk2.0-dev sous Debian), glib-dev (libglib2.0-dev sous Debian), unbound, libldns-dev . Ce qui nous donne la commande suivante :

   sudo apt-get install gcc libssl-dev libgtk2.0-dev libglib2.0-dev unbound libldns-dev

2. Le classique

   ./configure

3. Le classique

   make

4. Le classique

   sudo make install

5. sudo dnssec-trigger-control-setup

6. sudo dnssec-trigger-control-setup -i

7. Il faut lancer dnssec-triggerd au boot. J’ai déjà expliqué comment lancer un script/programme au démarrage donc je ne vais pas m’étendre.
   • On créer un fichier /etc/init.d/dnssec-triggerd avec le contenu suivant

     #!/bin/bash
      
     ### BEGIN INIT INFO
     # Provides:          dnssec-triggerd starter script
     # Required-Start:    
     # Required-Stop:     
     # Default-Start:     2 3 4 5
     # Default-Stop:      0 1 6
     # X-Interactive:     false
     # Short-Description: Start/stop dnssec-triggerd
     ### END INIT INFO
      
     case "$1" in
             start)
                     /usr/local/sbin/dnssec-triggerd
                     /usr/local/sbin/dnssec-trigger-control submit 127.0.0.3
             ;;
      
             stop)
                     killall dnssec-triggerd
             ;;
      
             *)
                     echo "dnssec-triggerd start|stop"
             ;;
     esac

     Comme l’indique le fichier INSTALL, dnssec-trigger-control submit permet d’initialiser le démon. Vous pouvez passer une liste vide d’IPs ou une IP qui ne sert pas.

     Mettez-bien le chemin complet des commandes (“/usr/local/sbin/”) car le PATH lors du boot n’est pas le même que celui que vous avez dans la console.

   • On donne les droits d’exécution à ce script :

     sudo chmod +x /etc/init.d/dnssec-triggerd

   • On active l’exécution du script au boot :

     sudo update-rc.d dnssec-triggerd defaults

8. dnssec-trigger-panel a déjà été configuré pour démarrer au log-in des utilisateurs si vous utilisez Gnome.
9. Profit !

J’ai décidé de quitter ma grotte et d’investir dans un écran plat. Oui, j’avais l’air d’un vieux dinosaure avec mes CRT 17″ et 19″. J’ai toujours eu peur de passer au plat à cause des problèmes d’angle de vision présents à leurs débuts. Mais après avoir testé un écran plat de récupération pendant plusieurs mois, j’étais assez convaincu pour franchir le pas. Il faut dire aussi qu’on gagne de la place en profondeur sur un bureau.

Présentation rapide : mon nouvel écran est un Asus ProArt PA246Q. Dalle IPS 24″, plutôt orientée graphisme quand même. Je n’ai rien à reprocher à cet écran, si ce n’est un angle de vision vertical qui est encore trop faible selon moi. La réactivité de l’écran est bonne : je n’ai pas vu de rémanence. Je peux également dire que l’écran claque les yeux et qu’il convient de baisser fortement sa luminosité. Néanmoins, sachez qu’en dehors de l’angle de vision et de la réactivité, je ne suis pas exigeant au niveau écran et que mon avis peut donc être fortement biaisé en fonction de vos attentes.

Passons maintenant à ce qui m’a conduit à la rédaction de ce billet. J’ai voulu tester cet écran sur ma GTX 295 qui est équipée d’une prise HDMI et de deux prises DVI, sans débrancher mon CRT. Je voulais que les deux écrans soient branchés en DVI. Mon nouvel écran n’apparaissait pas dans le panneau de configuration Nvidia. Il apparaissait dans les paramètres d’affichage de Windows mais les modifications que je faisais n’étaient pas prises en compte. Par contre, brancher un écran, tout seul, sur n’importe laquelle des deux prises DVI était une action gagnante.

J’ai téléchargé les derniers pilotes : échec. J’ai cru à une incompatibilité générationnelle entre mon CRT et mon PA246Q : “croire” ne me suffit pas. J’ai cru que ma GTX 295, étant donné qu’il s’agit de deux GT200, avait un fonctionnement différent des cartes qui n’ont qu’un seul processeur graphique : là encore, la croyance ne me suffit pas. J’ai donc creusé plus loin et voici la solution que j’ai trouvée (il ne s’agit pas d’une révolution mais c’est toujours ça ...) :

1. Dans le panneau de configuration Nvidia, dans la rubrique “Paramètres 3D”, dans la sous-rubrique “Définir la configuration PhysX et à plusieurs processeurs graphiques”, cochez la case “Activer tous les écrans” et appliquez les modifications.
2. Si, comme moi, vous recevez un écran bleu nv4_disp.dll en retour, revenez dans le panneau de configuration Nvidia et cochez plutôt la case “Désactiver le mode à plusieurs processeurs graphiques” et choisissez “Processeur” comme “Processeur PhyX”. Rebootez. Retentez l’étape 1. Cela a fonctionné pour moi. Si vous n’avez pas de BSOD (= écran bleu), vous n’avez rien à faire.
3. Rebootez.
4. Votre écran apparaît désormais dans les rubriques “Changer la résolution” et “Configurer plusieurs affichages” et vous pourrez le régler comme d’habitude (clone, bureau étendu, etc.).

P.-S. : Il paraît qu’à l’ouverture de la session Windows, l’icône du panneau de configuration Nvidia présente dans la zone de notification, nous informe, via une infobulle, qu’un écran inactif est présent et qu’il est possible de l’activer en cliquant sur l’infobulle. Je ne sais pas si l’information est vraie mais je peux affirmer que je n’ai pas vu cette infobulle s’afficher.

Quand vous tentez de vous associer à un AP public (j’ai rencontré ce problème sur les réseaux FreeWifi et SFR Wifi Public), il peut arriver qu’aucune adresse ne vous soit attribué par le serveur DHCP. Parfois, et c’est encore plus fort, vous obtenez, sans rien toucher, une IP à peine 5 minutes après l’échec. Toujours plus fort : vous surfez tranquillement, vous êtes brutalement déconnecté et il vous est impossible d’obtenir une IP.

Je parle ici d’une utilisation raisonnable : vous avez toujours utilisé uniquement votre identifiant, vous ne l’avez pas prêté, vous n’avez pas tenté de faire une mauvaise action telle quelle soit, vous faites un fair-use du réseau (en terme de temps d’utilisation et en terme de quantité de données transférée), etc ...

De plus, je pars du principe que la réception du signal radio est bonne car le problème n’est clairement pas lié à une mauvaise réception ou à un système d’exploitation ou bien encore à un chipset wifi.

On peut émettre plusieurs hypothèses plus ou moins réalistes : plage IP totalement distribuée par le serveur DHCP, blacklistage de votre adresse MAC, doublon de MAC, DoS du serveur DHCP, ... Certaines hypothèses n’expliquent cependant pas certains des scénarios énoncés au début de ce billet.

Je connais au moins deux solutions pour avoir une IP quand un serveur DHCP refuse de nous servir :

1. Attribuer manuellement une IP à l’interface réseau. Inconvénients : il faut connaître le plan d’adressage du réseau et trouver une IP non utilisée.
2. Changer son adresse MAC pour une MAC générée au pif. Avantage : rien d’autre à faire.

Intuitivement, j’ai éliminé la première méthode et je ne l’ai jamais essayée car le problème m’a toujours semblé venir des couches inférieures. Je vous conseille donc la deuxième méthode. En effet, en changeant l’adresse MAC de mon interface wifi, j’ai constaté que, à chaque fois, le serveur DHCP du réseau wifi public (uniquement testé sur FreeWifi et SFR Wifi Public, pour rappel) se réveille et m’attribue une IP.

Petit rappel de la commande permettant de changer, jusqu’au prochain reboot, l’adresse MAC d’une interface réseau :

sudo ifconfig <interface> hw ether <nouvelle_MAC>

Un blocage par MAC de la part des opérateurs me semblait improbable : complexe à établir/maintenir, probabilité importante de faux positifs. De plus, l’adresse MAC “d’origine” de mon interface wifi est parfois acceptée, parfois refusée par la même borne dans un intervalle qui se compte parfois en minutes et parfois en jours.

Hé bah pourtant, il semble bien y avoir un filtrage MAC, chez Free en tout cas : il suffit de chercher et on trouve ça, ça et encore bien d’autres ... En revanche, je n’ai rien trouvé concernant SFR ...

Personnellement, vu les circonstances dans lesquelles ce problème apparaît chez moi, je tique encore sur la possibilité d’un filtrage MAC volontaire. Mais comme je ne peux fournir une explication complète et que la réponse des opérateurs (et surtout de Free) se fait visiblement attendre ...

On va résumer vite fait la situation : la facture concernant ma ligne téléphonique fixe étant restée un peu trop longtemps dans le compartiment “à lire”, j’ai payé ma facture France Télécom/Orange avec 3 jours de retard.

Jusque-là, rien d’extraordinaire. Mais, aujourd’hui, je reçois un appel téléphonique aux alentours de 13h15. Un serveur vocal de France Télécom/Orange me rappelle que j’ai un retard de paiement de ma facture et m’invite, si je le désire (oui, je sais : pléonasme dans ma phrase), à la régler dès à présent à l’aide d’une carte bancaire. Vu que j’ai déjà payé et que je suis frileux à l’idée de voir mes numéros de CB circuler sur une ligne téléphonique à la sécurité plus que douteuse, je raccroche (j’ai donc suivi la deuxième option proposée par le serveur vocal).

Je me dis que c’est quand même bizarre ce coup de téléphone, car, à ma connaissance, les relances de paiement des autres entreprises se font par courrier postal : c’est la première fois que je vois une relance de paiement téléphonique. L’horaire d’appel est également suspect : 12h-14h est plus un créneau pour les télémarketeux et arnaqueurs de tous poils que pour des démarches sérieuses ...

Après je pense à l’aspect anti-sécurité de la chose : il suffit de réaliser une pondeuse téléphonique qui imite le serveur vocal de France Télécom/Orange et à nous les pépètes. Oui, il faut tomber sur des clients FT/Orange en retard de paiement + qui ont envie de régler maintenant + qui sont prêts à le faire par téléphone, mais en fonction des sommes dues, la somme récoltée peut quand même être intéressante : c’est le principe même des arnaques téléphoniques. Il serait donc bien étrange que France Télécom/Orange s’engage sur ce créneau.

Je jette un rapide coup d’œil sur orange.fr. On nous parle bien d’un courrier de rappel en cas de retard de paiement. Les articles 9 et 11 des Conditions Générales d’Abonnement au service téléphonique ne sont pas vraiment précis : on apprend juste qu’une majoration sera appliquée dès la première émission d’un courrier de rappel. Mais rien ne précise si France Télécom/Orange procède à un rappel téléphonique automatisé avant l’envoi de ce courrier. En même temps l’article 9 ne dit pas qu’il est possible de payer sa facture grâce au couple CB/téléphone, mais le “notamment” protège FT ... Je Google rapidement sur le sujet, mais je ne trouve rien sur ma situation. Mauvais chercheur ?

Vu que le 1014 est gratuit depuis une ligne France Télécom (c’est-à-dire, à partir du moment où vous payez un abonnement à FT, même en dégroupage partiel donc), je décide de me renseigner sur le sujet. Juste pour le lulz, je vais parler du serveur vocal qui raccroche dès que je fais un choix parmi ceux qu’il me propose et qui sont les plus pertinents ... Tans pis, je me résigne à demander un déménagement de ligne/création d’une nouvelle ligne. Ah, un téléconseiller décroche. Comme d’habitude, ça laisse supposer un centre d’appel délocalisé m’enfin ça, c’est un autre sujet ...

Le téléconseiller m’affirme que FT/Orange procède à une relance téléphonique automatisée via un serveur vocal et que je n’ai donc pas été appelé par un arnaqueur. Comme d’habitude dans ce genre de situation, je reformule ma question au cas où je me suis mal exprimé ou que l’on se soit mal compris. J’obtiens la confirmation. Devant son air étonné, je lui explique la principale raison de mon appel : comment madame Michu va-t-elle différencier un faux appel d’un vrai ? Malgré mon insistance, je n’ai pas eu de réponse sur ce point : le téléconseiller a répondu à côté de la plaque : lui me parlai de la simplicité pour le client que ce système procure alors que moi je ne remettais pas en cause le fait de pouvoir payer sa facture par téléphone et les avantages que cela apporte (c’est un autre sujet et j’ai déjà donné mon avis plus haut), ni le fait que FT/Orange relance ses clients par téléphone (c’est encore un autre sujet), mais le fait que FT/Orange relance ses clients par téléphone ET invite à régler en CB par téléphone. J’ai donc laissé tomber et salué mon correspondant.

Moi, je sens le fail ... Déjà que madame Michu a du mal à éviter le phishing sur le net et les arnaques basiques par téléphone alors si en plus FT/Orange ouvre des vecteurs d’attaque supplémentaires ... Néanmoins, je suis toujours sceptique sur ce fait donc je rappellerai, peut-être, le 1014 dans quelques jours.

À défaut d’être un billet technique, ce billet se propose de regrouper quelques-unes de mes découvertes plus ou moins récentes en informatique.

Table des matières

Différence entre un firewall stateless (pare-feu sans états) et un firewall stateful (pare-feu avec états)

Une bonne définition et une présentation détaillée de l’apport de sécurité amené par le stateful sont exposées ici (même si cette problématique n’est pas le thème majeur du billet) : Palo Alto Networks : Faut-il repenser notre vision du Firewall ? chez Guiguiabloc. Je rajouterai juste que le mode stateful permet une hausse des performances puisque les paquets appartenant à une connexion existante ne sont pas analysés “à fond” contrairement aux premiers paquets de chaque connexion.

Sécuriser un échange chiffré sur le long terme

Pourquoi vouloir sécuriser une connexion déjà sécurisée et temporaire, comme par exemple une session SSL/TLS, sur le long terme ? Imaginons simplement qu’une personne ou une organisation malveillante (pensez plus loin que les soit disant méchants pirates : autorités, prestataire réseau, ...) ait, un jour, l’occasion de faire un man-in-the-middle passif entre vous et un quelconque serveur avec lequel vous effectuez une connexion sécurisée : elle ne verra qu’une connexion chiffrée. Bien. Supposons maintenant qu’elle conserve votre échange avec le serveur et qu’un beau jour, elle soit en mesure de récupérer la clé privée du serveur (mauvais recyclage, saisie du serveur, ...) : elle sera en mesure de déchiffrer l’échange conservé. Afin d’éviter ceci, une méthode existe : le perfect forward secrecy (on peut traduire ça en “confidentialité persistante” ou en “confidentialité de transmission parfaite” mais je pense qu’il vaut mieux garder ça en anglais pour le coup). Cette technique s’applique aux protocoles d’échange de clé qui utilisent la cryptographie asymétrique (= à clé publique) et, de ce fait, aux protocoles utilisant ces derniers : SSL/TLS, SSH, IPSec, ... Notez que l’utilisation du perfect forward secrecy (PFS) est une option en SSL/TLS ou dans IPSec. Par contre, la version 2 de SSH, utilise, par défaut, diffie-hellman pour l’échange des clés et utilise donc le PFS.

Si cette méthode fait parler d’elle ces derniers temps, c’est tout simplement à cause de l’annonce de Google qui nous informe l’avoir mise en place sur ses services qui proposent un accès sécurisé (GMail, Google search, ...).

Je voulais donc profiter de l’occasion pour vous proposer d’en apprendre plus au sujet du PFS via ces deux sites :

• Perfect forward secrecy sur Wikipedia en
• SSL/TLS & Perfect Forward Secrecy chez Vincent Bernat. C’est en anglais mais très accessible (et si vous ne voulez pas faire un effort, une version française est également disponible : SSL/TLS & Perfect Forward Secrecy chez Vincent Bernat (FR)). Via GCU-Squad.

ÉDIT du 23/12/2011 à 17h50 :
J’ai modifié le paragraphe sur le PFS car il contenait un combo de boulettes. D’une part, le blog de Vincent Bernat est aussi accessible en langue française pour les irréductibles et d’autre part, le style d’écriture laissait entendre que le PFS n’était possible qu’avec SSL/TLS alors que je me servais uniquement de l’annonce de Google, qui pour le coup concerne uniquement SSL/TLS, pour évoquer le PFS.
Fin de l’édit

GNOME 3 - gestion de l’énergie et ordinateur portable - ne pas hiberner quand on ferme l’écran

Avec GNOME 2, il suffisait d’aller dans les paramètres systèmes. Plus aujourd’hui ... Qu’à cela ne tienne : utilisons gsettings :

$ gsettings set org.gnome.settings-daemon.plugins.power lid-close-ac-action blank

Dans la même veine, GNOME 3 ne laisse plus le choix de ne rien faire lorsque le niveau de la batterie atteint un niveau critique. Qu’à cela ne tienne (bis) :

$ gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action nothing

Et pour avoir une idée des autres paramètres disponibles pour la gestion de l’énergie, il suffit d’utiliser cette commande :

$ gsettings list-keys org.gnome.settings-daemon.plugins.power

Présentation de Netkit

À tous ceux qui veulent faire des expériences réseaux “sanstoutcasser”, je recommande Netkit. J’avais déjà entendu parler de ce projet dans GNU/Linux Magazine France mais je ne l’avais pas testé. C’est aujourd’hui chose faite et je le recommande. Il ne me reste plus qu’à essayer quelques uns des intéressants labs proposés sur le wiki du projet.

Et pour faire, facilement, une capture réseau sur un lien entre deux machines d’un lab, c’est par ici : New package of uml_dump for netkit 2.7 chez Kartoch’s Blog. Ce patch fonctionne encore tel quel avec la version 2.8 de Netkit.

ÉDIT du 28/02/2012 à 23h45 : Et pour ceux qui se demande quelle est la syntaxe de vdump, voici (copier/coller du Kartoch’s Blog) : vdump <domaine de collision> | wireshark -i - -k . Pour trouver le domaine de collision entre deux machines d’un lab Netkit, il suffit de regarder le lab.conf. Par exemple, quel paramètre dois-je passer à la commande vdump pour écouter le trafic réseau entre pc1 et pc2 en fonction de l’extrait de lab.conf suivant ?

pc1[0]="A"
root[0]="A"
root[1]="B"
bidule[0]="B"
pc2[0]="A"

Réponse : vdump A | wireshark -i - -k
Fin de l’édit

ÉDIT du 23/12/2011 à 17h50 : Et pour ceux qui veulent une configuration plus poussée et/ou mieux comprendre comment ça se passe sous le capot, je vous propose de lire ceci : Labo virtuel avec User Mode Linux chez Vincent Bernat.
Fin de l’édit

Fichier avec des zones vides (sparse file)

À ceux qui se demande comment font les logiciels de virtualisation pour créer des disques dur de taille dynamique (transition depuis Netkit : done), ne vous posez plus la question : il s’agit de sparse files. Je vous dirige vers Wikipedia pour une définition : sparse file sur Wikipédia. Si vous souhaitez obtenir plus de renseignements, c’est par là : Sparse files – what, why, and how chez UNIX Administratosphere. Ce type de fichier est également utilisé par les utilitaires de sauvegarde. Par exemple : Clonezilla sauvegarde l’intégralité de votre disque dur, même les zones vides, sans pour autant créer une image disque de même taille (je ne parle pas d’une quelconque compression).

Pour ma part, j’ai fait le rapprochement entre le nom (sparse file) et les usages en lisant le “Kernel corner” du numéro de novembre 2011 de GNU/Linux Magazine France qui parle de deux nouvelles opérations ajoutées à l’appel système lseek dans la version 3.1 du noyau Linux : SEEK_HOLE et SEEK_DATA qui permettent, respectivement de se placer au début d’une zone vide ou d’une zone de données.

Pointeur de fonction : maFonction(void) != maFonction() ?

N’étant pas un as du développement logiciel (chacun son truc on va dire), je me posais une question toute simple : pourquoi ce code compile-t-il sans erreur ni avertissement ?

void maFonction(void (*f)(double)) { 
     ; 
}
 
void FUSR1() {
     ;
}
 
int main(void) {
     maFonction(FUSR1);
     return 0;
}

Pour ceux que cela intéresse, la réponse se trouve ici : Pointeur de fonction : maFonction(void) != maFonction() ? sur la catégorie “C” du forum du SdZ.

Masque de réseau identique ne signifie pas réseau identique

Récemment, j’ai dépanné une personne se plaignant que deux machines, soit disant sur le même réseau, ne puisse pas se pinger. Le problème venait en fait du fait que cette personne croyait que les deux machines étaient sur le même réseau alors qu’elles ne l’étaient pas. Elle se fiait au masque de réseau, pourtant identique.

Les machines avaient des IPs ressemblant à : 192.168.0.1/30 et 192.168.0.5/30. Un /30 suppose que le dernier octet soit composé de 6 bits pour l’adresse réseau et 2 bits pour l’adresse machine. Cela donne donc un masque égal à 255.255.255.252. Calculons le pas : 256 - 252 = 4. Toutes les 4 adresses, nous changeons donc de sous-réseau :

192.168.0.0/30 est l’adresse du premier réseau
192.168.0.1/30 est la première machine du premier réseau
192.168.0.2/30 est la deuxième machine du premier réseau
192.168.0.3/30 est l’adresse de broadcast du premier réseau

192.168.0.4/30 est l’adresse du deuxième réseau
192.168.0.5/30 est la première adresse du deuxième réseau
192.168.0.6/30 est la deuxième adresse du deuxième réseau
192.168.0.7/30 est l’adresse de broadcast du deuxième réseau

...

On voit clairement que les machines 192.168.0.1/30 et 192.168.0.5/30 ne sont pas sur le même sous-réseau et qu’une passerelle sera donc nécessaire pour les faire communiquer.

Ce qui m’a mis la puce à l’oreille pendant que je faisais les vérifications d’usage (cablage), c’est l’interrogation de la personne : “les masques sont identiques mais les adresses de broadcast sont différentes, je ne comprend pas comment c’est possible. Si elles ont le même masque, les machines sont sur le même réseau et elles devraient donc avoir la même adresse de broadcast”.

Comment indiquer un port supérieur ou égal à 1024 dans iptables ?

Une autre question que l’on m’a posé récemment. Il suffit simplement d’utiliser la syntaxe “1024:”. Exemple :

iptables -t filter -A OUTPUT -o eth0 -s 172.16.0.0/24 -d 192.168.0.5/32 -p tcp -m tcp --sport 1024: --dport 80 -m state --state NEW -j ACCEPT

Pourquoi Windows 7 ne voit pas le disque dur et ses partitions lors d’une réinstallation ?

Encore un dépannage étonnant . L’ordinateur est équipé de Windows 7 Ultimate et d’Ubuntu tous deux installés par le propriétaire de la machine. Celui-ci souhaite réinstaller Windows 7 Ultimate en reformatant. Mais le programme d’installation ne détecte pas le disque dur et ses partitions.

Le mode AHCI est activé dans le BIOS mais cela ne devrait pas avoir d’importance puisque Windows 7 contient les drivers nécessaires. Je pars néanmoins à la recherche des drivers Intel AHCI et les mets sur une clé USB (voir le début de Adding Intel Matrix Drivers to Your XP Image for AHCI SATA Support chez Symantec Connect Community pour extraire les fichiers .inf de l’exécutable fourni par Intel). Windows les détecte bien mais affiche un message d’erreur en tentant de les charger. Encore plus fort : désactiver l’AHCI dans le BIOS ne résoud pas le problème !

Je pense pour un problème de disque dur et je démarre sur un live-cd de Gparted. Le disque dur se compose d’une partition de type inconnu de 200 Mo, de la partition dédiée à Windows, de la partition dédiée à Ubuntu et d’une partition dédiée au stockage des données. Mais à quoi sert donc cette partition de type inconnu ? L’utilisateur n’a pas le souvenir d’avoir créé cette partition ...

Doutant que la suppression de cette partition soit la solution au problème, je tente de cherche d’autres pistes. L’utilisateur m’incite à détruire la partition et je me laisse convaincre. Et le pire, c’est que cela fonctionne ! La suppression de cette partition a permis au programme d’installation de Windows 7 de détecter le disque dur et ses partitions contre toute logique (en même temps avec Windows ... je dis ça, je dis rien ).

Je n’ai par contre aucune piste concernant l’origine de cette partition atypique ...

Et comme mot de la fin : écoutez les personnes que vous dépannez, elles n’ont pas toujours tords .