Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
attends les refresh du bureau gnome .
je sais , c'est chiant , mais tu n'as pas d'autre solution .
Je ne pense pas qu'attendre règle le problème. C'est ce que j'ai fait en me disant que les extensions seraient mises à jour : pas d'évolution depuis environ un an.
Ajustements/Extensions est ko : je retrouve les extensions listées dans l'add-on Firefox, mais elles sont toutes off et grisées, impossible d'agir dessus.
Sur un autre PC en debian buster, aucun problème, des mises à jour ont eu lieu, les extensions fonctionnent. Le problème est sans doute ailleurs, mais je ne vois pas d'où ça peut venir.
Extension Manager : je ne suis pas très chaud, ça va ajouter une couche de logiciel.
Je vais explorer la piste de Lancelin, voir ce que j'ai installé et qui aurait pu interférer avec Gnome. Désinstaller pas à pas et retester. Je reste quand même dubitatif, je n'ai pas installé des tonnes de trucs, et à part Teams, tout vient des dépôts debian.
ou modifier ses extensions sur le site de gnome.org (je crois) https://extensions.gnome.org/
C'est justement ce que j'essaie de faire via l'add-on Firefox, et leur activation ne fonctionne pas. Elles sont toutes désactivées, et il m'est impossible de les activer (je peux passer le curseur à On, mais ce n'est pas pris en compte).
Le connecteur de l’hôte natif ne prend pas en charge les API suivantes : v6. Vous devriez mettre à niveau le connecteur de l’hôte natif ou installer des greffons pour les API manquantes. Veuillez consulter la documentation pour les instructions.
C'est quoi, ce connecteur natif et cette API v6 non pris en charge ? Je n'ai rien trouvé d'utilisable sur la page de documentation : https://wiki.gnome.org/Projects/GnomeSh … stallation.
Quelqu'un a rencontré le même problème ?
Une solution de contournement ?
Merci de votre aide
et
sans succès.
J'ai enfin réussi à booter sur grub après avoir modifié le Bios et désactivé le Secure Boot.
Si je veux pouvoir remettre en place le Secure Boot (qui fonctionnait correctement jusqu'à la dernière mise à jour de cette #@! de W10), quelle manip. préconisez-vous ?
(la récup avec gdisk m'a bluffé).
Moi aussi. Tout le début du disque était écrasé à coup de zéros, et si j'avais démarré par gdisk, je récupérais tout en deux minutes chrono.
En plus, gdisk permet de faire une sauvegarde de la table en plus du backup. Ce que je viens de faire pour mes deux disques qui par chance sont tous deux en GPT.
Seul bémol, les disques boot pour lesquels il semble y avoir des problèmes (mais rien de tel pour mon ssd en mode uefi).
Et on s'est fait suer pour rien. J'avais pourtant écrit dans mon premier message :
Oui raleur, j'en suis bien conscient. Faute de savoir ce que faisait gdisk, et en particulier qu'il me permettait de savoir si la partition était en gpt, j'ai commencé avec le premier indiqué. Comment perdre des heures quand la solution est là, sous mon nez !
Mais tu m'a appris plein de trucs (les outils disque gpart, losetup, tune2fs, les paramètres de dd que je ne connaissais pas), et surtout, ce que je pressentais sans avoir eu vraiment la preuve, qu'un système ouvert et l'entraide sont les outils les plus puissants qui existent. Alors désolé de t'avoir fait perdre ton temps, désolé pour mes questions à la noix sur détail de la vis de 6, et encore un immense merci pour ta patience et ton aide.
A ce sujet, j'aimerais bien savoir comment tu as acquis une telle expertise sur les systèmes de fichiers, le matériel, et les outils linux. Ca fait un bout de temps que je tripote linux, mais à part une utilisation basique de dd, je n'avais jamais entendu parler de toutes ces commandes.
Vérifie quand même que le MBR est bien de type MBR protecteur. Sinon il faudra passer par les fonctions expert avec "x" pour le reconstruire avec "n".
Euh, comment je vérifie ça ? Voici ce que donne 'print protective MBR data' en mode expert :
Apparemment, le disque était bien partitionné en GPT. Je comprends qu'il charge la table backup, mais que les CRC ne sont pas bons, et qu'il faut que je répare le disque. Avant d'écrire sur le disque, peux-tu me confirmer que c'est bien la séquence r (restore) c (load backup partition table) ?
La taille de ma première partition ext4 est de 204800000 secteurs (25600000*4096/512). Je retrouve bien les 100 Go de mon partitionnement initial.
Si je fais la même chose pour la troisième partition (seconde partition ext4) :
Seconde partition ext4 : 1 728 241 664 secteurs ou 843868 Mio.
Je viens de reprendre la première méthode avec dd et count=64, voici le résultat :
Le block count est cohérent avec les deux autres méthodes.
Et maintenant ?
Apparemment, je ne trouve pas le début de la partition. 
avec 100000=110001-10001.
Je pose la question qui parait triviale, mais je m'y perds entre décomptes en GiO et GO. Je comprends que dd compte en mebi-octets (1024x1024 octets) et gibi-octets (1024x1024x1024), mais que le disque a été partitionné en giga-octets (1000x1000x1000). J'ai bon ?
Pour la partition 3, voici ce que renvoie hdparm :
Entre CBS / LBA et LBA48 addressable sectors, quel est la bonne valeur ? Et de quelle taille de secteur parle-ton ? logique ou physique ?
Le LBA adressable sectors et des secteurs de 4096 octets me donne la valeur la plus proche, mais je ne tombe pas pile sur la taille du disque renvoyée par hdparm :
268 435 455 * 512 / 1024 / 1024 = 1 048 575,99 MiO
. Mais ça ne fonctionne pas. 
et ô miracle :
Idem pour la partition suivante :
Pour ma formation, je ne comprends pas la fin de la ligne de commande "file -". Que fait le - ? Et pourquoi la commande renvoie "4+0 enregistrements écrits", alors que je ne lui ai pas indiqué de fichier cible ?
Bien, maintenant que j'ai confirmation que les deux partitions sont intactes et que j'ai isolé leur emplacement, comment est-ce que je localise au secteur près ?
Je sais que la partition 2 démarre quelque part après le bloc 10001*2048. En tatonnant avec les paramètres, j'ai trouvé
alors que count=1 et count=2 renvoient "data". Et je ne connais pas la taille d'un bloc, fdisk -l ne me renseigne que sur le disque SSD en sda.
Cette fois-ci, j'ai bien repéré la partition de 100 Go, puis celle de 843 Go. Je laisse le scan se terminer pour avoir toutes les infos de gpart. Quelle est l'étape suivante ?
Je tente un gpart -f simple cette nuit.
Et qu'aurait-il donc fallu faire ?
Je pensais n'avoir perdu que la première partition puisque j'accédais aux deux suivantes et que les fichiers paraissaient ok. L'erreur a été d'arrêter le système sans réaliser que la table de partitionnement du disque avait été touchée. J'aurais dû transférer immédiatement tous les fichiers sur un disque de sauvegarde alors qu'ils étaient encore accessibles.
Comme tu l'avais prédit, gpart a "sauté" la fin de la partition ntfs, et semble avoir trouvé la troisième partition.
J'avais partitionné comme suit :
ntfs = 10 Go -> la première partition, bousillée par ma bévue (size 0, offset 3347)
ext4 = 100 Go -> ce doit être la partition détectée à l'offset 10001, et cataloguée en ntfs. Soit gpart a sauté des secteurs, soit l'écriture a aussi bousillé le début de cette partition.
ext4 = le solde de l'espace disque -> je la retrouve à l'offset 110001 Mo.
Et comme par défaut gpart saute les secteurs de la supposée partition, il ne trouvera pas la partition ext4 suivante. Pour éviter cela il faudrait spécifier "-f". D'autre part d'après la page de manuel par défaut gpart scanne tête par tête (-n h), ce qui n'est pas adapté au partitionnement actuel basé sur des blocs de 2048 secteurs. Donc spécifier soit "-n s" pour scanner tous les secteurs (long), soit "-n 2048" pour scanner par bloc.
Pourquoi -n 2048 ? parted indique :
D'où vient cette valeur de 2048 secteurs / bloc ?
Allez hop, c'est reparti pour un scan ... 
Gpart is a tool which tries to guess the primary partition table of a PC-type hard disk in case the primary partition table in sector 0 is damaged, incorrect or deleted. The guessed table can be written to a file or device. Supported (guessable) filesystem or partition types:
DOS/Windows FAT (FAT 12/16/32)
Linux ext2
Linux swap partitions versions 0 and 1 (Linux >= v2.2.X)
OS/2 HPFS
Windows NTFS
*BSD disklabels
Solaris/x86 disklabels
Minix FS
Reiser FS
Linux LVM physical volume module (LVM by Heinz Mauelshagen)
Si ça m'arrivait, je considèrerait que "c'est mort", et que photoreq ne permettera que de récuperer quelques fichiers dans une bouillie apocalyptique de fichier système.
Ben non, j'ai la foi, parce que c'est linux, que des générations entières de bidouilleurs ont fait la même c...nnerie avant moi, et que certains ont trouvé des solutions et développé les outils qui vont bien. 
Sinon autant rester sous Windows, et réinstaller son système à chaque fois que ça plante.
Un autre programme qui sert aussi à retrouver les partitions perdues est gpart (à ne pas confondre avec gdisk ou gparted), mais je ne l'ai jamais utilisé.
Note : si la table de partition est au format GPT, il y a une table de secours à la fin du disque, que des outils comme gdisk peuvent utiliser pour restaurer la table principale.
J'ai lancé gpart.... Ça mouline sec, mais avec un téra, va falloir être patient. Voici ce que ça donne pour l'intant :
J'ai aussi passé parted pour voir si mon second disque est en GPT, mais pas de résultat sur sdb :
Je vais tenter gdisk dès que gpart aura terminé.