cbaud2000

Entorse à mon planning, décalé d'un jour, qui me permet d'apporter un complément d'information, pas très réjouissant : que ce soit à partir d'un DVD ou d'une clé USB, absolument impossible d'installer Windows ! Sur le disque converti en GPT (conversion vérifiée avec GPARTED), j'obtiens une notification me disant en substance que je ne peux pas installer Windows sur ce disque parce qu'il est en GPT ; c'est le comble ! J'ai ensuite essayé sur un autre disque, cette fois en MBR, et là, il m'est de nouveau rappelé qu'il manque un lecteur à mon PC, comme expliqué dans mon précédent post. Revenu à l'emplacement initial, sur le disque reconverti en MBR, et après avoir reconnecté le MAXTOR, l'installation échoue une fois de plus avec cette notification : Nous n'avons pas pu créer de partition, ni localiser une partition déjà existante. Pour plus d'information, voir les fichiers journaux d'installation. En passant, ils sont où ces fichiers journaux ? Bref, j'ai tout essayé, aussi bien en vidant complètement le disque réservé à l'installation de Windows (espace non alloué), qu'en le préparant avec les partitions idoines, rien n'y a fait. Si bien qu'en désespoir de cause, j'ai débranché tous les autres disques, et cette fois, exactement comme pour les mises à niveau précédentes, l'installation a accepté de se faire sans anicroche. Et me voilà revenu à la même configuration qu'auparavant. S'appliquant à la déconnexion du disque MAXTOR, c'était un peu vite dit de ma part ! J'aimerais bien comprendre un jour le pourquoi de cette particularité tout de même un peu gênante. Salutations cordiales

Merci, le PoissonClown. S'agissant de la conversion sans perte, c'est exactement la méthode que j'ai suivie, décrite sur la page même que tu m'indiques. En réalité, je n'avais pas vraiment besoin de préserver les quelques données qui traînaient sur ce disque, sauvegardées de toute manière, mais je voulais tester ce procédé qui n'oblige pas à "cleaner" le disque, comme le fait DISKPART. Et ça marche parfaitement, comme j'ai pu le vérifier avec GPARTED, puis avec l'explorateur de fichiers, qui m'a confirmé que rien n'avait bougé. Quant à NINITE dont j'ignorais absolument l'existence, c'est génial ce truc ! Bien sûr, ça ne réinstalle pas tout, mais ça représente tout de même un sacré gain de temps et d'énergie. Je suis ravi de cette découverte, grâce à toi. Pour les drivers, j'en ai fait une sauvegarde avec DRIVERBACKUP (de Sourceforge), qui promet aussi une réinstallation facile. Cette dernière, pourtant, n'est pas encore commencée, car après avoir passé un disque de MSDOS en GPT (j'en laisse encore un pour faire tourner au moins un OS, en l'occurrence Windows 10) et déconnecté le plus ancien de mes DDs (sur lequel était installé Kubuntu 16.04), et en lançant pour installation un live DVD avec une ISO de Windows 10 1703 (15063.296), je n'obtiens, après quelques minutes, que cette notification sur écran bleu : Recovery There was a problem with a device connected to your PC. An unexpected I/O error occured. Error code : 0xc00000e9 This problem can happen when a removable storage device is removed while it's in use or is failing. Properly connecting any removable storage and restarting your PC may fix this problem. Je n'attache pas grande importance aux codes d'erreur en général, car ils m'ont fait perdre trop de temps en vaines recherches, et j'ai pu constater que le même phénomène répété pouvait générer des codes d'erreur différents. Mais après tout, puisque on a booté sur un support externe (DVD), qu'est-ce que ça peut lui faire qu'il manque un disque ? Naturellement, je sais bien que mon boot est fusillé, mais en l'occurrence, on n'en a pas besoin. Pour accéder au Windows restant, je me sers d'un live CD Linux contenant un programme de boot manuel, qui détecte les systèmes installés, quels qu'ils soient. Inutile de réparer le boot avant d'avoir réinstallé mes deux OS. Dernière question : comment se fait-il que Windows 10 Pro x64, supposé exiger l'UEFI, tourne depuis presque 3 ans (je recevais les builds "insider preview" avant la sortie officielle) sur un disque avec une table MBR, et presque parfaitement si l'on met de côté cette impossibilité de procéder à des mises à niveau ? Je retourne à mes tentatives d'installation, et vous tiendrai au courant, bien qu'avec un délai de 10 à 15 jours, comme expliqué précédemment. Salutations cordiales

Je me lance dans des grandes manœuvres, car la tâche n'est pas aussi aisée qu'attendu : je ne peux pas sauvegarder mon Kubuntu, actuellement sur un disque en MBR, sous la forme d'une image-système, car la restauration en UEFI ne sera pas possible ; le clonage de la partition système serait inopérante pour la même raison. Du reste, je constate sur les forums dédiés à Linux que la restauration d'une image-système n'est pas un procédé très courant. Il lui est souvent préféré une méthode consistant à réinstaller purement et simplement le système, le "Home" ayant été préalablement sauvegardé (le mien est de toute façon sur une partition séparée), de même que la liste des paquets installés (en fait toutes les applications non intégrées dans le système), qu'il est possible, semble-t-il, de réinstaller automatiquement au moyen de cette liste. Même si je devais le faire manuellement, ce serait tout de même beaucoup (vraiment beaucoup) plus rapide que sous Windows. C'est ce que je suis en train de faire. Du coup, il va me falloir aussi déplacer mon OS Windows, et toujours en raison du problème susvisé (passage de MBR en GPT), les images-systèmes de sauvegarde que j'ai ne pourront pas me servir : je peux tout effacer ! Par conséquent, je ne peux pas échapper à une réinstallation complète, qui va me prendre un temps fou. Je vais quand même essayer de faire une sauvegarde des drivers, ce sera toujours ça de gagné. Tout ça pour dire qu'il faudra attendre un peu pour connaître la fin de l'histoire, d'autant plus que je dois m'absenter une quinzaine de jours dès lundi. Cependant, je viendrai ici faire part de mon expérience quand tout sera fini…et peut-être avant, car rien ne dit que je n'aurai pas besoin de vos lumières en cours de route. Merci encore, et salutations cordiales.

Si bien sûr, ça n'est pas bien difficile : je vais faire une sauvegarde de mon système Kubuntu (ce soir seulement, car pour l'instant je travaille sur l'autre OS), que je serai ensuite en mesure de récupérer ailleurs. Ne serait-il pas opportun de profiter de la situation pour passer en GPT le disque, quel qu'il soit, sur lequel je déciderai de le placer ? Un détail de plus : à chaque fois que je me suis servi de l'utilitaire (sous Linux) BootRepair, bien utile pour apporter des modifications au boot, il m'a demandé si ce disque (le vieux MAXTOR) était amovible ou pas, alors que la question ne s'est jamais posée pour les autres. Est-ce en raison de sa taille réduite, ou de sa connexion différente de celles des autres ? Je ne sais pas si c'est significatif.

Merci pour vos réponses, et mille pardons pour mon retard à réagir (une courte absence). Au PoissonClown, je précise que j'ai naturellement essayé d'utiliser l'assistant de Windows (creation-tool, je crois), mais sans plus de succès, bien que je ne me souvienne plus avec quelle notification il m'a signifié l'échec de la manœuvre. En revanche, je me rappelle très bien celle qui a mis fin à l'installation depuis un support externe (clé USB, en l'occurrence, sur laquelle j'avais chargé à l'aide de "WintoFlash" une image ISO dont le hash avait été vérifié) : "The boot selection failed because a required device is inaccessible" Ce qui m'amène à dire à Delta qu'il a probablement pointé quelque chose de sensible. D'abord je réponds à sa question: ma carte-mère st une Gigabyte GA 78LMT-USB3, qui supporte effectivement UEFI et Legacy, et est équipée d'une double connexion ATA (la grosse nappe pour connecter 2 lecteurs de CD/DVD, le plus souvent) et de 6 connections SATA ; socket M2, chipset AMD 780G (révision 00) ; southbridge AMD SB700 ; BIOS FA du 23/04/2013. Nulle part je n'ai trouvé d'indication sur la version de cette CM, du reste Speccy de Piriform ne peut renseigner que x.x. Dans le BIOS, les disques apparaissent correctement, avec une petite bizarrerie tout de même : l'ensemble de ce PC ayant été constitué progressivement (mais la CM, le processeur, la carte graphique et les RAM sont de la même date : 2014) au gré de remplacements d'éléments antérieurs, il se trouve que le disque le plus ancien (un MAXTOR de 80 Gb), qui héberge un OS LINUX (Kubuntu 16.04) peu gourmand en espace se trouve sur la double connexion ATA (cavalier maître-esclave), avec un lecteur de CD/DVD ; or, à des moments où il a fallu toucher au multiboot en raison d'installations, je me suis aperçu qu'au démarrage, ce disque n'était pas présent dans le CMOS (je l'ai constaté parce que l'amorce de GRUB2 était sur ce disque), et qu'il réapparaissait après quelques secondes, le temps d'un redémarrage. J'ai cherché des explications à ce phénomène curieux, et même contraire à ce qu'on pourrait intuitivement attendre, mais je n'en ai pas trouvé sur les forums. Au demeurant, je n'ai pas insisté outre mesure, car il était facile de pallier cette fantaisie en changeant de place l'amorce de Grub2, que j'ai mise sur un disque plus constant. Enfin, à propos d'UEFI, je dois ajouter que trois disques, dont les deux sur lesquels tournent les deux OS, sont en MBR, alors que le quatrième (un TOSHIBA de 3 To, d'où la nécessité de passer en GPT) est en GPT. Je laisse la CM se débrouiller toute seule, en choisissant l'option "automatique" pour le choix entre démarrage EFI ou NON-EFI des lecteurs. Mais il est possible que cet assemblage hétéroclite ait des effets secondaires indésirables (sur un autre forum, quelqu'un m'avait soutenu qu'une telle combinaison n'était pas possible), bien que la machine, dans les intermèdes entre deux mises à niveau, fonctionne parfaitement sous ses deux OS. La seule difficulté que j'ai parfois se rapporte, sous Linux, à la mise en réseau avec d'autres appareils (sous Windows ou MAC, un NAS aussi) : probablement une affaire dépendant de Samba qu'il faudra creuser dans un autre fil. Ses précisions vous aideront-elles à affiner vos diagnostics ? c'est ce que j'espère. Salutations cordiales.

Bonjour, Mon problème est apparu lorsque j'ai été invité (Windows insider) à réaliser la mise à niveau de la version 1607 (14393.1358) vers la version dite "Creator" 1703 : impossible de venir à bout de cette update ! Chaque tentative se soldait par un écran de ce genre. L'OS me signalait bien que le paramétrage de mon compte Windows Insider "requérait mon attention", mais sans précision complémentaire, si bien que je n'ai jamais compris ce qu'il convenait de modifier ; j'ai donc décider de désactiver cette option, de ne plus recevoir les Builds intermédiaires inabouties (depuis l'époque précédant la sortie de W10, ma curiosité s'était émoussée), et de m'en tenir aux versions stables. Cependant, Windows Update ne me laissait pas en paix, et cherchait obstinément (en pratique chaque jour, à l'arrêt du PC) à installer les MàJs disponibles, notamment la KB 4025339, qui ne réussissaient jamais et se terminaient à chaque fois sur cette notification : Laquelle annulation reprenait au prochain démarrage, avec un redémarrage au passage (présence obligatoire, le PC étant en multiboot) : éteindre ou allumer la machine exigeait au total un bon quart d'heure. Pour éviter cela, j'ai apporté des modifications dans l'éditeur de stratégie (gpedit.msc), en arrêtant les MàJs de fonctionnalité et en ne conservant que les notifications des MàJs de qualité et de sécurité, et en choisissant l'option n° 2 : "notifier les téléchargements et les installations automatiques" dans ordinateur > Modèles d'administration > Composants Windows > Windows Update > Configuration du service mises à jour automatiques. Ensuite, en parcourant tout ce que j'ai pu trouver sur ce sujet dans les tutoriels et les forums, j'ai pensé, après avoir essayé sans succès toutes les manières possibles et imaginables de ramener WU à de meilleurs sentiments, qu'il fallait probablement réparer des composants Windows détériorés, d'où le recours à SFC /Scannow et à DISM. Pour ce qui concerne SFC, j'ai obtenu dans le temps (c'est-à-dire au cours du mois écoulé) des résultats différents, le dernier en date ne détectant aucune anomalie, que je trouve donc inutile de fournir ici. Pour DISM, ils disent tous à peu près la même chose (fichiers sources introuvables) : celui du 24/07/2017, puis celui du 25, et enfin celui du 26. Or, je suis absolument formel : l'image ISO de mon Windows 1607, que j'ai montée en : N, est bien à l'emplacement indiqué dans ma commande, et ne contient dans le dossier "sources" qu'un fichier install.wim (et non .esd). Je joins ici le log CBS du 28/07/2017 : CBS_17-07-28.log, et le dernier, du 28 également, de DISM : dism_17-07-28.log. J'oublie de préciser que j'avais bien entendu utilisé l'utilitaire Windows de réparation de WU, dont voici le résultat datant du 28 juin dernier : Windows-Update_log_17-06-28.docx. En lisant l'article cité en référence, il m'avait semblé avoir trouvé la solution idéale...hélas ! Voici ce que me notifie l'installateur en s'interrompant : J'avoue que je commence à me lasser un peu, et que tout secours serait le bienvenu. Mon PC n'a rien de bien particulier, c'est un assemblage personnel pas très ancien, équipé de quatre disques durs. Cependant, j'ai déjà été obligé, pour installer la mise à niveau 1607 qui tourne actuellement, de procéder à une réinstallation complète, ce qui prouve que le problème rencontré maintenant existait probablement à ce moment. Du reste, je n'ai jamais pu procéder à une installation d'un OS Windows quel qu'il soit (depuis le 7 Ultimate qui était le premier sur ce PC) sans être obligé de débrancher manuellement les trois disques durs autres que celui sur lequel je voulais installer l'OS. Cela ne me semble pas tout à fait normal, alors que je ne rencontre aucune de ces difficultés avec les OS Linux installés en multiboot sur la même machine. S'agit-il là de coquetteries qui sont propres à Microsoft ? Salutations cordiales