[Résolu] grub rescue :-(

Dokouest · 28-10-2018 21:03:01

Bonsoir,

j'ai grave m...é !
J'ai voulu créer une clé usb bootable avec Stretch pour supprimer le W10 du portable de ma fille.
J'ai (comme un c..) copié deux lignes de commande en su sur mon portable (sous Jessie). J'ai pas tilté qu'il y avait une référence à sdb dans la commande.
Je rallume mon portable et ... grub rescue.

Je suis normalement en dual boot W7(ATA HDD0) et Jessie (ATA HDD2) sur un SSD

Quand je démarre (avec F12) sur le DD W7(ATA HDD0) => j'obtiens

error: no such device: 5ec8e ................

Enterring rescue mode ...

grub rescue>

Et quand je démarre (avec F12) sur le SSD W7(ATA HDD2) => j'obtiens la fenêtre d'installation de Debian (Debian GNU/Linux installer boot menu)

Help !

Dernière modification par Dokouest (01-11-2018 18:56:34)

Dokouest · 28-10-2018 21:19:59

J'ai fait 2 clés USB bootables :
Une avec Super Grub 2 et l(autre avec un image netinstall amd64 de Jessie
Avec les deux, je n'arrive à rien ...

P.S. : j'ai aussi sous la main une sauvegarde faite (il y a quelques temps) avec Back In Time

Dernière modification par Dokouest (28-10-2018 21:30:58)

Dokouest · 28-10-2018 22:16:44

J'ai les mains dans le cambouis : je viens d'utiliser "Boot Repair" => le rapport est à cette adresse https://paste.ubuntu.com/p/TrxZGQ9thZ/
Après, j'ai pas trop envie de lancer la réparation automatique sans rien comprendre à ce que je fait ...

empanada · 28-10-2018 22:25:38

Faites attention. Il me semble que t'as ecrasé la table des partitions de /dev/sdb . Tu peut perdre toutes tes données sur ce disque si tu fais des mauvais pas.

Le grub cherche une partition (5ec8e976-4934-4724-870b-a74adb5266ca) qui n'existe plus

search.fs_uuid 5ec8e976-4934-4724-870b-a74adb5266ca root hd1,msdos1

"blkid" output: ________________________________________________________________

Device UUID TYPE LABEL

/dev/loop0 squashfs
/dev/sda1 F8D4EB17D4EAD742 ntfs Réservé au système
/dev/sda2 5E3AECAB3AEC817F ntfs ULIX220 W7pro
/dev/sdb1 2018-07-14-10-26-37-00 iso9660 Debian 9.5.0 amd64 n
/dev/sdb2 FAF8-C102 vfat
/dev/sdc1 2017-10-29-00-56-18-00 iso9660 Boot-Repair-Disk 64bit
/dev/zram0 f51d80f1-10e8-4cf6-abbc-f490fad2f8e9 swap
/dev/zram1 12624ac1-7dba-4dce-a6ad-34c25d5be676 swap
/dev/zram2 0fdb645e-e22c-4fb2-8853-1184e2f5cce2 swap
/dev/zram3 c68b5eb7-db68-4515-95d6-d6626075f0d5 swap

Et en plus ces deux messages :

Drive: sdb _____________________________________________________________________
Disk /dev/sdb: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sdb1 * 0 595,967 595,968 0 Empty
/dev/sdb2 3,772 4,603 832 ef EFI (FAT-12/16/32)

/dev/sdb1 overlaps with /dev/sdb2

GUID Partition Table detected, but does not seem to be used.

Partition Attrs Start Sector End Sector # of Sectors System
/dev/sdb1 + R 0 595,911 595,912 Data partition (Windows/Linux)
/dev/sdb2 + R 3,772 4,603 832 Data partition (Windows/Linux)

Premier tout faire un clonage de sdb

Dernière modification par empanada (28-10-2018 22:33:56)

Dokouest · 28-10-2018 22:38:06

Yes ! Je vois que tu comprend qqchose au pastbin !
Je me lance et je vais essayer de cloner sdb ... si tu peux me dire comment tu ferai (avec dd, avec gparted ?)

Dernière modification par Dokouest (28-10-2018 22:40:08)

empanada · 28-10-2018 22:39:12

Pour la récupération des données la première règle d'or c'est rien écrire sur le disque original. Donc c'est fortement conseillé de faire une copie sur un autre disque (évidement plus grand que l'original). Dans votre cas, c'est peu probable que le disque original aie des dégâts phisiques, et on pourrait utiliser dd,...mais pas impossible. Mieux utiliser gnuddrescue, qui peut mieux gérer des erreurs de lecture.
Dans l'exemple je suppose que le nouveau disque est déjà monté sur /media/external_disk (changer selon votre cas):

system-rescue-cd doit avoir ddrescue (votre debian est KO).

ddrescue --no-split /dev/sda /media/external_disk/fichier_image.img fichier_log

Et maintenant on peut travailler sur l'image sans rien toucher du disque original:

testdisk /media/external_disk/fichier_image.img

Sur la web de Christophe Grenier tu peut rencontrer des infos détaillées, mais c'est un logiciel assez simple. Il tourne sous la ligne de commande , mais il est interactif et très simple. TestDisk Etape par Etape

Salut

Dernière modification par empanada (28-10-2018 22:41:34)

Dokouest · 28-10-2018 22:42:56

Ok, je me lance et je te tiens au courant.
Merci !

Dokouest · 28-10-2018 22:55:29

<s>Petite question subsidiaire => Je suis en train de faire une partition sur un DD externe pour la sauvegarde du sdb. Quel système de fichier dois-je choisir (ext4 ? NTFS ?)</s> J'ai posté un peu vite

Dernière modification par Dokouest (28-10-2018 23:20:01)

empanada · 28-10-2018 23:19:08

Dokouest a écrit :

Petite question subsidiaire => Je suis en train de faire une partition sur un DD externe pour la sauvegarde du sdb. Quel système de fichier dois-je choisir (ext4 ? NTFS ?)

Ce que tu veux:
- NTFS c'est plus facile pour bouger des données entre différents systèmes d'exploitation
- ext4 mieux support pour récupération des données, etc...
mais...pourquoi partitionner? Si c'est pour ce dépannage, ce n'est pas du tout nécessaire.

Dokouest · 28-10-2018 23:22:31

Oui j'ai posté trop vite. Là je suis en train de faire l'image dans un dossier du DD (encore 45mn)...

Dokouest · 29-10-2018 01:12:52

Bon, là je galère. Je n'arrive pas à faire une clé USB SystemRescueCd...
J'ai donc fait une copie .iso de ma sdb avec le gestionnaire de disque. et je lance partimage pour avoir accès à testdisk.
Nous verrons bien ...

otyugh · 29-10-2018 01:41:45

Si tu as vraiment écrasé le début de ta partition, t'es trèèèès mal mine de rien.

Le mieux que tu puisses faire je pense, c'est récupérer la deuxième partition si tu trouves l'offset d'où elle commence (testdisk peut ptéte aider), et tu pourra la dd-er plus tard. Mais pour la première qui a été en partie effacée, je crois que tu pourra au mieux sauver tes fichiers avec testdisk, au pire avec photoreq (et "pire" est un aphorisme, c'est l'horreur).

J'espère que t'as un backup

Dokouest · 29-10-2018 01:58:17

Voila ce que j'ai (c...n)t tapé dans un debian jessie qui marchait aux petits oignons :

wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso

dd if=debian-9.5.0-amd64-netinst.iso of=/dev/sdb bs=4M && sync

C'est pas récupérable comme boulette ?

raleur · 29-10-2018 10:15:04

Si j'ai bien compris la situation, il y avait :
- un disque dur Hitachi /dev/sda (hd0) avec Windows et l'amorce de GRUB dans le MBR
- un SSD Samsung /dev/sdb (hd1) avec Debian

Personnellement, je n'aurais pas installé GRUB sur le disque de Windows car cela rend les deux disques dépendants l'un de l'autre :
- Debian ne peut pas démarrer sans le disque dur où GRUB est installé
- GRUB ne peut pas démarrer complètement sans le SSD qui contient une partie de ses fichiers
- Windows ne peut pas démarrer sans GRUB qui a remplacé le MBR de Windows, donc sans le SSD.

J'aurait plutôt installé GRUB dans le MBR du SSD /dev/sdb et declare ce dernier comme prioritaire dans l'ordre d'amorçage du BIOS.

Avec la commande dd tu as écrasé le début de sdb à hauteur de la taille de l'image netinst amd64, soit environ 300 Mo. Cela inclut la table de partition et le début de la première partition voire plus la taille de cette partition est inférieure à 300 Mo.

Le fichier de configuration inclus dans la core image de GRUB :

search.fs_uuid 5ec8e976-4934-4724-870b-a74adb5266ca root hd1,msdos1 

set prefix=($root)'/boot/grub'

nous apprend que
- le SSD (hd1) a une table de partition au format DOS/MBR -> pas de copie de secours à la fin du disque comme avec le format GPT
- pas de partition séparée pour /boot
- la partition racine contenant /boot/grub est /dev/sdb1, donc c'est probablement elle dont le début a été écrasé.

Si tu avais créé une partition séparée pour /home, elle est probablement intacte mais sa position est perdue. Sans copie de secours de la table de partition, il faut faire un scan du disque avec testdisk ou gpart pour tenter de retrouver des méta-données caractéristiques du début d'un système de fichiers. Sinon, si tu n'avais créé q'une seule partition pour tout le système, alors il ne reste que les outils forensiques comme photorec (inclus avec testdisk) pour tenter de retrouver des documents mais sans leur nom d'origine. Dans tous les cas, tu devras réinstaller le système ou le restaurer à partir d'une sauvegarde.

Suggestion : mettre la partition de swap au début du disque, ainsi en cas d'écrasement les dégâts sont limités.

Dernière modification par raleur (29-10-2018 10:20:19)

empanada · 29-10-2018 10:35:00

Dokouest a écrit :

Bon, là je galère. Je n'arrive pas à faire une clé USB SystemRescueCd...
J'ai donc fait une copie .iso de ma sdb avec le gestionnaire de disque. et je lance partimage pour avoir accès à testdisk.
Nous verrons bien ...

Un copie *.iso? Dans ce cas. mieux utiliser dd:

dd if=/dev/sda conv=sync,noerror bs=64K /media/external_disk/fichier_image.img

Dokouest a écrit :

Voila ce que j'ai (c...n)t tapé dans un debian jessie qui marchait aux petits oignons :
dd if=debian-9.5.0-amd64-netinst.iso of=/dev/sdb bs=4M && sync

C'est pas récupérable comme boulette ?

Ufff . T'as écrasé tout ce qui était dès le début de sdb jusqu'au la fin de debian-9.5.0-amd64-netinst.iso (environ 300 Mo?). Table des partitions inclus. Si tu n'as pas des sauvegardes de la table de partitions (je ne crois pas), au minimum t'as perdu tout ce qui est dans ces 300 Mo premier du disque. Quand au reste, c'est très probable que tu va perdre beaucoup (voir toutes) des données. Ça dépende. C'est qui est presque sûr c'est que les noms des fichiers sont perdus. Parfois on arrive a récupérer les donnés , mais les noms des fichiers, sont presque toujours perdus. On va voir les options.

Je travaillerais plutôt sur l'image que sur le disque réel. Le disque réel , le mieux c'est,après créer l'image, même le débrancher si possible, pour éviter aucune type d'écriture sur lui.
C'est bon télécharger un ou plusieurs forensics live CD, qui ont tous les outils décrits en bas:
caine c'est bien entretenu (la dernière version c'est octobre 2017)
deft (il y a un live CD (deft zero) seulement pour faire les images, et après on travaille avec une machine virtuelle (deft X)

Le premier c'est essayer de récupérer la table des partitions. Je n'aurais pas trop d'espoir sur ce corvée: t'as écrasé la table des partitions.
J'essayerais testdisk le premier. Après, tu peux essayer
- mmls (dans le paquet sleuthkit)
-testdisk (inclus le file carver photorec)
-gparted
-parted
-rescuept (ext2, FAT, swap, extended partition tables, BSD disklabels y Unixware 7 partitions)
-fixdisk
-findsuper (ext2)
-fixdisktable (ext2, FAT, NTFS, ufs, BSD disklabels)

Si la récupération de la table des partitions c'est un échec , tu doit pencher sur les "file carvers":
J'ai utilisé, parfois avec succès:
photorec (inclus avec testdisk)
foremost
scalpel
magicrescue
recoverjpeg
ntfsundelete
scrounge-ntfs

Je ne suis pas un spécialiste en récupérations des données. Ceux sont des logiciels que j'ai utilisé quelque fois avec de succès divers.

Salut

Dernière modification par empanada (29-10-2018 10:37:20)

empanada · 29-10-2018 10:42:20

raleur a écrit :

si tu n'avais créé q'une seule partition pour tout le système, alors il ne reste que les outils forensiques comme photorec (inclus avec testdisk) pour tenter de retrouver des documents mais sans leur nom d'origine. Dans tous les cas, tu devras réinstaller le système ou le restaurer à partir d'une sauvegarde.

C'est vrai. J'avais oublié de le dire: si t'avais une seule partition, les probabilités d'échec dans la recherche de la table des partitions, c'est presque 100%, et dans ce cas seulement les file carvers peuvent retrouver des fichiers, mais normalement sans le nom original.

Dokouest · 29-10-2018 12:30:51

Pour la récupération des données la première règle d'or c'est rien écrire sur le disque original. Donc c'est fortement conseillé de faire une copie sur un autre disque (évidement plus grand que l'original). Dans votre cas, c'est peu probable que le disque original aie des dégâts phisiques, et on pourrait utiliser dd,...mais pas impossible. Mieux utiliser gnuddrescue, qui peut mieux gérer des erreurs de lecture.
Dans l'exemple je suppose que le nouveau disque est déjà monté sur /media/external_disk (changer selon votre cas):

system-rescue-cd doit avoir ddrescue (votre debian est KO).

ddrescue --no-split /dev/sda /media/external_disk/fichier_image.img fichier_log

Et maintenant on peut travailler sur l'image sans rien toucher du disque original:

testdisk /media/external_disk/fichier_image.img

Sur la web de Christophe Grenier tu peut rencontrer des infos détaillées, mais c'est un logiciel assez simple. Il tourne sous la ligne de commande , mais il est interactif et très simple. TestDisk Etape par Etape

Merci encore pour ton intérêt pour mon petit (même si, sur le moment, j'ai eu l'impression que mon animal de compagnie venais de faire un infarc devant mes yeux ).

Bon j'ai fais une image de la partition abimée (ma Jessie sur sdb). J'ai lancé testdisk et suivi le tuto (peut être pas comme il faut ?). M'enfin, rien de trouver par testdisk. Ni table de partition, ni fichier, etc.

Donc, (je continu à raconter ma vie), je m’apprête à installer une Stretch. J'ai une vieille sauvegarde du home. Nous verrons ...

Si, quelqu'un ici sait fixer le problème autrement. Je suis preneur !
@+

Dokouest · 29-10-2018 13:24:21

raleur a écrit :

Si j'ai bien compris la situation, il y avait :
- un disque dur Hitachi /dev/sda (hd0) avec Windows et l'amorce de GRUB dans le MBR
- un SSD Samsung /dev/sdb (hd1) avec Debian

Personnellement, je n'aurais pas installé GRUB sur le disque de Windows car cela rend les deux disques dépendants l'un de l'autre :
- Debian ne peut pas démarrer sans le disque dur où GRUB est installé
- GRUB ne peut pas démarrer complètement sans le SSD qui contient une partie de ses fichiers
- Windows ne peut pas démarrer sans GRUB qui a remplacé le MBR de Windows, donc sans le SSD.

J'aurait plutôt installé GRUB dans le MBR du SSD /dev/sdb et declare ce dernier comme prioritaire dans l'ordre d'amorçage du BIOS.

Avec la commande dd tu as écrasé le début de sdb à hauteur de la taille de l'image netinst amd64, soit environ 300 Mo. Cela inclut la table de partition et le début de la première partition voire plus la taille de cette partition est inférieure à 300 Mo.

Le fichier de configuration inclus dans la core image de GRUB :
search.fs_uuid 5ec8e976-4934-4724-870b-a74adb5266ca root hd1,msdos1
set prefix=($root)'/boot/grub'

nous apprend que
- le SSD (hd1) a une table de partition au format DOS/MBR -> pas de copie de secours à la fin du disque comme avec le format GPT
- pas de partition séparée pour /boot
- la partition racine contenant /boot/grub est /dev/sdb1, donc c'est probablement elle dont le début a été écrasé.

Si tu avais créé une partition séparée pour /home, elle est probablement intacte mais sa position est perdue. Sans copie de secours de la table de partition, il faut faire un scan du disque avec testdisk ou gpart pour tenter de retrouver des méta-données caractéristiques du début d'un système de fichiers. Sinon, si tu n'avais créé q'une seule partition pour tout le système, alors il ne reste que les outils forensiques comme photorec (inclus avec testdisk) pour tenter de retrouver des documents mais sans leur nom d'origine. Dans tous les cas, tu devras réinstaller le système ou le restaurer à partir d'une sauvegarde.

Suggestion : mettre la partition de swap au début du disque, ainsi en cas d'écrasement les dégâts sont limités.

Bon, j'ai cherché une table de partition avec plusieurs des outils proposés => nada
Je viens donc de découvrir l’intérêt d'un Home séparé et de mettre la swap en début de DD
Merci, encore pour les coups de main. Je continu d'y croire encore un tout petit, petit, petit peu. Et après, haut les coeur, je vais en profiter pour réinstaller (un peu mieux que ma Jessie) une Stretch toute neuve, avec les données que j'avais sauvegardé ... en avril ....
Prochaine étape, trouver le tuto DF pour automatiser mes sauvegardes (et allumer mon cerveau la prochaine fois que je taperai quelquechose en su)

Dokouest · 29-10-2018 14:41:50

Bon, on peut fermé le sujet.
J'ai réinstaller une Stretch sur mon sdb. J'ai partitionné comme conseillé plus haut. J'ai mis le Grub sur sdb. Au démarrage => nada

J'ai relancé sur une clé USB avec Boot Repair. J'ai accepté la réparation automatique (https://paste.ubuntu.com/p/499Pr4YKqj/). Miracle, je peux ouvrir la Stretch toute neuve syr sdb ou mon W7 (j'ai un gestionnaire de carte vitale installé dessus ; un futur projet sera de le réinstaller sous debian ou une virtualisation de W7 ...)
Sankiou pour m'avoir accompagné dans la compréhension que dés fois, quand on allume pas son cerveau, c'est irrattrapable

empanada · 29-10-2018 15:38:53

Dokouest a écrit :

Bon, on peut fermé le sujet.
J'ai réinstaller une Stretch sur mon sdb. J'ai partitionné comme conseillé plus haut. J'ai mis le Grub sur sdb. Au démarrage => nada

Mais il faut aprés, sur la BIOS, indiquer le disque que tu veux comme priorité dans l'amorçage (dans le 95% des BIOS c'est possible...mais pas toujours, surtout dans portables: vérifier)...et avant c'était sda, donc...c'est normal que ton ordinateur ne démarre sur ton nouveau debian.

Dokouest a écrit :

J'ai relancé sur une clé USB avec Boot Repair. J'ai accepté la réparation automatique (https://paste.ubuntu.com/p/499Pr4YKqj/). Miracle, je peux ouvrir la Stretch toute neuve syr sdb ou mon W7

Ce qu'il a fait c'est presque sûr installer GRUB sur sda. Donc t'es comme au début. Le conseil de raleur est très bon, je te conseille de le suivre: chaque disque avec son gestionnaire d'amorçage, si c'est possible, comme dit plus haut.
Après, dans le BIOS, le signaler comme le disque d'amorçage. Chaque disque peut démarrer l'autre, mais c'est bon qu'il peut s'amorcer lui même (imagine que le disque sda tombe en panne (pas difficile: c'est un disque dur, assez "petit", donc je suspect "vieux" (8 ans par exemple?). Tu peux voir l'état actuel est faire des tests avec gsmartcontrol, dès debian).

Pour installer GRUB dans sdb, il suffit démarrer c'est toute neuve debian et
*

grub-install /dev/sdb

Et après rédémarrer , entrer en BIOS et signaler sdb comme disque d'amorçage. Ça y est

*PS: Je ferai avant le grub-install, une installation d'un MBR** qui écrasera le "vieux" GRUB, pour laisser le sda plus "propre", puisqu'il n'a aucun linux:

apt-get update

apt-get install install-mbr

install-mbr /dev/sda

C'est mieux de le faire avant le grub-install, parce que si non le grub-install rencontrera les entrées du GRUB installé sur sda, et les ajoutera sur le GRUB de sdb. Si on fait le install-mbr /dev/sda après le grub-install /dev/sdb, on a dans le GRUB de sdb des entrées qui n'existent plus. La solution peut dans ce cas installer à nouveau grub sur sdb...mais mieux le faire d'une fois, n'est-ce pas?

**MBR (MasterBootRecord) c'est un petit logiciel qui cherche la partition active (partition primaire qui a la marque d'amorçage. Dans ton sda: sda1). C'est la forme première de fonctionnement dans le design primaire de l'amorçage avec les tables de partitions msdos. Les gestionnaires d'amorçage comme grub écrasent le MBR des partitions msdos, et c'est , à mon avis, une procédure un peu tricheuse. Avant grub le gestionnaire d'amorçage plus utilisé sur linux c'était lilo, et même grub on peut l'installer sur le boot-sector de la partition active...mais il n'aime pas beacoup .

Dokouest a écrit :

(j'ai un gestionnaire de carte vitale installé dessus ; un futur projet sera de le réinstaller sous debian ou une virtualisation de W7 ...)

Tu n'as qu'à "virtualiser" ton Windows réel. Un exemple: Running a real Windows install in VirtualBox on Linux
Ce n'est pas difficile, les ressources RAM/processeur utilisés sont les mêmes que si elle est virtuelle, et tu peut avoir un Windows réel et una machine virtuelle tout dans la même installation.
Si t'as suffisante mémoire RAM (je ne ferais avec moins de 4Go) est un processeur assez puissante (mieux avec des options comme PAE/NX et VT-x(Intel) ou AMD-V (AMD)
Vérifier si la CPU est capable avec

grep --color vmx /proc/cpuinfo||grep --color svm /proc/cpuinfo 

Salut

Dernière modification par empanada (29-10-2018 16:34:51)

raleur · 30-10-2018 13:31:28

empanada a écrit :

Les gestionnaires d'amorçage comme grub écrasent le MBR des partitions msdos, et c'est , à mon avis, une procédure un peu tricheuse.

Pourquoi ?

empanada a écrit :

Avant grub le gestionnaire d'amorçage plus utilisé sur linux c'était lilo

Qui peut être installé aussi bien dans le MBR que dans le secteur d'amorce d'une partition.

empanada a écrit :

même grub on peut l'installer sur le boot-sector de la partition active...mais il n'aime pas beacoup

Avec raison, dans certains cas. Dans d'autres cas, GRUB ne le permet carrément pas. Cela dépend du type de contenu de la partition.

empanada · 30-10-2018 18:20:06

raleur a écrit :

empanada a écrit :
Les gestionnaires d'amorçage comme grub écrasent le MBR des partitions msdos, et c'est , à mon avis, une procédure un peu tricheuse.

Pourquoi ?

Ben...c'est une opinion très subjective. Il me semble plus propre que chaque système touche seulement dans ces propres partitions, et pas ailleurs. Pour moi le MBR c'est un espace commun et il me semble plus "propre" que les gestionnaires d'amorçage ne touchent pas MBR si ce n'est pas explicitement fait par l'administrateur. Mais comme dit au début, c'est une vision très subjective.

Salut.

raleur · 30-10-2018 23:26:30

C'est un point de vue qui se défend techniquement. Mais à mon avis il n'est que la conséquence du postulat selon lequel le MBR est unique et ne peut être partagé. Or le MBR n'est pas forcément unique puisqu'il y en a un par disque et il peut y avoir plusieurs disques. D'autre part ce postulat est remis en cause par l'UEFI qui remplace le MBR comme zone d'amorce par une ou plusieurs partition "système EFI" contenant un système de fichiers standard (FAT), et donc la possibilité d'y stocker plusieurs chargeurs ou gestionnaires d'amorçage.

Mais soit, restons dans le cadre de ce postulat. Un seul MBR non partageable. Mais il faut bien y mettre quelque chose, et pouquoi cela devrait-il être forcément le pauvre programme hérité du DOS qui ne sait que chaîner le programme du secteur d'amorce d'une des 4 partitions principales ? De fait, les gestionnaires/chargeurs d'amorçage comme LILO ou GRUB (pour ne parler que de ceux que j'ai utilisés) sont aussi capables de cela et de bien plus encore comme amorcer directement les systèmes Linux présents et même d'autres OS comme.Windows. On pourrait donc très bien décider que ce LILO ou GRUB est commun à tous les systèmes présents.

Le défaut de cette approche est dans l'implémentation concrète : même s'il gère l'amorçage de tous les systèmes présents, LILO ou GRUB "appartient" par défaut au système qui l'a installé, car une partie du chargeur est contenue dans une partition de son "propriétaire". LILO a son fichier /boot/map, GRUB a son répertoire /boot/grub. Pour que le chargeur soit un minimum indépendant, il faut qu'il ait sa propre partition. C'est possible, mais ce n'est pas le cas par défaut.

Dokouest · 01-11-2018 19:05:51

empanada a écrit :

Dokouest a écrit :
Bon, on peut fermé le sujet.
J'ai réinstaller une Stretch sur mon sdb. J'ai partitionné comme conseillé plus haut. J'ai mis le Grub sur sdb. Au démarrage => nada

Mais il faut aprés, sur la BIOS, indiquer le disque que tu veux comme priorité dans l'amorçage (dans le 95% des BIOS c'est possible...mais pas toujours, surtout dans portables: vérifier)...et avant c'était sda, donc...c'est normal que ton ordinateur ne démarre sur ton nouveau debian.

Dokouest a écrit :
J'ai relancé sur une clé USB avec Boot Repair. J'ai accepté la réparation automatique (https://paste.ubuntu.com/p/499Pr4YKqj/). Miracle, je peux ouvrir la Stretch toute neuve syr sdb ou mon W7

Ce qu'il a fait c'est presque sûr installer GRUB sur sda. Donc t'es comme au début. Le conseil de raleur est très bon, je te conseille de le suivre: chaque disque avec son gestionnaire d'amorçage, si c'est possible, comme dit plus haut.
Après, dans le BIOS, le signaler comme le disque d'amorçage. Chaque disque peut démarrer l'autre, mais c'est bon qu'il peut s'amorcer lui même (imagine que le disque sda tombe en panne (pas difficile: c'est un disque dur, assez "petit", donc je suspect "vieux" (8 ans par exemple?). Tu peux voir l'état actuel est faire des tests avec gsmartcontrol, dès debian).

Pour installer GRUB dans sdb, il suffit démarrer c'est toute neuve debian et
*
grub-install /dev/sdb

Et après rédémarrer , entrer en BIOS et signaler sdb comme disque d'amorçage. Ça y est

*PS: Je ferai avant le grub-install, une installation d'un MBR** qui écrasera le "vieux" GRUB, pour laisser le sda plus "propre", puisqu'il n'a aucun linux:
apt-get update
apt-get install install-mbr
install-mbr /dev/sda

C'est mieux de le faire avant le grub-install, parce que si non le grub-install rencontrera les entrées du GRUB installé sur sda, et les ajoutera sur le GRUB de sdb. Si on fait le install-mbr /dev/sda après le grub-install /dev/sdb, on a dans le GRUB de sdb des entrées qui n'existent plus. La solution peut dans ce cas installer à nouveau grub sur sdb...mais mieux le faire d'une fois, n'est-ce pas?

**MBR (MasterBootRecord) c'est un petit logiciel qui cherche la partition active (partition primaire qui a la marque d'amorçage. Dans ton sda: sda1). C'est la forme première de fonctionnement dans le design primaire de l'amorçage avec les tables de partitions msdos. Les gestionnaires d'amorçage comme grub écrasent le MBR des partitions msdos, et c'est , à mon avis, une procédure un peu tricheuse. Avant grub le gestionnaire d'amorçage plus utilisé sur linux c'était lilo, et même grub on peut l'installer sur le boot-sector de la partition active...mais il n'aime pas beacoup .

Dokouest a écrit :
(j'ai un gestionnaire de carte vitale installé dessus ; un futur projet sera de le réinstaller sous debian ou une virtualisation de W7 ...)

Tu n'as qu'à "virtualiser" ton Windows réel. Un exemple: Running a real Windows install in VirtualBox on Linux
Ce n'est pas difficile, les ressources RAM/processeur utilisés sont les mêmes que si elle est virtuelle, et tu peut avoir un Windows réel et una machine virtuelle tout dans la même installation.
Si t'as suffisante mémoire RAM (je ne ferais avec moins de 4Go) est un processeur assez puissante (mieux avec des options comme PAE/NX et VT-x(Intel) ou AMD-V (AMD)
Vérifier si la CPU est capable avec
grep --color vmx /proc/cpuinfo||grep --color svm /proc/cpuinfo

Salut

Après avoir pas mal galérer pour retrouver mes mots de passe, je découvre cette réponse. Virtualiser mon W7 réel, voila qui, j'ose le dire , m'excite. Et si, cerise au kirsch sur le baba au rhum, mon gestionnaire de carte vitale tourne toujours => je décrirai la manip, pour aider d'autre doc à quitter le coté obscur ...

Debian-facile

#1 28-10-2018 21:03:01

[Résolu] grub rescue :-(

#2 28-10-2018 21:19:59

Re : [Résolu] grub rescue :-(

#3 28-10-2018 22:16:44

Re : [Résolu] grub rescue :-(

#4 28-10-2018 22:25:38

Re : [Résolu] grub rescue :-(

#5 28-10-2018 22:38:06

Re : [Résolu] grub rescue :-(

#6 28-10-2018 22:39:12

Re : [Résolu] grub rescue :-(

#7 28-10-2018 22:42:56

Re : [Résolu] grub rescue :-(

#8 28-10-2018 22:55:29

Re : [Résolu] grub rescue :-(

#9 28-10-2018 23:19:08

Re : [Résolu] grub rescue :-(

#10 28-10-2018 23:22:31

Re : [Résolu] grub rescue :-(

#11 29-10-2018 01:12:52

Re : [Résolu] grub rescue :-(

#12 29-10-2018 01:41:45

Re : [Résolu] grub rescue :-(

#13 29-10-2018 01:58:17

Re : [Résolu] grub rescue :-(

#14 29-10-2018 10:15:04

Re : [Résolu] grub rescue :-(

#15 29-10-2018 10:35:00

Re : [Résolu] grub rescue :-(

#16 29-10-2018 10:42:20

Re : [Résolu] grub rescue :-(

#17 29-10-2018 12:30:51

Re : [Résolu] grub rescue :-(

#18 29-10-2018 13:24:21

Re : [Résolu] grub rescue :-(

#19 29-10-2018 14:41:50

Re : [Résolu] grub rescue :-(

#20 29-10-2018 15:38:53

Re : [Résolu] grub rescue :-(

#21 30-10-2018 13:31:28

Re : [Résolu] grub rescue :-(

#22 30-10-2018 18:20:06

Re : [Résolu] grub rescue :-(

#23 30-10-2018 23:26:30

Re : [Résolu] grub rescue :-(

#24 01-11-2018 19:05:51

Re : [Résolu] grub rescue :-(

Pied de page des forums