NTLDR manque sur install Ubuntu

Support Debian
#1

Bonjour à tous !
Je me permets poster dans cette section car ce n’est pas un souci Debian. Ne pas hésiter à le déplacer.
Sur le forum Ubuntu je n’ai pas eu de réponse :

Utilisateur d’Ubuntu MATE 16.04LTS depuis 2 ans, d’un coup, j’me suis dis : installation d’Ubuntu Budgie.
Je télécharge pour une live install (Ubuntie Budgie 18.04LTS), je test… ça me plait et ça à l’air de tourner.
Je lance l’installation.Il voit Ubuntu MATE, il demande où installer, à côté d’Ubuntu ? Non, il y a une partition de 53 Go inutilisée, je le dirige par là.
Et là, j’ai un message :

ERROR!!!
Partition(s) 1,2 on /dev/sda have been written, but we have been unable to inform the kernel on the change, probably because it/they are in use. As a result; the old partition (s) will remain in use. You should reboot now before making futher changes.

Je redémarre… écran noir avec curseur en haut à gauche qui clignote…
Je redémarre avec la clé et je relance une istallation… on voit plus que le disque sans Ubuntu MATE comme à la première tentative.
Dites-moi que c’est rattrapable… please !!
Merci !

Rapport Boot repair :
http://paste.ubuntu.com/p/ZCp7BmkCyt/

Rapport de réparation de démarrage :
http://paste.ubuntu.com/p/R6yrNKpTCc/

Du coup, je redémarre :

NTLDR manque
Entrez Ctrl+Alt+Suppr pour redémarrer

Une solution ?
En ce moment je sauve les meubles : récupération des fichiers sur le volume Sauvegarde.
Là où je suis décontenancé, je ne vois plus la partition Ubuntu 16.04 et j’ai quelques trucs à récupérer dessus.

Merci !

#2

Ben là, tu n’as posté dans aucune section en fait, donc ça c’est pas bon, va falloir qu’un modérateur corrige.

Si tu ne touches à rien, peut être que quelqu’un saura comment réinstaller une version de backup de la table de partition gpt (que je connais mal) ou que tu pourras reconstruire une table de partition si tu as quelques part un extrait détaillé de fdisk ou autre qui t’indiquent les cylindres et la géomètrie qu’avait ton disque avant, mais ça m’étonnerait.
Là de ce que je vois, tu as fait sauter les partitions de ton disque, il ne te reste plus qu’une partition NTFS nommée sauvegarde.
Ca craint pour toi.

#3

De ce que je vois là:
https://wiki.archlinux.org/index.php/GPT_fdisk#Recover_GPT_header
Avec gdisk /dev/sda depuis un livecd, tu peux restaurer une version backup de ton partitionnement gpt en allant dans le mode expert, touche ‘r’ pour rebuild, puis ‘b’ pour reconstruire la table à partir du backup.
Mais attention, ça me semble irréversible comme opération, et si ce n’est pas la bonne chose à faire, ça peut empirer les choses, donc il faudrait confirmation par un “bon en gpt” que c’est la bonne chose à faire.

#4

Salut mattotop !
Cool, je sais qu’ici vous réagissez vite et surtout efficacement.
Oui, je me doute que ça sent pas bon…
Avec l’outil gparted, on voit la partie jaune (ntfs/sauvegardes) et les parties blanches et grises c’est là ou se trouve MATE. C’est quoi les 2 point d’exclamation sur /dev/sda1 ?
J’attends.
En tout cas, merci pour ta réactivité 20191129_133145

#5

Je n’ai vu ce message que dans trois situations :

  1. Le programme de partitionnement utilise le vieil appel système pour demander au noyau de relire toute la table de partition (comme les anciennes versions de fdisk) mais au moins une partition du disque (pas forcément modifiée) est en cours d’utilisation. J’ignore si le programme de partitionnement de l’installateur d’Ubuntu utilise cet appel système.

  2. Au moins une des partitions modifiées est en cours d’utilisation (système de fichiers monté, partition de swap activée…). Cela peut arriver si l’installation est faite depuis un système live, mais pas un installateur dédié (j’ignore si Ubuntu en a encore un).

  3. La modification porte sur une ou plusieurs partitions logiques et au moins une autre partition logique dans la même partition étendue est en cours d’utilisation. Mais cela suppose que la table de partition est au format DOS/MBR, or @mattotop dit qu’elle est au format GPT.

Je ne peux pas voir les rapports de boot repair d’où je suis, ça devra attendre ce soir.

Le message “NTLDR manque” n’est pas pertinent comme titre du sujet. Il indique seulement que la “réparation” de démarrage a remplacé l’amorce de GRUB dans le MBR par un programme d’amorce standard qui a tenté de booter sur la partition NTFS.

Tu n’aurais pas dû laisser boot repair faire une réparation automatique. Tu risques d’avoir aggravé la situation. Même chose en lançant Gparted qui a tendance à “corriger” silencieusement ce qui ne lui plaît pas.

#6

Salut PascalHambourg !

Ah oui, j’avais hésité pour la réparation de boot-repair… trop tard.
J’attends ton retour ce soir, rien est pressé j’ai un portable sous LM de secours.
Pour le titre fais moi une proposition, aucun problème. Concernant gparted, j’ai juste fais un affichage des disques, aucune réparation.
Si rien est récupérable je m’en remettrais. Par principe j’aime bien réparer. Cette semaine je vais acheter un SSD et repartir à plat.
Encore merci pour votre expertise.

#7

Je viens de lire les rapports.

@mattotop, où vois-tu que le disque sda est au format GPT ? Le rapport indique que le format est DOS/MBR (“Disklabel type: dos”). Il ne mentionne aucune trace de format GPT sur le disque sda. Eventuellement à vérifier en forçant la lecture d’une éventuelle table de partition GPT avec fdisk -t gpt -l ou gdisk -l.

Je n’ai pas osé le dire dans mon message précédent avant de vérifier ce point, mais je m’étonnais que le secteur d’amorçage d’une partition de disque au format GPT (celui qui affiche le message “NTLDR manque”) soit exécuté. A ma connaissance, la seule façon de faire ça sans passer par un chargeur d’amorçage comme GRUB est d’installer le secteur d’amorçage GPT fourni avec syslinux (gptmbr.bin) dans le MBR et d’activer l’attribut GPT “legacy boot” de la partition à amorcer.

D’après le rapport de “réparation”, la seule action effectuée a été l’activation de l’indicateur d’amorçage de la partition sda1. Cela n’a donc pas causé de dommages supplémentaires.

Le rapport confirme également que la partition sda1 est plus grande que le système de fichiers NTFS qu’elle contient. Avec un peu de chance, les données des partitions manquantes sont donc toujours présentes et il “suffirait” d’identifier leurs positions. Des outils pour cela sont testdisk et gpart.

#8

Finalement ça parait récupérable. Content de pouvoir bidouiller.
Bon, plus qu’à fouiller dans les commandes testdisk et gpart.

#9

C’est une excellente question.
En te remerciant de l’avoir posé, j’avouerais que je me le demande.

#10

NTLDR est un fichier windows. Donc MBR évidemment erroné.

Ou voir s’il n’y aurait pas exactement la même question dans un forum ubuntu par exemple:
https://forum.ubuntu-fr.org/viewtopic.php?id=2046153

Solution:
=> Installer un bootloader qui réécrira le MBR (les 446 premiers octets de sda)

Passe le message à Gothmog.

#11

Comme je l’ai écrit plus haut, ce message n’est pas affiché par le MBR mais par le secteur de boot de la partition NTFS. Ici le MBR se limite à charger le secteur de boot de la partition active, ce qui n’a rien d’anormal en soi.

Ben voyons. Et il va charger quoi, ton bootloader, sachant que les partitions Linux ont disparu ?

#12

Si tu installes grub2, le bootloader ira automatiquement chercher le fichier core.img installé par grub2.
Le bootloader correspond en fait au fichier boot.img de grub2 (seuls les 446 premiers octets sont écrits dans le MBR).
Il me semble qu’ubuntu utilise aussi grub2 par défaut.
Ces problèmes simples ne devraient avoir aucun secret sur un forum ubutnu.

#13

Je répète ma question : et elle va faire quoi, la core image, sachant que les partitions Linux ont disparu ?
(et je passe sur les erreurs techniques de ton message, ce n’est pas le sujet)

#14

Alors s’il n’y a plus de partitions, ce n’est plus le sujet initial d’un fichier “NTDLR manquant” qui explique extrêmement clairement que le MBR n’a pas été correctement écrit.

Le cas classique est l’inversion sda/sdb où le mbr peut être écrit sur le mauvais disque par défaut.

Si entre temps différents outils de tripatouillages ubuntu ont été utilisés pour détruire les partitions, il faut ouvrir un autre sujet sur un forum Ubuntu.
Soit un outil de récupération de partition (testdisk ou autre) saura les retrouver, ou sinon plutôt tout réinstaller puisqu’il est impossible de suivre chaque tripatouillage d’un forum à l’autre.

#15

Tout cela a déjà été dit. Tu as vraiment lu toute la discussion avant d’intervenir ?

#16

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.

#17

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

#18

@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&section=all&arch=any&keywords=budgie-desktop&searchon=names

D’ailleurs aussi disponible chez Debian…
https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=budgie-desktop

#19

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.

#20

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.