disons Fedora et Ubuntu?
… Qui sont tous deux aujourd'hui des systèmes d'exploitation systemd.
Que se passe-t-il dans les systèmes d'exploitation systemd
le mécanisme natif
Systemd utilise différents types d'unités. .mountles fichiers d'unité lui demandent de monter des volumes. .swaples fichiers d'unité lui demandent d'indiquer au noyau les partitions de swap. (Les .servicefichiers unitaires lui expliquent comment exécuter les services. Et ainsi de suite.) Ce sont les mécanismes natifs de systemd. Pour les appliquer, systemd lui-même supprime les processus enfants qui effectuent les appels système appropriés.
Si vous utilisez la systemctlcommande (avec --all) sur un tel système d'exploitation systemd, elle vous indiquera les .swapunités chargées . Par exemple:
dev-disk-by \ x2dpartuuid-40549710 \ x2d05.swap chargé actif actif / dev / disk / by-partuuid / 40549710-05
dev-disk-by \ x2duuid-1bb589e8 \ x2d929f \ x2d4041 \ x2d81f4 \ x2dff2b339b4e2a.swap chargé actif actif / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b339b4
dev-sda5.swap chargé actif actif / dev / sda5
Il vous indiquera également les .mountunités.
Un administrateur système peut effectivement écrire des .swapfichiers unitaires à la main, tout comme peut écrire xe .service, .socketet d' autres fichiers de l' unité à la main. systemd lui-même recherche simplement les fichiers d'unité dans le système de fichiers. Ils sont son mécanisme natif.
On peut même demander à systemd de vous montrer ce qu'il y a dans ces fichiers unitaires et où dans le système de fichiers ils peuvent être trouvés:
$ systemctl cat dev-disk-by \\ x2duuid-1bb589e8 \\ x2d929f \\ x2d4041 \\ x2d81f4 \\ x2dff2b339b4e2a.swap
# /run/systemd/generator/dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap
# Généré automatiquement par systemd-fstab-generator
[Unité]
SourcePath = / etc / fstab
Documentation = man: fstab (5) man: systemd-fstab-generator (8)
[Échanger]
What = / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b339b4e2a
Options = sw
$
fichiers d'unité générés automatiquement
On peut les écrire à la main. En général , cependant ces .mountet les .swapfichiers unitaires sont générés automatiquement par des programmes appelés générateurs . Deux de ces générateurs sont systemd-fstab-generatoret systemd-gpt-auto-generator. Ils s'exécutent tous les deux au début du processus d'amorçage et en réponse à une systemctl daemon-reloadcommande, et (comme vous pouvez le voir ci-dessus), ils génèrent une charge entière de fichiers d'unité dans un sous-répertoire non documenté dans /run/systemd/. systemd lui- même utilise simplement ces fichiers d'unité générés .
L'ancien générateur lit /etc/fstab, reconnaissant plusieurs extensions systemd à ce format de fichier. Comme je l'ai souligné dans un commentaire de réponse, les partitions de swap ont traditionnellement le type de montage de swet c'est ainsi que l'on trouvera que d'autres systèmes d'exploitation reconnaissent les enregistrements de swap dans ce tableau. Mais les logiciels Linux ont pris la voie alternative de reconnaître le type VFS à la place, en le recherchant swapcomme type VFS. systemd-fstab-generatorne fait pas exception ici, et c'est ainsi qu'il interprète /etc/fstablors de sa conversion en mécanismes natifs.
Ce dernier générateur traite la table de partition EFI qui se trouve sur le même disque que celui contenant la partition système EFI, à la recherche des entrées de table de partition EFI qui ont divers GUID de type de partition bien connus . L'un de ces GUID est le GUID conventionnel attribué aux partitions d'échange Linux; et si systemd-gpt-auto-generatortrouve une partition avec ce GUID (qui satisfait les critères donnés dans le docu systemd) il en fera une .swapunité; pas du tout /etc/fstabimpliqué .
Bien sûr, ce processus a beaucoup d'effets secondaires. Par exemple, comme /etc/fstabil n'y a pas de clé primaire dans la table, les enregistrements peuvent avoir des champs "spéc" et "fichier" (c'est-à-dire "quoi" et "où") en double. Dans le mécanisme natif de systemd, cependant, le champ "fichier" (c'est-à-dire "où") est une clé unique pour les .mountunités, incorporée dans les noms des unités. Deux .mountunités ne peuvent pas le partager. Pour les .swapunités, le champ "spec" (c'est-à-dire "quoi") est la clé unique pour les unités. Deux .swapunités ne peuvent pas partager cela. Donc, tous les enregistrements ne /etc/fstabsont pas nécessairement convertibles en mécanismes natifs et fonctionneront, surtout si les gens font des choses comme lister le même point de montage à deux fins différentes ou lister la même partition de swap de deux manières différentes.
De même, parce qu'il s'est traduit /etc/fstabpar le mécanisme natif et que le mécanisme natif de systemd a d'autres moyens d'activer les unités , le comportement est subtilement différent de celui des systèmes d'exploitation non-systemd. Une .mountunité sera, par défaut, automatiquement activée parsystemd-udevd , même après l'amorçage, en réponse à l'apparition du périphérique de stockage monté. Ou il peut être répertorié comme un Wants=ou Requires=d'une partie .serviceou d'une .socketunité, ce qui signifie qu'il sera (réactivé) lorsqu'ils le seront. Il y en a même RequiresMountsFor=.
programmes d'installation et la manière systemd
Traditionnellement, les programmes d'installation du système d'exploitation et l'administrateur systemd reconfigurant ensuite le système ont des swentrées écrites dans /etc/fstab. Et c'est ainsi que le natif .mountet les .swapunités finissent par être générés automatiquement. L'utilitaire d'installation / configuration "sait" où le fichier d'échange a été placé, car dans son interface utilisateur, l'administrateur système a fait une sorte de choix et écrit un /etc/fstabpour correspondre. Parfois, ce choix est que j'ai besoin de vous pour me faire une partition d'échange dans le cadre de l'installation. ; Parfois, il suffit d'utiliser la partition de swap que vous avez déjà trouvée sur le disque. (les installateurs examinent également les types de partitions).
Mais les gens de systemd ont cette idée de systèmes d'exploitation qui se configurent automatiquement à partir d'une /etcarborescence largement vide , les systèmes dits sans état , et c'est à cela que servent des mécanismes comme le générateur qui lit la table de partition EFI. Dans le plan des gens de systemd, il n'y a pas /etc/fstab, et en fait aucune donnée de configuration persistante sous /etc, et tout cela est déduit du contenu de la table de partition sur le disque , à chaque démarrage et à chaque systemctl daemon-reload. De nos jours, ils font la promotion de programmes d'installation de système d'exploitation que n'en écrivent pas/etc/fstab .
Dans le schéma traditionnel, bien sûr, vous pouvez en effet avoir chaque système d'exploitation a sa propre partition de swap privée, et ne pas les faire toucher les partitions de swap les uns des autres. Et en effet, si vous utilisez la mise en veille prolongée sur un disque via une partition de swap et que vous vous attendez à pouvoir démarrer plusieurs fois sur un autre système d'exploitation en veille prolongée ( ce qui est une très mauvaise idée car il est très facile de provoquer une corruption du système de fichiers de cette façon ), ce sera nécessaire.
Dans le schéma systemd, même si le système d'exploitation n'est pas encore comme les gens systemd l'envisagent et "sans état", les générateurs susmentionnés fonctionnent; et ainsi toutes les partitions de swap (sur le disque ESP / root) avec le type de partition requis sont automatiquement utilisées par tous les systèmes d'exploitation systemd. Puisqu'ils partageront toutes les partitions d'échange découvertes automatiquement, il n'est vraiment pas nécessaire de créer une partition d'échange par système d'exploitation installé.
Lectures complémentaires