Utilisateur:jcl_vanier
De Wiki de la communauté Mandriva.
Cette page constitue un appel à commentaires (RFC ;)
Sommaire |
Combien de partitions peut-on créer sur un même disque dur ?
Réponse : ça dépend
Oui, mais encore ?
Un disque dur d'un PC, peut contenir jusqu'à 4 partitions dites primaires. L'adresse physique de ces 4 partitions est inscrite dans le premier secteur du disque (le MBR ou Master Boot Record). L'une de ces partitions peut être marquée comme partition étendue. Elle pourra alors contenir un certain nombre de nouvelles partitions dites logiques. Chacune de ces partitions logiques contient un premier secteur (EBR ou Extended Boot Record) contenant l'adresse de la partition logique suivante. Il faut donc parcourir cette chaîne d'adresses pour accéder à une partition quelconque.
L'avantage de cette structure est qu'il n'y a pas vraiment de limite au nombre de partitions logiques que l'on peut créer, sinon la limite du bon sens et de la taille du disque.
Cependant traditionnellement linux pouvait gérer 64 partitions (en fait 63 ou 62).
Comment?
Du point de vue du noyau, un disque est un périphérique comme un autre. Son accès est rendu possible par l'intermédiaire de fichiers spéciaux placés dans le répertoire /dev et dont le nom évoque le type de périphérique : hard disk. On a donc une série de fichiers nommés /dev/hd* Le premier disque (du point de vue du bios) porte le nom /dev/hda, le deuxième /dev/hdb etc.
À l'intérieur de chaque disque, les partitions sont reconnues par un numéro. Et contrairement à l'habitude en informatique la numérotation ne commence pas par 0 mais par 1 (ce qui peut causer des confusions lorsqu'on configure grub mais c'est un autre sujet). On a donc :
/dev/hda1 pour la première partition primaire /dev/hda2 pour la deuxième, /dev/hda3 pour la troisième et /dev/hda4 pour la quatrième.
Si une partition primaire est marquée comme étendue, les partitions logiques ont un numéro commençant par 5
/dev/hda5 pour la première /dev/hda6 pour la deuxième etc.
Une particularité de ce système est que quel que soit le nombre de partitions primaires, la première partition logique portera le nom /dev/hda5.
Le noyau, lui, identifie les périphériques par des couples de nombres, associés aux noms de fichiers spéciaux. Ces couples sont composés de ce qu'on appelle un code majeur (type de périphérique) suivi d'un code mineur (numéro d'ordre).
Historiquement, l'attribution d'un code majeur/mineur, était déterminé par une liste type inscrite une fois pour toute dans un fichier permettant aux développeurs l'écriture homogène des pilotes. Il fallait, au démarrage du système créer une grande quantité de fichiers spéciaux dont la majeur partie n'était pas utilisée. Aujourd'hui, seuls les fichiers nécessaires sont créés dynamiquement.
Chaque disque dur peut disposer d'un code majeur et d'une plage de 64 codes mineurs pour les différentes partitions. On attribue au premier disque la plage 0-63, au deuxième disque de même type la plage 64-127 et ainsi de suite.
Le premier numéro de chaque plage identifie le disque lui-même, et les suivants les partitions.
La partition étendue , si elle existe, présente une particularité : elle est référencée dans la liste des codes mais pas dans la liste des fichiers spéciaux. En effet, seules les partitions logiques peuvent être montées, pas la partition étendue qui les contient. Par contre, le noyau a besoin d'y accéder pour retrouver les adresses des partitions logiques.
En bref, sur les 64 codes mineurs attribuables à un disque, le premier concerne le disque lui-même (ce qui permet à un utilitaire comme fdisk de fonctionner) et un autre concerne la partition étendue. On peut donc, sous Linux, monter au maximum 62 partitions sur un disque dur.
Voici un exemple de ce qu'on peut voir avec la commande ls sur un système doté de disques IDE.
# ls -l /dev/hd* | sort -k 6.1 -n brw-r----- 1 root disk 3, 0 2009-02-18 22:57 /dev/hda brw-r----- 1 root disk 3, 1 2009-02-18 22:57 /dev/hda1 brw-r----- 1 root disk 3, 2 2009-02-18 22:57 /dev/hda2 brw-r----- 1 root disk 3, 5 2009-02-18 21:57 /dev/hda5 brw-r----- 1 root disk 3, 6 2009-02-18 21:57 /dev/hda6 brw-r----- 1 root disk 3, 7 2009-02-18 22:57 /dev/hda7 brw-r----- 1 root disk 3, 8 2009-02-18 21:57 /dev/hda8 brw-r----- 1 root disk 3, 9 2009-02-18 21:57 /dev/hda9 brw-r----- 1 root disk 3, 10 2009-02-18 21:57 /dev/hda10 brw-r----- 1 root disk 3, 11 2009-02-18 21:57 /dev/hda11 brw-r----- 1 root disk 3, 64 2009-02-18 22:57 /dev/hdb brw-r----- 1 root disk 3, 65 2009-02-18 22:57 /dev/hdb1 brw-r----- 1 root disk 3, 66 2009-02-18 22:57 /dev/hdb2 brw-r----- 1 root disk 3, 69 2009-02-18 21:57 /dev/hdb5 brw-r----- 1 root disk 3, 70 2009-02-18 21:57 /dev/hdb6 brw-r----- 1 root disk 3, 71 2009-02-18 21:57 /dev/hdb7 brw-rw----+ 1 root floppy 22, 0 2009-02-18 22:57 /dev/hdc brw-rw----+ 1 jcl cdwriter 22, 64 2009-02-18 21:57 /dev/hdd
code majeur ----------------^ ^ code mineur --------------------^
On peut voir que les disques hda et hdb ont le même code majeur. hda a le mineur 0 et hdb a le mineur 64 laissant les numéros inférieurs à la disposition de hda.
Les lecteurs de disquettes et de CD ont le même majeur 22 et se voient attribués les mêmes plages de 64 mineurs que les disques durs.
Depuis la version 2008, voir les notes 2008, les disques durs reconnus comme /dev/sd* ne sont plus traité de la même manière. Par défaut, on leur attribue seulement une plage de 16 codes mineurs selon le même principe. Le premier code désigne le disque et un autre code désigne la partition étendue. On peut donc, par défaut, monter un maximum de 14 partitions sur ces disques.
Sur un système plus récent, la commande ls donne :
# ls -l /dev/sd* | sort -k 6.1 -n brw-rw---- 1 root disk 8, 0 2009-02-20 21:46 /dev/sda brw-rw---- 1 root disk 8, 1 2009-02-20 21:46 /dev/sda1 brw-rw---- 1 root disk 8, 2 2009-02-20 21:46 /dev/sda2 brw-rw---- 1 root disk 8, 16 2009-02-20 21:46 /dev/sdb brw-rw---- 1 root disk 8, 17 2009-02-20 21:46 /dev/sdb1 brw-rw---- 1 root disk 8, 18 2009-02-20 21:46 /dev/sdb2 brw-rw---- 1 root disk 8, 19 2009-02-20 21:46 /dev/sdb3 brw-rw---- 1 root disk 8, 21 2009-02-20 20:46 /dev/sdb5 brw-rw---- 1 root disk 8, 22 2009-02-20 20:46 /dev/sdb6 brw-rw---- 1 root disk 8, 23 2009-02-20 20:46 /dev/sdb7 brw-rw---- 1 root disk 8, 24 2009-02-20 20:46 /dev/sdb8 brw-rw---- 1 root disk 8, 25 2009-02-20 20:46 /dev/sdb9 brw-rw---- 1 root disk 8, 26 2009-02-20 21:46 /dev/sdb10 brw-rw---- 1 root disk 8, 27 2009-02-20 20:46 /dev/sdb11 brw-rw---- 1 root disk 8, 28 2009-02-20 20:47 /dev/sdb12 brw-rw---- 1 root disk 8, 29 2009-02-20 20:47 /dev/sdb13 brw-rw---- 1 root disk 8, 30 2009-02-20 21:46 /dev/sdb14 brw-rw---- 1 root floppy 8, 32 2009-02-20 20:46 /dev/sdc brw-rw---- 1 root floppy 8, 48 2009-02-20 20:46 /dev/sdd brw-rw---- 1 root floppy 8, 64 2009-02-20 20:46 /dev/sde brw-rw---- 1 root floppy 8, 80 2009-02-20 20:46 /dev/sdf
On voit bien ici les plages de 16 mineurs.
Extrait des notes 2008
Pilotes modulaires IDE et nouvelle pile libata
Les anciens pilotes PATA (communément appelés IDE) sont maintenant compilés en tant que modules — voir les changements liés au noyau concernant les pilotes modulaires IDE ci-dessous. De ce fait, l'installateur peut maintenant aussi bien utiliser les anciens pilotes comme les nouveaux en utilisant la pile libata.
L'installateur prend par défaut les vieux pilotes pour des raisons de consistance et de fiabilité : utiliser les nouveaux pilotes par défaut a été testé mais n'était pas sans problèmes.
Les nouveaux pilotes possèdent comme nom générique "libata". Tous les disques PATA et SATA contrôlés par libata utilisent désormais /dev/sd* pout leur nom de périphérique au lieu de /dev/hd*.
Quand un contrôleur est supporté seulement par les nouveaux pilotes (libata), l'installation au-delà de la 15ème partition des disques PATA (les disques SCSI, SATA et PATA/IDE sont tous des disques PATA) n'est plus supportée par défaut.
Pour effectuer une installation au delà de la 15ème partition, le noyau d'installation doit être démarré avec le paramètre noauto, qui permettra une sélection manuelle de l'ancien pilote PATA approprié, qui en réalité supporte jusqu'à 63 partitions par disque PATA, comme dans les versions précédentes de Mandriva.
Les personnes ayant besoin de partitionnements complexes peuvent aussi utiliser LVM, qui offre bien plus de flexibilité système pour créer des volumes.
Un problème à éviter
Drakdisk autorise (20/02/09) la création de 15 partitions logiques dans une partition étendue (on suppose qu'on est sur un disque reconnu comme sd*), sans tenir compte des partitions primaires déjà créées. Cela conduit inévitablement à des problèmes. ce fil.
Serveur X, gestionnaire de fenêtres et bureaux
Fonctionnement d'une session graphique sous mdv
Habituellement, on démarre avec
service dm start
qui appelle /etc/X11/prefdm
Celui-ci choisit le gestionnaire de connexion (display manager - DM) dans /etc/sysconfig/desktop et cherche le script de configuration correspondant avec /etc/X11/lookupdm dans /usr/share/X11/dm.d puis lance le DM. Celui-ci peut être: xdm, kdm, gdm, slim, wdm [1]
Le DM établit la liste des bureaux ou des gestionnaires de fenêtres (windows manager - WM) utilisables d'après le contenu de /usr/share/apps/kdm/sessions/ pour kdm ou bien /etc/X11/dm/Sessions/ pour gdm. Dans ce dernier cas, j'ai par exemple :
01KDE4.desktop 02GNOME.desktop 03WindowMaker.desktop 04LXDE.desktop 05BlackBox.desktop 07IceWM.desktop 13vtwm.desktop 26Openbox.desktop 29drak3d.desktop fvwmi.desktop mini-fvwmi.desktop opale.desktop
xdm n'offre pas le choix du type de session mais cherche dans
- ~/.desktop (préférence utilisateur)
- /etc/sysconfig/desktop (préférence globale)
- session par défaut
Kde et Gnome sont clairement des bureaux alors que Icewm peut être considéré comme un gestionnaire de fenêtres légèrement amélioré par rapport aux ancêtres comme fvwm ou twm qui n'est qu'un WM (comme son nom l'indique).
Kde et Gnome ont chacun leur gestionnaire de fenêtre par défaut : kwin et metacity Mais ils peuvent être remplacés par n'importe quel autre en principe. Le mcc offre le choix entre compiz-fusion et metisse. Pour cela il va modifier le fichier /etc/sysconfig/compositing-wm qui contient :
COMPOSITING_WM_START=no
pour lancer le WM par défaut, ou bien
COMPOSITING_WM_START=yes COMPOSITING_WM=<nom du WM>
Lorsqu'on a choisi un type de session dans le DM, celle-ci est lancée le plus souvent (cela dépend du contenu des fichiers .desktop vus plus haut) via le script /usr/bin/start<nom_de_session> (startkde, starticewm, startgnome, …)
Ces scripts sont plus ou moins élaborés selon l'environnement choisi.
Dans le cas de startkde, tout une série de tests et de configurations sont réalisés avant de lancer kde. Notamment des variables d'environnement sont fixées :
KDE_FULL_SESSION=true KDE_SESSION_VERSION=4 KDE_SESSION_UID=$UID
Ensuite, après le lancement de kde via kdeinit4, le gestionnaire de fenêtres est lancé via
kwrapper4 ksmserver –windowmanager $KDEWM
Si la variable KDEWM n'est pas initialisée, c'est kwin qui sera lancé.
X
le serveur X offre un service élémentaire d'affichage de fenêtres pour des applications graphiques. Il est étroitement lié à la notion de « display ».
Un « display » (une console graphique) est un ensemble « affichage graphique/dispositif de pointage/clavier » dont on retrouve la configuration matérielle dans /etc/X11/xorg.conf (aujourd'hui seuls l'écran et la carte graphique sont l'objet de directives de configuration, les options par défaut étant suffisantes pour la souris et le clavier).
On sait qu'il existe des consoles texte, traditionnellement au nombre de 6, numérotées de tty1 à tty6. Elles sont activées par init d'après les directives de /etc/inittab. De même, les displays sont liés à des consoles virtuelles dont les numéros commencent par vt7.
On accède à ces consoles par ALT CTRL Fn (n pouvant varier de 1 à 12 si on a 12 touches de fonction) ou simplement ALT Fn si on est déjà dans une console texte.
Les consoles graphiques sont dites virtuelles car on peut lancer plusieurs serveurs X sur la même machine physique avec la commande :
X :n
avec n pouvant varier de 0 à 5 si on a 12 touches de fonction. Cependant la console accessible par ALT F12 est réservée aux messages système sur mdv. On l'active via le mcc dans sécurité/Configurer la sécurité.../sécurité du système/ENABLE_CONSOLE_LOG. X peut être lancé par tout utilisateur du système.
Note : les consoles textes sont elles aussi virtuelles, bien qu'on les appelle tty pour des raisons historiques.
À partir du moment où le serveur est actif, on peut lancer une application graphique cliente qui fonctionnera parfaitement. Il est nécessaire auparavant d'initialiser la variable DISPLAY pour permettre à l'application de savoir à quel serveur elle doit s'adresser :
export DISPLAY=:n
toujours avec n compris entre 0 et 5
L'application cliente peut demander l'affichage sur n'importe quel serveur, qu'il soit local ou distant, à condition cependant que ce dernier accepte la connexion. Il n'est pas alors suffisant d'utiliser la notation simplifiée :n
La notation complète est :
<hôte>:<numéro de display>.<écran>
En effet une machine peut gérer plusieurs écrans physiques.
- Si <hôte> est omis, localhost est l'hôte par défaut.
- Si <écran> est omis, l'écran 0 est l'écran par défaut.
Exemple : sur l'ordinateur boson, j'ai lancé mon bureau comme d'habitude. Celui-ci utilise le serveur :0 Je peux lancer un autre serveur :2 , par exemple. Celui-ci, en l'absence de directive contraire, s'emparera de la première console virtuelle disponible vt8. Je peux alors, depuis un autre ordinateur, elite, afficher une application graphique sur boson en fixant la variable DISPLAY ainsi :
export DISPLAY=boson:2.0
ou plus simplement :
export DISPLAY=boson:2
Note : certaines applications (comme xeyes par exemple) acceptent l'option
-display <display à utiliser>
dispensant d'avoir à fixer la variable DISPLAY. D'autres options permettent de fixer la couleur, la taille et la position de la fenêtre.
Il est nécessaire aussi d'indiquer au serveur X qu'il doit autoriser les connexions distantes. Il existe plusieurs méthodes de contrôle d'accès. Le plus simple, ici, est d'autoriser elite à se connecter en lançant sur boson :
xhost +elite
ou
xhost +
pour autoriser toutes les connexions distantes (voir man xhost et man Xserver).
On peut aussi vérifier que les options de sécurité du système (mdv) autorisent les connexions réseau pour les serveurs X :
mcc/sécurité/configurer la sécurité.../sécurité du système/ALLOW_XSERVER_TO_LISTEN
Je peux alors contrôler mon application qui tourne sur elite et qui a accès à ses ressources, depuis boson. L'application n'a pas accès aux ressources (fichiers) de boson.
Il est possible aussi d'utiliser le serveur boson:0 et afficher l'application sur le bureau de boson bénéficiant ainsi de la possibilité de manipuler la fenêtre de l'application (voir plus loin : WM et bureaux) .
On peut contrôler l'apparence, la définition de l'affichage et le comportement du serveur au lancement ou lorsqu'il est déjà en fonctionnement :
- man X
- man Xorg
- man Xserver
- man xorg.conf
- man xsetroot
Un exemple simple
Depuis une console texte utilisateur:
X :1 vt09 -retro &
lance un serveur X sur le display :1 avec un curseur en forme de croix et un fond gris sur la console vt9
export DISPLAY=:1
évite d'avoir à préciser l'option -display pour les commandes suivantes
xeyes -geometry 500x500+300+300 -center green -outline yellow -fg red &
affiche les yeux en couleurs dans une fenêtre carrée de 500 pixels de côté et à 300 pixels du bord haut et du bord gauche de l'écran
xsetroot -solid "#401080"
l'écran est violet: effrayant, non ?
On peut voir les changements après chaque commande avec ALT CTRL F9.
Gestionnaires de fenêtres (WM)
Une fois que la fenêtre de l'application est lancée, elle fonctionne (en principe) mais on ne peut pas manipuler sa position et sa taille à l'aide de la souris. Si on lance plusieurs applications à la suite, leurs fenêtres vont se superposer : par défaut, elles seront placées au coin supérieur gauche.
C'est là qu'intervient le gestionnaire de fenêtres. On peut le lancer et l'arrêter n'importe quand après le serveur X : avant ou après les applications graphiques. On peut aussi en changer en cours de route. C'est un client du serveur X comme un autre !. Il faut donc au moins que la variable d'environnement DISPLAY soit correctement initialisée.
Bien entendu, si on arrête le WM, les fenêtres des autres applications clientes de X resteront figées. Dans les tous premiers WM on avait twm (qu'on peut installer : urpmi twm), un gestionnaire de fenêtres minimaliste. On a maintenant des WM plus évolués en fonctionnalités et en apparence. Leur rôle est d'abord de permettre la manipulation aisée des fenêtres. Certains ont aussi une ambition esthétique et cherchent à obtenir une décoration agréable.
Exemple: si à la suite des commandes de l'exemple précédent, on lance twm, on pourra facilement changer la taille et la position des yeux:
twm &
En plus ça leur ajoute une barre du plus bel effet !
IceWM fait partie de cette catégorie. On peut le configurer et il donne accès à un menu pour lancer directement (depuis la session X) des applications. On a aussi BlackBox, FluxBox et bien d'autres.
Bureaux
Un WM c'est déjà bien mais un bureau ajoute d'autres fonctionnalités. Fondamentalement, c'est ensemble de clients X, un environnement, offrant toute une série d'utilitaires le plus souvent accessibles via des icônes ou via la fenêtre qui occupe toute la surface d'affichage : le bureau proprement dit. Ce bureau a besoin comme les autres applications d'un gestionnaire de fenêtres.
kwin est le WM par défaut de kde mais on peut le remplacer par n'importe quel autre en principe. On peut par exemple arrêter kwin et lancer icewm. Par exemple, si on a le bureau sur le display :0, depuis une console (texte ou graphique) on peux lancer les commandes suivantes :
su - # habituellement la session graphique est lancée au démarrage du système par root export DISPLAY=:0 killall kwin icewm
Amusant, non ?
Relations entre serveur X et DM
Le DM (display manager) est un client X comme un autre. Cela signifie qu'on peut le lancer sur n'importe quel serveur : local ou distant. Prenons kdm (qui me paraît le plus facile à configurer, c'est juste une question de goût).
Son fichier de configuration est dans /usr/share/config/kdm/kdmrc (qui est en fait un lien vers etc/alternatives/kdm4-config/ lui-même un lien vers /var/lib/mandriva/kde4-profiles/common/share/config/kdm/kdmrc )
La première section contient en principe :
[General] ConfigVersion=2.3 ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6 PidFile=/var/run/kdm.pid ReserveServers=:1,:2,:3,:4,:5 ServerVTs=-7 StaticServers=:0
On trouve une documentation très complète sur ce ficher (et kdm en général) ici sur le site de kde.org :
ReserveServers= ce sont les serveurs temporaires sur lesquels kdm peut être lancé.
ServerVTs= première console virtuelle à utiliser. En effet, normalement kdm lance le serveur X local avant d'afficher la fenêtre de connexion.
StaticServers= ce sont les serveurs permanents (disponibles au lancement de kdm).
La syntaxe des deux directives StaticServer et ReserveServer est la suivante :
:n indique le display du serveur X à lancer
hôte:n indique sur quel serveur X (déjà lancé) kdm doit afficher la fenêtre de connexion
Exemple (mon ordi s'appelle elite)
ReserveServers=:2,:3,:4,:5 StaticServers=:0,localhost:1,boson:1
Au démarrage, kdm lancera un serveur X sur le display local :0, et affichera une fenêtre de connexion sur le serveur local :1 (s'il est déjà lancé) ainsi que sur le serveur distant boson:1 (s'il est déjà lancé et s'il accepte les connexions).
Je peux donc me connecter à elite depuis les displays :0 et :1 d'elite ainsi que depuis le display :1 de boson. Ce mécanisme est distinct de celui offert par XDMCP (X Display Manager Control Protocole).
XDMCP, s'il est autorisé (voir la section éponyme de kdmrc), permet à un ordinateur distant d'initier une connexion vers un serveur X local sous un compte local. Par exemple, depuis boson, je peux me connecter sur elite en lançant la commande :
X -query elite
qui affichera sur boson la fenêtre de connexion du kdm lancé sur elite.
La différence réside essentiellement dans l'initiative de la connexion.
On peut donc imaginer la configuration suivante. Soit 3 ordis : elite, boson et neutron.
Un serveur X tourne sur boson. Je lance kdm sur elite avec la configuration suivante :
[General] StaticServers=boson:0 [Xdmcp] Enable=true
Depuis neutron, j'initie une connexion xdmcp sur elite :
X :0 -query elite
Je peux donc travailler sur elite (qui est une machine puissante) depuis boson et neutron.
La connexion boson-elite est initiée par elite. Boson doit autoriser la connexion TCP/IP à son serveur X.
La connexion elite-neutron est initiée par neutron. Elite doit autoriser le protocole xdmcp. C'est kdm qui gère cette autorisation et en tant que client local du serveur X, il n'y a pas besoin que X soit autorisé à écouter sur le port 600n (avec n, numéro du display).
Notons enfin que le DM lance le serveur X local en mode exclusif. En effet lorsque la fenêtre de connexion est affichée, nulle autre application ne peut s'afficher sur ce serveur. Alors que le serveur distant sur lequel peut s'afficher la fenêtre de connexion n'est pas affecté par cette "prise pouvoir".
On peut donc configurer kdm (je n'ai pas essayé avec gdm) pour que localhost:0 soit considéré comme distant et inventer un script qui ajoute une application par dessus. On peut imaginer par exemple une vidéo de bienvenue !
