Ajout d'un second disque dur

J’ai eu des problèmes avec le partitionnement que je ne maîtrise absolument pas.

Il suffit de faire 3 partitions :

• une swap de 4Go en swap (ou le double de la RAM si tu as moins de 2Go de RAM) - éventuellement commune à un autre système Linux
• une partition

  /

  de 25Go en ext4 (5Go pour un système léger)
• une partition

  /home

  de taille arbitraire pour tes documents / profils utilisateur (généralement le reste du disque).

(peu importe le disque, le type de partition, elles n'ont même pas besoin d'être sur le même disque même si c'est plus naturel).

Le programme d’installation demande Device for boot-loader installation.
Q-1 Quel disque choisir? Le vieux ou le neuf?

Celui sur lequel le BIOS amorce (et donc que tu peux choisir). Généralement si on a deux disques (genre un pour le système et l'autre pour la donnée), on le met sur le disque avec le système. Dans ton cas si tu as des systèmes sur les deux (windows sur l'un, linux sur l'autre), il serait plus logique de le mettre sur le disque linux et d'amorcer dans le BIOS sur le disque linux.

Q-2 S'il y a trois systèmes d’exploitation sur deux disques, est-ce qu’il y a trois boot loader ou un seul ?

Un seul, qui te donne le choix entre les 3 OS.

Q-3 Dans le cas où il y trois boot loader est-ce qu'ils doivent être sur le même disque?

Cf Q2 : un boot loader correspond simplement au menu qui permet de choisir sur quel système démarrer.

Bonne chance

J'ai finalement réussi à installer Mint Ulyssa (Mate).

Bravo

Cependant, dans le menu Grub, je ne vois pas Win 7 et Debian Wheezy qui sont sur le vieux disque dur. Lundi, je vais changer l'ordre de priorité des disques et je vais voir ce que va m'offrir Grub.

Les dernières versions de grub ne scannent pas les partitions windows. Il faut corriger la configuration de grub comme expliqué ici. Personnellement je mets la directive magique dans le fichier

/etc/default/grub.d/multiboot.cfg

, créé pour l'occassion :

sudo echo "GRUB_DISABLE_OS_PROBER=false" > /etc/default/grub.d/multiboot.cfg
sudo update-grub

Lorsque j'ai créé les partitions avec Mint Live et que j'ai voulu installer Ulyssa, le programme d'installation m'a signalé qu'il manquait la partition Efi. Il me semble que l'on ne m'a pas donné le choix entre le type de partition (MBR, GPT) que je voulais.

Que donne

sudo parted -l

? Ensuite c'est normal qu'on ne t'ait pas donné le choix entre MBR et GPT puisque tu avais déjà une table des partitions. Mais en cas de besoin, tu peux passer de MBR à GPT avec

gdisk

(voir ce lien).

Q1 : oui (par contre plus efficace n'est pas le bon adjectif, c'est plutôt qu'il permet plus de choses), mais il vaut mieux privilégier GPT.

Q2 : non c'est spécifique MBR (voir ce lien

Bonne chance

Bonjour,

Par rapport à ton message en rouge, voir ce lien. En gros ce n'est pas très grave, mais si tu as l'opportunité de déplacer la partition avec

gparted

c'est mieux (après avoir sauvé tes données).

Le partitionnement est correct mais il est un peu surprenant que la partition ESP ne soit pas sur

/dev/sda

mais vu que tu bootes sur

/dev/sdb

pourquoi pas. De manière générale la partition ESP n'est utile que si tu utilises le secure boot.

Au niveau du partitionnement, tu dis avoir mutualisé la swap. Très bien ça semble être le cas. Par contre si tu as mutualisé

/home

et

/

sous Mint, j'ai un peu de mal à voir pourquoi tu as autant de partitions ext4.

Au niveau de grub, oui, le même disque. En vrai il suffit d'installer grub avec juste l'une des deux distributions, mais si les deux installent grub, c'est simplement la dernière à mettre à jour grub qui installera le sien dans l'en-tête de

/dev/sdb

.

Quelque soit la distribution qui installe grub, sous réserve que l'option

GRUB_DISABLE_OS_PROBER=false

soit précisée, celui-ci scannera l'ensemble des partitions et détectera donc l'ensemble des systèmes installés (indépendamment de la distribution qui est en train d'installer grub).

Habituellement, les distributions Linux n’écrasent pas les autres contrairement à Windows

Si tu redéployes grub sur le même disque ça écrasera l'ancien grub. Si tu installes Linux sur des partitions existantes, ça les écrasera. Il n'y a donc pas de règle, il faut juste être vigilant à ce qu'on fait.

J'ai fait la commande (sous Mint) nano -v /etc/default/grub.d/multiboot.cfg
mais nano ouvre un fichier vide (New file).

Oui il faut le créer. Les fichiers

/etc/default/grub.d/*.cfg

sont lus au moment de régénérer grub. Après, ça n'a rien d'obligatoire et ol serait aussi possible de directement charcuter

/etc/default/grub

. Le résultat serait le même mais la configuration un peu moins propre.

En effet, quand on ajoute des bouts de configuration, on essaye de ne pas toucher au fichier de configuration par défaut et on les met à part (quand c'est prévu pour, comme ici). Cela présente deux avantages :

• La configuration personnalisée est mise en évidence dans des fichiers dédiés : c'est plus lisible et mieux rangé.
• Si

  apt

  a besoin de mettre à jour le fichier de configuration principal alors comme le fichier est toujours sous sa forme standard, il met la nouvelle sans te demander ton avis ; si tu l'as bidouillé,

  apt

  ne saura pas quoi faire et te demandera de prendre une décision (interrompant toute la suite de la mise à jour jusqu'à ce que tu lui répondes).
• On retrouve ce système à d'autres endroits (par exemple voir

  /etc/apt/sources.list.d

  )

Bonne chance

Bonjour

Je reprends ci-dessous tes questions du message #24.

1) Par rapport au partitionnement

Je n'ai pas trop compris comment on était passé de deux disques avec 8 partitions et un autre avec 4 partitions à un disque avec 6 partitions. Mais peu importe. J'ai compris que dans ce nouveau partitionnement tu avais Mint et Debian sur un même disque. En admettant que

DONNEES_DEB

et

DONNEES_MINT

correspondent aux partitions

/home

de Debian et Mint, alors tu aurais pu les mutualiser.

2) /etc/default/grub.d/multiboot.cfg doit être créé manuellement

Tout à fait, et plus généralement les fichiers suivant le motif

/etc/*.d/*

sont des fichiers de configuration injectés par l'utilisateur ou une application, mais pas par le système lui-même. Note que le nom de ce fichier est complètement arbitraire, tu pourrais l'appeler

/etc/default/grub.d/toto.cfg

et ça continuerait de marcher.

3) Comment marche grub2

C'est une bonne question, on a l'impression qu'il y a un maillon manquant entre ce qu'on configure dans /etc/default/grub et ce qui est déployé dans l'en-tête du disque dur. Et en fait, ce maillon existe, c'est le fichier

/boot/grub/grub.cfg

.

Si tu prends le temps de l'ouvrir, tu retrouveras certaines informations que tu as renseignées dans

/etc/default/grub

mais également tous les aspects manquants que tu as évoqués (notamment sur quelles partitions se trouvent chaque système). Et c'est également là qu'on se dit heureusement qu'on a juste à bidouiller

/etc/default/grub

, car le fichier est bien plus simple à appréhender et bien plus court.

Alors dans l'absolu, rien ne t'empêcherait d'aller directement bidouiller

/boot/grub/grub.cfg

, ça ferait le job. Et d'ailleurs grub1 fonctionnait comme ça. Aujourd'hui, à cause de cette distinction claire entre ce que l'utilisateur peut avoir envie de configurer et ce qu'il faut effectivement configurer, le fonctionnement de grub2 est sensiblement différent.

En tant qu'utilisateur tu utilises essentiellement

update-grub

qui fait tout ce qui doit être fait conformément aux options que tu as renseignées dans

/etc/default/grub

. En réalité,

update-grub

fait plein de choses pour toi en arrière boutique :

• il appelle

  os-prober

  qui, comme son nom le suggère, cherche les systèmes d'exploitations installés sur tes partitions de disque dur ;
• il exploite ces résultats (ainsi que le contenu de

  /etc/default/grub

  et des fichiers dans

  /etc/default/grub.d/*

  ) ;
• à partir de ces informations, il appelle

  grub-mkconfig

  pour recréer

  /boot/grub/grub.cfg

  ;
• enfin, il appelle

  grub-install

  pour installer grub dans l'en-tête du bon disque en s'appuyant sur

  /boot/grub/grub.cfg

  .

Si tu veux encore plus de détails, tu peux regarder les pages de man de chaque commande

grub-*

(e.g.,

man grub-mkconfig

).

Bonne chance

1)

Oui, tu as raison ça manque de rigueur et j'ai eu le même ressenti quand j'ai moi-même découvert ces notions.

Quelques explications : MBR veut dire Master Boot Record ce qui désigne l'en-tête du disque (voir ce lien). Cette notion ne dépend pas du modèle de partitionnement (GPT ou ... MBR). Et c'est pour ça que l'on continue d'appeler cette en-tête MBR, que l'on soit en partitionnement GPT ou MBR.

Concernant le fait de parler de modèle DOS plutôt que de modèle MBR, ça ne me paraît pas plus adéquat, car c'est également un terme surchargé :

• je n'ai jamais vu personne employer le terme de partitionnement DOS ;
• on parle parfois de partition DOS pour parler des partitions FAT16 (=

  fat

  ) ou FAT32 (=

  vfat

  ), typiquement

  fdisk

  adopte cette convention ;
• DOS désigne par ailleurs aussi désigne le système d'exploitation MS-DOS, qui a précédé Windows.

Enfin il faut bien distinguer le modèle de partitionnement (donc GPT ou MBR), qui contraint différemment le nombre et la taille des partitions sur un disque, et le système de fichiers associé à chaque partition formatée :

• systèmes de fichiers Linux: ext4, ext3, ext2, ...
• système de fichiers DOS : fat, vfat
• système de fichiers Windows : ntfs

2)

Selon moi, la partition EFI contient des fichiers exploités (notamment des fichiers

.efi

) par LE boot loader (

grub

dans ton cas). Ces fichiers ne sont pas forcément produits lors de l'installation de GRUB (par exemple certains sont déjà présents quand ton Windows est pré-installé).

La partition ESP étant montée dans

/boot/esp

tu peux regarder ce qu'elle contient pour te forger ta propre opinion.

(root@silk) (~) # find /boot/efi/ | grep efi$
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Microsoft/Boot/bootmgr.efi
/boot/efi/EFI/Microsoft/Boot/memtest.efi
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/debian/grubx64.efi
/boot/efi/EFI/debian/shimx64.efi
/boot/efi/EFI/debian/mmx64.efi
/boot/efi/EFI/debian/fbx64.efi

Quoi qu'il en soit, la phrase "An ESP contains the boot loaders or kernel images for all installed operating systems (which are contained in other partitions), device driver files for hardware devices present in a computer and used by the firmware at boot time, system utility programs that are intended to be run before an operating system is booted, and data files such as error logs." (source wikipedia) me paraît très discutable.

Par exemple, le noyau Linux est stocké dans

/boot

(et donc pas dans

/boot/efi

), donc sur la partition

/

de ton système Linux (ou la partition dédiée à

/boot

, selon comment tu as partitionné).

Bonne chance