Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
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)
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
Dernière modification par Dokouest (28-10-2018 21:30:58)
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
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)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Dernière modification par Dokouest (28-10-2018 22:40:08)
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
Dernière modification par empanada (28-10-2018 22:41:34)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
Dernière modification par Dokouest (28-10-2018 23:20:01)
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
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.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
En ligne
C'est pas récupérable comme boulette ?
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
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)
Il vaut mieux montrer que raconter.
Hors ligne
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:
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)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
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.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
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 !
@+
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
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)
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
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.
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
*
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:
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 
.
(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
Salut
Dernière modification par empanada (29-10-2018 16:34:51)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
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 ?
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.
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.
Il vaut mieux montrer que raconter.
Hors ligne
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.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
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 beacoupDokouest 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 avecgrep --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 ...
ἕν οἶδα ὅτι οὐδὲν οἶδα ...
Hors ligne
Pages : 1