partitionnement
Bonjour,
J'ai installé Trisquel et Hyperbola en dualboot sur mon Libreboot X200 et tout fonctionne très bien.
Cependant, je ne comprends pas très bien le partitionnement de mon disque et la manière dont cela fonctionne.
Voilà ce que j'ai fait:
J'ai installé Hyperbola en premier, car l'installateur de Trisquel permet de détecter un autre système d'exploitation.
D'abord Hyperbola :
sda1 : partition étendue totalité du disque dur
sda5 : boot 200M
sda6 : swap 8G
sda7 : root 30G
sda8 : home le reste
Ensuite, lors de l'installation de Trisquel,l'installateur m'a proposé de redimensionner sda8 pour Trisquel, c'est ce que j'ai fait.
Donc, 3 nouvelles partitions :
sda9
sda10
sda11
Je ne me rappelle plus exactement, mais une des 3 partitions était swap. C'était le partionnement habituel de Trisquel.
Il y avait donc 2 partition swap en tout.
Cela fonctionnait très bien pour Hyperbola, mais problème d'agencement de clavier sur Trisquel, impossible de rentrer le mot de passe en mode graphique comme en mode texte.
Alors j'ai repris cfdisk, et j'ai reppris l'installateur de Trisquel avec l'outil de partitionnement, j'ai supprimé les partitions Trisquel, et créé une partition sda9 avec l'espace disponible et j'ai recommencé l'installation.
Cette fois Trisquel s'est installé sur sda9 et utilise désormais la même partition swap qu'Hyperbola (sda6). Trisquel n'utilise donc que 2 partitions sda6 (swap) et sda9. J'ai défini sda9 comme partition racine à l'installation de Trisquel. Mais alors Trisquel n'a ni de partition pas de partition boot ? Je ne comprends pas très bien.
J'aimerais savoir si mon partitionnement est correcte et ne représente pas de risque.
Merci d'avance pour votre aide.
Pas de « risque », non. Néanmoins, il est pratique de mettre /home sur une partition à part : cela permet d’installer un autre système par-dessus le premier, de spécifier quoi monter en /home (le système de fichiers existant sur la partition séparée) sans formater (bien sûr) et donc sans avoir à récupérer les données utilisateurs d’une sauvegarde (que tu veux néanmoins réaliser régulièrement et tout particulier avant l’installation d’un nouveau système).
En fait, tu pourrais même utiliser une seule et même partition /home pour les deux systèmes. Je l’ai déjà fait. Il faut néanmoins faire en sorte que les numéros des utilisateurs (uid) et des groupes (gid) soient les même sur les deux systèmes. Il peut aussi y avoir des soucis si une même application utilisateur est utilisée sur les deux systèmes mais dans des versions différentes dont les configurations sont incompatibles.
Maintenant une petite leçon pour que tu comprennes mieux ces histoires de partitions et de système de fichiers.
Sur GNU/Linux, du point de vue des utilisateurs, absolument tous les fichiers sont organisés dans une seule et même hiérarchie, c’est-à-dire suivant une unique arborescence. La racine de cette arborescence est /. Il en part plusieurs branches comme « bin », « boot », etc. terminales ou non (ce sont alors des dossiers d’où partent d’autres branches). Physiquement, néanmoins, le sous-arbre de fichiers qui part de n’importe quel dossier (n’importe quel dossier, pas nécessairement un dossier au premier niveau) peut être sur une partition séparée, voire sur un autre disque, peut-être même sur un disque distant avec lequel on interagit au travers du réseau. À l’opposé, tous les fichiers peuvent être dans une unique partition.
Sauf à parler d’abstractions logicielles (LVM), une partition ne s’étend que sur un disque. Par exemple, lorsque tu insères une clé USB, les fichiers dessus sont sur une partition qui n’est, bien sûr, pas la même que celle où se trouve ton système. Pourtant, ces fichiers apparaissent dans l’unique hiérarchie de fichiers, typiquement sans un sous-dossier de /media. La ou les partitions de la clé USB (car, oui, on peut partitionner une clé USB) sont dits « montés » (avec la commande 'mount') sur l’arborescence, de la même façon qu’init monte, peu après le chargement du noyau, les partitions spécifiées dans /etc/fstab (qui liste aussi la ou les partitions swap qui, elles, ne sont pas montées avec 'mount' mais activées avec 'swapon' : j’en parle plus tard).
Sauf que, pour parler plus précisément, ce ne sont pas les partitions du disque (rien de plus qu’un intervalle de secteurs du disque) qui sont montées mais leurs systèmes de fichiers. Les partitions sont, en effet, « formatées », c’est-à-dire que les fichiers sur une partition sont organisés d’une façon ou d’une autre, définie par le type de système de fichiers choisi : ext4, xfs, btrfs, fat, etc. Voilà d’ailleurs une raison pour vouloir partitionner un disque : choisir des types de système de fichiers différents pour différents sous-arbres de la hiérarchie de fichiers. Certains types de système de fichiers sont plus sûrs (moins de problème en cas d’arrêt du système au beau milieu d’une écriture), d’autres sont plus efficaces avec des petits fichiers, ou des gros fichiers, d’autres sont supportées par d’autres système d’exploitation (une caractéristique intéressante pour une clé USB), etc. Partitionner un disque permet aussi de pouvoir reformater une partition sans toucher aux autres, par exemple d’installer un système GNU/Linux par-dessus un autre sans toucher aux fichiers utilisateurs dans un système de fichiers séparé, monté en /home. L’inconvénient d’avoir plusieurs partitions est qu’il s’agit de les dimensionner correctement : on ne veut pas se retrouver avec une partition pleine (empêchant toute nouvelle écriture dans le sous-arbre correspondant de la hiérarchie de fichiers) alors qu’il y a de la place à revendre sur une autre partition, surtout si on a utilisé un type de système de fichiers qui ne supporte pas le redimensionnement (encore une caractéristique qui diffère d’un type de système de fichiers à un autre).
Et la swap dans tout ça ? Il ne s’agit pas d’un système de fichiers mais d’une partition jouant le rôle d’extension de la mémoire vive : si les programmes exécutés viennent à utiliser toute cette mémoire, le système peut continuer à fonctionner grâce à la swap. Le noyau écrit alors (de façon transparente pour les programmes) sur la partition swap (qui peut en fait aussi être un simple fichier) les données supplémentaires que les programmes stockent normalement en mémoire vive… et le système rame car accéder au disque est typiquement cent fois plus lent qu’accéder à la mémoire vive. Néanmoins, dans cette même situation de pénurie de mémoire vive mais sans swap, le noyau arrête violemment le programme qu’il *croît* fautif de nécessiter trop de mémoire. Bref, il est préférable de ramer le temps de sauvegarder le travail réalisé et de fermer consciemment les applications dont on ne sert plus. Pour cet usage, il n’y a aucune raison d’avoir plusieurs partitions swap : tous les systèmes GNU/Linux peuvent utiliser la même car, comme pour la mémoire vive, le contenu de la swap n’est pas censé être conservé après extinction/redémarrage du système. Sauf que la swap étant de fait sur le disque, son contenu est persistent et la fonctionnalité d’hibernation utilise cette persistance : elle copie le contenu de la mémoire vive en swap et réalise l’opération inverse lors de la sortie d’hibernation. Donc, pour pouvoir hiberner deux systèmes, je suppose (car je n’ai jamais testé) qu’il faut deux partitions swap.
Des questions ? Il y aura interro demain ! :-)
Merci beaucoup pour cette petite leçon, tout cela me semble plus clair maintenant :-)
Pourrais-tu m'en dire un peu plus sur la partition /boot ? J'imagine qu'elle sert à lancer le système d'exploitation mais j'ai lu sur le forum ubuntu qu'elle n'était pas forcément nécessaire. Et puis je croyais que Grub suffisait pour lancer le système. Je ne comprends pas très bien.
Ce que doit contenir chaque dossier système de GNU/Linux est défini par une norme, le « Filesystem Hierarchy Standard » : http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
Pour /boot : http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s05.html (je découvre que les noyaux ne sont pas nécessairement dans /boot; ils peuvent aussi être directement dans /; je n’ai jamais utilisé une distribution faisant ce choix).
/boot contient, entre autres, les éventuels fichiers accédés par le chargeur d’amorçage. C’est le cas sur Trisquel, où ce chargeur d’amorçage est, par défaut, GNU GRUB. Ceci étant, le BIOS ne sait rien sur la hiérarchie de fichiers. Le chargeur de démarrage doit alors être à un endroit précis : dans les 512 premiers octets du disque, le Master Boot Record (MBR). 512 octets, c’est peu ! Un chargeur de démarrage extrêmement rudimentaire s’en contente. Sinon, les instructions dans ces 512 octets sont ce que l’on appelle le « stage 1 » du chargeur d’amorçage. Elles chargent, depuis /boot, le « stage 2 » qui s’occupe du reste.
En fait, aujourd’hui il y a l’UEFI qui remplace le BIOS et le GPT qui remplace la table de partitionnement de la MBR (qui ne permet pas d’adresser plus de 2,2 To sur un disque). Avec ces technologies plus récentes, le stage 1 peut-être n’importe où sur le disque (un endroit spécifié par la GPT).
Merci pour ce lien précieux et pour les informations. C'est passionnant de découvrir le fonctionnememt de tout cela !