Tout cela a déjà été dit. Tu as vraiment lu toute la discussion avant d’intervenir ?
Pour recentrer, il faut depuis une distrib live (quelconque) installer si nécessaire ou lancer testdisk et s’inspirer par exemple de ça pour reconstruire la table de partition d’avant:
https://doc.ubuntu-fr.org/testdisk#utilisation_pour_reparation
C’est sans garantie de récupérer quoi que ce soit sur les partitions ainsi reconfigurées, sinon.
@Verner Gothmog, c’est moi bien sur… comme personne ne semblait proposer de solution après plus de 100 vues, je me suis tourné sur le forum Debian que je fréquente déjà. Pour le titre, je savais pas trop. J’ai mis dans le titre le dernier message d’erreur, si vous avez une proposition plus explicite je prends.
@PascalHambourg J’essaie de suivre et ça m’apprend comment fonctionne tout ça. Merci pour la piste à suivre (testdisk/gpart
@mattotop Merci pour la doc, je vois ça demain.
@B1-66ER
Globalement, ton problème n’est pas ou n’est plus un problème de MBR.
Boot-repair n’est même pas un outil ubuntu, mais provient d’un “ppa”.
Ça me parait infiniment trop compliqué et embrouillé pour résoudre des problèmes simples, mais c’est juste un avis.
Ton problème est donc une grosse bourde durant le partionnement de l’installateur “Ubuntie Budgie”, en notant qu’ubuntie n’est pas ubuntu, et qu’à la longue de cloner des clonages, il peut arriver un certain nombre de dégénérescences.
Partition(s) 1,2 on /dev/sda have been written
Testdisk sait très facilement reconstruire une table de partition, à partir du moment où les partitions elles-mêmes n’ont pas été corrompues ou réécrites.
La partition sda1 étant dans un état incompréhensible et incohérent, ça commence très mal, mais qui ne tente rien…
EDIT:
je suppose qu’ubuntie est en fait ubuntu… (même erreur sur autre forum dû au copier/coller…)
Tu n’avais même pas besoin d’installer ubuntu sur une autre partition en plus d’ubuntu Mate, avec tous les dangers que représentent l’installation à partir d’un liveCD, mais simplement de rajouter un bureau Budgie à ton installation Ubuntu mate, et de sélectionner une session Mate ou Budgie lors de ta connexion user.
budgie-desktop
https://packages.ubuntu.com/search?suite=default§ion=all&arch=any&keywords=budgie-desktop&searchon=names
D’ailleurs aussi disponible chez Debian…
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=budgie-desktop
Bon, je tenterai testdisk.
Oui, erreur de frappe ou de copier/coller.
J’ai bien compris la possibilité des doubles bureaux sur une même distribution linux. Mon Ubuntu MATE était 16.04, là on parle d’une installation d’Ubuntu Budgie 18.04.
Oui, je pense passer sous Debian ou LMDE3.
Merci.
A condition que leur type soit identifiable sans ambiguïté grâce à ses méta-données et que testdisk sache l’identifier. Par exemple je doute que testdisk puisse retrouver une partition “BIOS boot” (dédiée à la core image de GRUB) ou une partition chiffrée par dm-crypt sans en-tête LUKS, qui n’ont pas de méta-données. D’autre part je ne sais pas si la liste des formats mentionnés dans sa description et sa page de manuel est exhaustive, mais Btrfs ou F2FS, qui ne sont pas si exotiques, n’y figurent pas. Par ailleurs certains situations sont ambiguës, comme avec les formats imbriqués (système de fichiers dans LVM ou RAID par exemple) ou les fichiers d’images disques qui contiennent des méta-données mais ne sont pas des partitions.
Qu’est-ce qui te fait dire cela ?
D’après la photo d’écran de gparted elle est dans un état suffisamment cohérent pour être montée. Moi je comprends qu’elle n’a pas la bonne taille (trop grande), c’est tout.
sda1 est en fait une partition ntfs qui couvre la totalité de l’espace disque.
Il est impossible d’installer ubuntu dans une partition ntfs.
gparted ne comprend pas non plus la situation.
Ça risque donc d’être compliqué pour testdisk, mais ce n’est que spéculation.
Seul B1-66ER pourra en dire plus.
La photo d’écran montre au contraire que Gparted comprend très bien la situation. Il affiche bien en beige l’espace occupé dans le système de fichiers NTFS, en blanc l’espace libre dans le système de fichiers NTFS et en gris l’espace à la fin de la partition qui n’appartient pas au système de fichiers NTFS parce que la partition est plus grande qu’elle devrait.
sda1 n’est pas ntfs dans sa globalité.
Les parties grise et blanche à droite sont du ext4.
A quoi correspondent les 2 point d’exclamation entre /dev/sda1 et le carré vert sur la photo ?
Ils expliquent que gparted ne comprend pas comment un bloc “supposé” ext4 pourrait se retrouver écrit à l’intérieur d’une partition sda1 ntfs qui occupe la totalité du disque, de taille 465Go.
Si tu avais initialement une partition sda1 windows, sda2 Ubuntu Mate, puis sda3 Ubuntu “Buggie”, si je compte bien, ça devrait faire 3 partitions.
C’est ça que testdisk doit démêler, mais je crains que…
Pure fantaisie. Gparted ne suppose rien du tout et se moque bien de ce qui se trouve à la fin de la partition. Ce n’est pas son problème. Son seul problème éventuellement, c’est que la partition est plus grande que la taille déclarée dans les méta-données NTFS.
A part la contradiction perpétuelle, tu aimes quoi ?
Qui a dit que gparted “suppose” une partition ext 4 ?
Je, tu, ils supposent que lorsqu’on installe ubuntu par défaut, la partition ubuntu sera “supposée” ext4 (bordel quoi…).
Gparted te dit juste qu’il ne comprend pas cette partition unique sda1 sur le disque.
Typiquement encore un sujet qui va devenir un sujet sur un mois de débat stérile.
Et tout ça pour ubuntu “buggie”.
Salut
Ca ressemble fortement à un souci que j’ai déjà eu (justement, suite à une installation d’ubuntu-budgie).
Vérifie l’ordre d’amorçage des disques dans le BIOS: J’irais bien parier que ton installation n’est pas faite sur ce disque ne comprenant qu’une partition NTFS mais sur un second disque et ton BIOS pousse l’amorçage sur ce disque au lieu de celui sur lequel ton système est installé (sans doute vu comme sdb par ton système).
Si ton BIOS voit bien les 2 disques, tu n’auras qu’à modifier la priorité des disques (ta partition NTFS ayant un flag de boot, si elle est en 1er sur la priorité de disques, elle va monopoliser l’amorçage et faire que ça coince).
Sinon, il suffit de débrancher puis rebrancher le cable SATA de ton disque système (EDIT: machine éteinte, évidemment … ) pour qu’il soit vu de nouveau par ton BIOS et ça repart.
Salut choops,
Bienvenue dans la discussion.
Bon, j’ai fais une analyse du disque avec testdisk, un rapport s’était enregistré dans les documents mais en voulant le poster sur le forum, la session live a planté… chuis bon pour remettre ça demain soir…
Grosso modo il avait trouvé des trucs (Linux/swap) mais il disait qu’il ne pouvait rien faire je crois.
Je poste le rapport demain.
@choops Si rien n’y fait, je regarderais cette piste du BIOS.
Merci !
Comme je maîtrise pas grand chose et encore moins les paramètres du BIOS :
Ton BIOS ne voit qu’un disque dur qui est connecté au port SATA1.
A son petit nom, je dirais que c’est un disque à plateaux SEAGATE de 500G correspondant à ce qui était vu par gparted.
Si tu as un autre disque dur où était installé ton ubuntu-mate et où est maintenant installé ton ubuntu-budgie (ce qui est vachement vraisemblable à l’historique de ce fil), il te suffit d’éteindre ta machine, de l’ouvrir et de débrancher puis rebrancher le cable SATA de ce disque avant de redémarrer.
(Comme je le disais, ça ressemble très fortement à ce que j’avais vécu avec ubuntu-budgie)
@choops Non, c’est un même et seul disque. MATE était installé sur la partie blanche et j’ai voulu installer Budgie sur la partie grise. Avec le temps je pense que cette partition n’était pas “prête” pour une install (formatage en EXT).