Réinstallation de Grub pour booter sur luks

Support Debian
,
Tags: #<Tag:0x00007f63f41cb3f8> #<Tag:0x00007f63f41cbad8>
#1

Bonjour,
J’ai acheté un ssd nvme pour remplacer le vieux hdd de mon laptop, j’ai copié les partitions : /boot en /dev/nvme0n1p1 / (luks) en /dev/nvme0n1p2et windows 7 en /dev/nvme0n1p3 j’ai réussi a démarrer sur linuxmint chiffré dans une partition luks mais pas a démarrer sur windows 7, j’ai donc tenté de réparer grub avec boot-repair et Rescatux mais visiblement le fait de ne plus avoir de disque en sata pose problème, les logiciels de réparation de grub ne veulent que une partition de type /dev/sdX

J’ai effectué plusieurs manipulations sur la partition luks et depuis je n’arrive plus a démarrer sur aucuns de mes OS installés, je n’ai même plus grub qui s’affiche.

Avez vous un tuto ou des piste pour réinstaller grub (ou un autre bootloader) sur un ssd nvme donc /dev/nvme0n1p1 ?

Merci
J’ai bien entendu des backups des partitions :wink:

#2

Si tu peux démarrer sur linuxmint … alors tu doit pouvoir installer grub sur ton nvme.

As-tu un souci pour réinstaller grub ? ou n’y avais-tu pas pensé ?

#3

De quelle façon ?

Pour Windows, cela ne m’étonne pas. Il ne supporte pas bien qu’on change le support de stockage de sa partition système, même en supposant que le pilote NVMe soit installé.

Quelle surprise… (mode persiflage)

Quelles manipulations ? Si tu n’avais vraiment touché que la partition LUKS, cela n’aurait pas dû affecter GRUB qui n’utilise que la partition /boot.

Peux-tu poster le rapport de bootinfoscript, qui devrait être disponible dans certains systèmes de « réparation » ?

#4

Oui j’ai un soucis pour re faire l’installation, les réparateur ne veulent que des partitions en sdX

Bonjour PascalHambourg ravie de voir que tu est encore présent ici :smiley:

j’ai copié avec Clonnezilla
Pour win7 il était déjà sur ssd nvme 120go et je l’ai remplacé par un plus gros

c’est a dire ?

j’ai effectivement modifié ma partitions luks en chroot et je ne me souviens plus trop quoi … :frowning:

Voici le rapport de boot-repair avec les deux disques (l’ancien en sda et le nouveau en nvme)
nvme0n1p4 correspond a une nouvelle installation de ubuntu pour voir si l’installateur détecterai les ancienne distribution, ce ne fut pas le cas, j’ai remarqué qu’il fallait dévérouiller les partitions luks pour qu’elles soient détectés par les réparateurs.

boot-repair-4ppa130                                              [20210802_1819]

============================== Boot Info Summary ===============================

 => Grub2 (v1.99-2.00) is installed in the MBR of /dev/nvme0n1 and looks at 
    sector 1543808 of the same hard drive for core.img, but core.img can not 
    be found at this location.
 => Syslinux MBR (5.00 and higher) is installed in the MBR of /dev/sda.

nvme0n1p1: _____________________________________________________________________

    File system:       ext4
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v2.00) is installed in the boot sector of 
                       nvme0n1p1 and looks at sector 301768 of the same hard 
                       drive for core.img. core.img is at this location and 
                       looks for (,msdos6)/grub. It also embeds following 
                       components:
                       
                       modules
                       -------------------------------------------------------
                       fshelp ext2 part_msdos biosdisk
                       -------------------------------------------------------
    Operating System:  
    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

nvme0n1p2: _____________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

nvme0n1p3: _____________________________________________________________________

    File system:       ntfs
    Boot sector type:  Windows 7/2008: NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  Windows 7
    Boot files:        /Windows/System32/winload.exe

nvme0n1p4: _____________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

sda2: __________________________________________________________________________

    File system:       Extended Partition
    Boot sector type:  -
    Boot sector info: 

sda5: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

sda6: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v2.00) is installed in the boot sector of sda6 
                       and looks at sector 301768 of the same hard drive for 
                       core.img. core.img is at this location and looks for 
                       (,msdos6)/grub. It also embeds following components:
                       
                       modules
                       -------------------------------------------------------
                       fshelp ext2 part_msdos biosdisk
                       -------------------------------------------------------
    Operating System:  
    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

sda7: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 


================================ 1 OS detected =================================

OS#1:   Windows 7 on nvme0n1p3

============================ Architecture/Host Info ============================

CPU architecture: 64-bit
Live-session OS is Ubuntu 64-bit (Ubuntu 20.04 LTS, focal, x86_64)


===================================== UEFI =====================================

This live-session is not in EFI-mode.
EFI in dmesg.
[    0.010131] ACPI: UEFI 0x000000008ABCB750 000042 (v01                 00000000      00000000)
This session has been detected as 'live' because df -Th / contains overlay



============================= Drive/Partition Info =============================

Disks info: ____________________________________________________________________

nvme0n1	: is-GPT,	no-BIOSboot,	has-noESP, 	not-usb,	not-mmc, has-os,	2048 sectors * 512 bytes
sda	: notGPT,	no-BIOSboot,	has-noESP, 	not-usb,	not-mmc, no-os,	2046 sectors * 512 bytes

Partitions info (1/3): _________________________________________________________

nvme0n1p1	: no-os,	32, nopakmgr,	no-docgrub,	nogrub,	nogrubinstall,	grubenv-ng,	noupdategrub,	not-far
nvme0n1p3	: is-os,	32, nopakmgr,	no-docgrub,	nogrub,	nogrubinstall,	no-grubenv,	noupdategrub,	farbios
sda6	: no-os,	32, nopakmgr,	no-docgrub,	nogrub,	nogrubinstall,	grubenv-ng,	noupdategrub,	not-far

Partitions info (2/3): _________________________________________________________

nvme0n1p1	: isnotESP,	part-has-no-fstab,	no-nt,	no-winload,	no-recov-nor-hid,	no-bmgr,	notwinboot
nvme0n1p3	: isnotESP,	part-has-no-fstab,	no-nt,	haswinload,	no-recov-nor-hid,	no-bmgr,	notwinboot
sda6	: isnotESP,	part-has-no-fstab,	no-nt,	no-winload,	no-recov-nor-hid,	no-bmgr,	notwinboot

Partitions info (3/3): _________________________________________________________

nvme0n1p1	: is-sepboot,	no-boot,	part-has-no-fstab,	not-sep-usr,	no---usr,	part-has-no-fstab,	std-grub.d,	nvme0n1
nvme0n1p3	: not-sepboot,	no-boot,	part-has-no-fstab,	not-sep-usr,	no---usr,	part-has-no-fstab,	std-grub.d,	nvme0n1
sda6	: is-sepboot,	no-boot,	part-has-no-fstab,	not-sep-usr,	no---usr,	part-has-no-fstab,	std-grub.d,	sda

fdisk -l (filtered): ___________________________________________________________

Disk nvme0n1: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk identifier: 6ACFCED9-5539-404C-8B1B-273C2E85EDD9
              Start       End   Sectors   Size Type
nvme0n1p1      2048   1953791   1951744   953M EFI System
nvme0n1p2   2050048 793239551 791189504 377.3G Linux filesystem
nvme0n1p3 824492032 976773119 152281088  72.6G Microsoft basic data
nvme0n1p4 793239552 824491505  31251954  14.9G Linux filesystem
Partition table entries are not in disk order.
Disk sda: 698.65 GiB, 750156374016 bytes, 1465149168 sectors
Disk identifier: 0x0009dbd8
      Boot     Start        End    Sectors   Size Id Type
sda2            2046 1465147391 1465145346 698.7G  5 Extended
sda5       880275456 1465147391  584871936 278.9G 83 Linux
sda6  *         2048    1953219    1951172 952.7M 83 Linux
sda7         1955840  830955519  828999680 395.3G 83 Linux
Partition table entries are not in disk order.

parted -lm (filtered): _________________________________________________________

sda:750GB:scsi:512:4096:msdos:ATA WDC WD7500BPKX-2:;
2:1048kB:750GB:750GB:::;
6:1049kB:1000MB:999MB:ext4::boot;
7:1001MB:425GB:424GB:::;
5:451GB:750GB:299GB:::;
nvme0n1:500GB:nvme:512:512:gpt:CT500P1SSD8:;
1:1049kB:1000MB:999MB:ext4::boot, esp;
2:1050MB:406GB:405GB:::;
4:406GB:422GB:16.0GB:::;
3:422GB:500GB:78.0GB:ntfs::msftdata;
sr1:2715MB:unknown:2048:2048:mac:Unknown:;
1:2048B:6143B:4096B::Apple:;
2:2162MB:2166MB:4063kB::EFI:;

blkid (filtered): ______________________________________________________________

NAME        FSTYPE      UUID                                 PARTUUID                             LABEL                  PARTLABEL
sda                                                                                                                      
├─sda2                                                       0009dbd8-02                                                 
├─sda5      crypto_LUKS d98bf4d4-5883-4ec7-8774-f19702b1c010 0009dbd8-05                                                 
├─sda6      ext4        ef6442d5-a90f-4051-98cf-3f45e2179a8c 0009dbd8-06                                                 
└─sda7      crypto_LUKS ebc0f244-93b1-494a-9e09-2b9d41bda92f 0009dbd8-07                                                 
nvme0n1                                                                                                                  
├─nvme0n1p1 ext4        ef6442d5-a90f-4051-98cf-3f45e2179a8c 32f36658-70bc-4fd7-849f-5cbc4688ca58                        
├─nvme0n1p2 crypto_LUKS ebc0f244-93b1-494a-9e09-2b9d41bda92f 09f3f021-13e6-47bf-803f-1ba9f9d0b81e                        
├─nvme0n1p3 ntfs        D08A7E8A8A7E6D3A                     25c9d2aa-245e-422b-be59-de989e8ba558                        
└─nvme0n1p4 crypto_LUKS 198b1d67-62e8-491b-8efd-00ffb107d3f1 db906f82-e170-0a49-a275-afaa9f36b932                        

df (filtered): _________________________________________________________________

           Avail Use% Mounted on
nvme0n1p1 700.7M  17% /mnt/boot-sav/nvme0n1p1
nvme0n1p3   5.3G  93% /mnt/boot-sav/nvme0n1p3
sda6      700.4M  17% /mnt/boot-sav/sda6

Mount options: __________________________________________________________________

nvme0n1p1 rw,relatime
nvme0n1p3 rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096
sda6      rw,relatime

====================== nvme0n1p1/grub/grub.cfg (filtered) ======================

Linux Mint 19.1 Cinnamon   60c34ed0-b3dd-4e04-ae43-dabd969ad930
Linux Mint 19.1 Cinnamon, avec Linux 4.15.0-43-generic   60c34ed0-b3dd-4e04-ae43-dabd969ad930
Linux Mint 19.1 Cinnamon, avec Linux 4.15.0-20-generic   60c34ed0-b3dd-4e04-ae43-dabd969ad930
Windows 7 (sur sda1)   5E9E7AC19E7A916F
### END /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_uefi-firmware ###

================= nvme0n1p1: Location of files loaded by Grub ==================

           GiB - GB             File                                 Fragment(s)
   0,211921692 = 0,227549184    grub/grub.cfg                                  1
   0,143917084 = 0,154529792    grub/i386-pc/core.img                          1
   0,142276764 = 0,152768512    vmlinuz-4.15.0-20-generic                      1
   0,223529816 = 0,240013312    vmlinuz-4.15.0-43-generic                      1
   0,463165283 = 0,497319936    initrd.img-4.15.0-20-generic                   2
   0,513828278 = 0,551718912    initrd.img-4.15.0-43-generic                   2

======================== sda6/grub/grub.cfg (filtered) =========================

Linux Mint 19.1 Cinnamon   60c34ed0-b3dd-4e04-ae43-dabd969ad930
Linux Mint 19.1 Cinnamon, avec Linux 4.15.0-43-generic   60c34ed0-b3dd-4e04-ae43-dabd969ad930
Linux Mint 19.1 Cinnamon, avec Linux 4.15.0-20-generic   60c34ed0-b3dd-4e04-ae43-dabd969ad930
Windows 7 (sur sda1)   5E9E7AC19E7A916F
### END /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_uefi-firmware ###

==================== sda6: Location of files loaded by Grub ====================

           GiB - GB             File                                 Fragment(s)
   0,211921692 = 0,227549184    grub/grub.cfg                                  1
   0,143917084 = 0,154529792    grub/i386-pc/core.img                          1
   0,142276764 = 0,152768512    vmlinuz-4.15.0-20-generic                      1
   0,223529816 = 0,240013312    vmlinuz-4.15.0-43-generic                      1
   0,463165283 = 0,497319936    initrd.img-4.15.0-20-generic                   2
   0,513828278 = 0,551718912    initrd.img-4.15.0-43-generic                   2
#5

Un sacré bazar…

nvme0n1 :

  • table de partition GPT
  • la partition 1 a le type « système EFI », ce qui ne correspond pas à son contenu qui est ext4 (/boot), le type devrait donc être « Linux filesystem ».
  • le MBR contient une amorce de GRUB mais celle-ci pointe vers un secteur qui ne contient pas la suite de GRUB (core image), d’où l’échec du lancement de GRUB
  • le secteur d’amorce de la partition 1 contient une amorce de GRUB qui pointe vers un secteur de la partition contenant la suite de GRUB (correspondant normalement à l’emplacement de/grub/i386-pc/core.img). Mais il n’y a rien pour exécuter ce secteur d’amorce.
  • la partition 3 contient une installation de Windows mais pas le chargeur d’amorçage en mode BIOS (/bootmgr). De toute façon Windows ne peut pas démarrer en mode BIOS depuis un disque au format GPT. Si Windows était installé sur un disque au format GPT, il démarrait en mode UEFI avec une partition système EFI (une vraie) qui est absente sur le nouveau SSD.

Quel était le partitionnement du SSD d’origine de WIndows ?

En très gros, les options disponibles sont :

  • installer un GRUB pour amorçage BIOS qui marche mais aucune chance de démarrer Windows dans cette configuration BIOS+GPT.
  • copier la partition système EFI du SSD de Windows et installer un GRUB pour l’amorçage EFI.

C’est-à-dire que cette déficience renforce mon préjugé contre ces outils de « réparation » qui peuvent faire encore plus de dégâts quand on ne sait pas ce qu’on fait et qui ne sont pas nécessaires quand on.sait ce qu’on fait.

#6

Oui effectivement c’est le bazar :blush:
Ayant des sauvegardes je n’avais pas trop peur de tout casser quitte a tout retransférer de sda a nvme.
Le truc qui me bloque c’est que même en essayant de réinstaller linux mint sur une autre partition l’installateur

ne détecte pas pas la partition luks donc je ne sais pas comment faire et pour windows si je comprend bien il manque une partition vers la quelle grub doit renvoyer ?

Pour que windows boot (sans ufi) sur l’ancienne config c’était bien parceque grub était sur sda ou ça n’a rien a voir ?

De mémoire il y avait 2 partitions 1 système et l’autre démarrage (?)

Oui c’est pas faux, mais je me souviens aussi qu’avec les logiciels il m’étais impossible de valider la ‹ réparation › car il ne ‹ voyait › pas nvme (il ne voulait que sdX pour finaliser)

#7

Qu’entends-tu exactement par « ne détecte pas » et en quoi cela te gêne-t-il pour installer Mint sur une autre partition ? Je ne connais pas l’installateur de Mint, mais celui de Debian ne peut pas ouvrir un volume chiffré existant.

En gros oui.

Ce n’est pas assez précis. Pour vérifier si Windows est installé pour démarrer en mode BIOS ou UEFI il faut savoir si la table de partition est au format DOS/MBR ou GPT, si la partition de démarrage est de type « système EFI » ou NTFS. Tu ne peux pas rebrancher l’ancien SSD pour vérifier ?

A priori la localisation de GRUB n’a rien à voir.
Par contre tu veux dire que Windows pouvait être lancé depuis le menu de GRUB ? Avec l’entrée de menu « Windows 7 (sur sda1) » listée dans le rapport ? Dans ce cas pourrais-tu poster le contenu du fichier /grub/grub.cfg dans la partition de boot du disque dur ? Par contre la mention « sur /dev/sda1 » indique que Windows était installé sur un disque ou SSD SATA, pas NVMe.

#8

De mémoire quand tu fait une nouvelle installation, l’installateur détecte les autres OS et propose de les ajouter a grub pour faire du multiboot.

Si je vais remonter le nvme mais dans les paramètre du bios j’ai bien le boot EFI désactivé.

Dans ce laptop j’ai deux emplacement pour des système de stockage, dans l’ancienne config linux mint + grub était sur un DD et windows sur le nvme de 120Go donc si windows 7 bootait bien sur nvme

#9

La détection d’un OS n’est pas possible s’il est dans un volume chiffré, mais je ne vois toujours pas en quoi cela empêche de faire une autre installation dans d’autres partitions.

Effectivement les indices vont dans le sens d’une installation de Windows pour démarrer en mode BIOS. Dans ce cas, il devait y avoir une partition de boot sur l’ancien SSD et Windows ne pourra pas démarrer depuis un disque au format GPT.

Si tu veux parler d’un emplacement au format M.2 pour le SSD, ce n’est pas synonyme de NVMe. Il y a plusieurs types de SSD au format M.2 : SATA, AHCI (rare) et NVMe.

#10

ça ne m’empèche pas d’installer le nouvel OS mais avec cette technique je pensait que ça pourrait permettre de repartir de zéro concernant grub.

Donc il faut que je change GPT pour autre chose ?

Ah je ne savais pas merci pour l’info tu a probablement raison dans mon cas.

#11

Que veux-tu dire par « repartir de zéro » ?

Si tu veux lancer Windows en mode BIOS depuis ce SSD, il faut que sa table de partition soit au format DOS/MBR.

Il y a une solution intermédiaire qui consiste à créer un MBR « hybride » avec le programme gdisk pour mettre en place une double table de partition GPT (utilisée par Linux) et DOS (utilisée par Windows). Je l’ai déjà fait pour un dual-boot Debian+Windows, ça peut marcher. Mais c’est non standard et fragile, et les outils de partitionnement basés sur libparted (parted, gparted, installateur de Debian et peut-être d’autres distributions) ont tendance à supprimer ce MBR hybride et sa table de partition DOS et ne laisser que la table de partition GPT.

Tu peux vérifier le type du SSD en faisant une recherche avec son modèle. Mais idéalement il faudrait le remettre dans le PC pour voir comment il est reconnu par Linux et surtout vérifier comment il est partitionné pour Windows. S’il est de type SATA, tu risques d’avoir une difficulté supplémentaire liée aux pilotes disque pour démarrer cette installation de Windows depuis un SSD de type NVMe.

#12

Re faire le transvasement du DD vers le nvme avec clonnezila

Oui je crois me souvenir d’avoir vue cette erreur dans Gparted

Je vais le remettre dedans pour voir, mais si c’est trop compliqué je rajoute un disque en sata juste pour /boot

#13

Là, tu m’as perdu. Quel est le rapport entre le transfert du disque dur vers le SSD et l’installation d’un nouvel OS ?

Quelle erreur ? Tu avais déjà fait un MBR hybride ? Je ne suis même pas sûr que Gparted affiche un message, en tout cas parted écrase silencieusement le MBR hybride.

Ça n’a rien à voir avec la localisation de /boot mais de Windows lui-même.

#14

Je vois que je n’ai vraiment pas compris comment fonctionnait le boot sous linux …

Aucuns je me suis aussi perdu :confused: excuse moi pour la maladresse
Comme dit plus haut j’ai fait des modifications un peut hasardeuses (

    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

alors que c’est sensé être du amd64 ) je n’arrive plus a avoir grub donc dans ma logique je copie le DD sur le nvme : les uuid des partitions ne change pas et donc normalement le démarrage sera possible ?

Je ne m’en souviens plus :confused:

La localisation de la partition /boot est bien celle que le bios va amorcer ? Donc pas de GPT ? mais plutôt du MBR ? Y’a t’ils des inconvénients a utiliser MBR pour cette utilisation (partitions luks, ext4, ntfs) ou cela n’a rien avoir avec le type de partitions ?

#15 
============================== Boot Info Summary ===============================

 => Syslinux MBR (5.00 and higher) is installed in the MBR of /dev/sda.
 => Syslinux MBR (5.00 and higher) is installed in the MBR of /dev/sdb.

sda1: __________________________________________________________________________

    File system:       ntfs
    Boot sector type:  Windows 7/2008: NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        /bootmgr /Boot/BCD

sda2: __________________________________________________________________________

    File system:       ntfs
    Boot sector type:  Windows 7/2008: NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  Windows 7
    Boot files:        /Windows/System32/winload.exe

sdb2: __________________________________________________________________________

    File system:       Extended Partition
    Boot sector type:  -
    Boot sector info: 

sdb5: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

sdb6: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v2.00) is installed in the boot sector of sdb6 
                       and looks at sector 301768 of the same hard drive for 
                       core.img. core.img is at this location and looks for 
                       (,msdos6)/grub. It also embeds following components:
                       
                       modules
                       -------------------------------------------------------
                       fshelp ext2 part_msdos biosdisk
                       -------------------------------------------------------
    Operating System:  
    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

sdb7: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 


================================ 3 OS detected =================================

OS#1:   L'OS actuellement utilisé - Linux Mint 19.1 Tessa CurrentSession on mapper/sdb7_crypt
OS#2:   Windows 7 (boot) on sda1
OS#3:   Windows 7 on sda2

sda:120GB:scsi:512:512:msdos:ATA KINGSTON SM2280S:;
1:1049kB:106MB:105MB:ntfs::boot;
2:106MB:73.5GB:73.4GB:ntfs::;

NAME           FSTYPE      UUID                                 PARTUUID                             LABEL              PARTLABEL
sda                                                                                                                     
├─sda1         ntfs        5E9E7AC19E7A916F                     25a93e83-01                          Réservé au système 
└─sda2         ntfs        D08A7E8A8A7E6D3A                     25a93e83-02
#16

Mais non, GRUB BIOS fonctionne en mode réel, c’est toujours i386 même avec l’architecture amd64.
GRUB ne fonctionne plus parce que l’amorce du MBR ne pointe pas au bon endroit. Il suffit de réinstaller une amorce correcte avec grub-install. Mais ça ne fera pas revenir Windows.

Non, le BIOS va amorcer le MBR d’un disque, et le MBR va s’occuper de la suite.

Cela a à voir avec le nombre de partitions. Jusqu’à 4 partitions, on peut créer des partitions primaires. Au-delà, il faut créer une partition étendue et des partitions logiques comme sur le disque dur. C’est une structure fragile et complexe (une liste chaînée de partitions étendues emboîtées) qui complique les modifications.
Mais voilà : Windows exige DOS/MBR pour démarrer en mode BIOS.
Dans ton cas, tu as déjà au minimum besoin de 4 partitions :

  • /boot et LUKS pour Linux
  • boot et système pour Windows

Donc si tu choisis d’utiliser des partitions primaires, tu ne pourras pas créer de partition supplémentaire.

#17

Ok, donc rien ne m’empêche de créer une partition étendu pour y mettre plusieurs partitions dedans, a part le fait de devoir passer de GPT a MBR qui doit probablement nécessiter un formatage ?

c’est l’espace de 1Mo qui m’a été demandé lors d’une tentative de réparation de grub?

#18

Le rapport confirme que

  • l’ancien SSD Kingston est de type (S)ATA et vu comme sda
  • il a une table de partition de type DOS/MBR
  • Windows a une partition de boot sda1 qui contient bien le fichier /bootmgr du chargeur d’amorçage BIOS de Windows, et dont l’UUID correspond à celui figurant dans le fichier grub.cfg. Pour avoir une chance de démarrer Windows sur le nouveau SSD il faut aussi transférer cette partition.

En effet. Néanmoins

  • je ne sais pas comment Windows va réagir si tu le clones dans des partitions logiques alors qu’il a été installé dans des partitions primaires. Même réserve concernant le passage de SATA à NVMe. Il faudra probablement passer l’utilitaire de réparation de démarrage de Windows, et pas sûr que cela suffise.
  • je recommande que la partition /boot de Linux soit une partition primaire pour limiter le risque de renumérotation inhérent aux partitions logiques, ce qui perturberait GRUB.

Pas un reformatage mais un repartitionnement. Il est possible de transformer une table de partition GPT en DOS/MBR en conservant les partitions à certaines conditions. Il faut notamment qu’il y ait au moins deux secteurs libres avant chaque partition logique pour y loger les secteurs de partition étendue (EBR).

Tu fais peut-être référence à la partition de type « BIOS boot » (si table de partition GPT) ou à l’espace non alloué entre le MBR et la première partition (si table de partition DOS) ? Cet emplacement est recommandé voire nécessaire dans certains cas pour l’installation de GRUB dans le MBR ; il sert à contenir la « core image » de GRUB qui est effectivement chargée par la boot image de GRUB qui est dans le MBR. Sa taille n’a pas besoin d’être de 1 Mo, 50 ko suffisent dans la plupart des cas, 100 ko au pire. C’est la taille du fichier (/boot)/grub/i386-pc/core.img.

#19

Bon après quelques jours de vacances :smiley:
J’ai fini par tout recopier et réparer grub avec boot-repair, linux mint boot bien, il ne me reste qu’a réparer le boot de windows 7