digamos Fedora y Ubuntu?
… Ambos son actualmente sistemas operativos systemd.
Que sucede en los sistemas operativos systemd
el mecanismo nativo
Systemd emplea varios tipos de unidades. .mountlos archivos de la unidad le indican que monte volúmenes. .swaplos archivos de la unidad le indican que le diga al núcleo acerca de las particiones de intercambio. (los .servicearchivos de la unidad le indican cómo ejecutar servicios. Y así sucesivamente). Estos son los mecanismos nativos del sistema. Para promulgarlos, systemd mismo bifurca los procesos secundarios que realizan las llamadas relevantes del sistema.
Si utiliza el systemctlcomando (con --all) en dicho sistema operativo systemd, le informará sobre las .swapunidades cargadas . Por ejemplo:
dev-disk-by \ x2dpartuuid-40549710 \ x2d05.swap cargado activo activo / dev / disk / by-partuuid / 40549710-05
dev-disk-by \ x2duuid-1bb589e8 \ x2d929f \ x2d4041 \ x2d81f4 \ x2dff2b339b4e2a.swap cargado activo activo / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b339b4e2
dev-sda5.swap cargado activo activo / dev / sda5
También le informará sobre las .mountunidades.
Un administrador del sistema puede escribir realmente esos .swaparchivos unitarios de la mano, al igual que xe puede escribir .service, .sockety otros archivos de la unidad de mano. systemd mismo solo busca archivos unitarios en el sistema de archivos. Son su mecanismo nativo.
Incluso se puede obtener systemd para mostrarle qué hay en estos archivos de unidad y en qué parte del sistema de archivos se pueden encontrar:
$ 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
# Generado automáticamente por systemd-fstab-generator
[Unidad]
SourcePath = / etc / fstab
Documentación = man: fstab (5) man: systemd-fstab-generator (8)
[Intercambiar]
Qué = / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b339b4e2a
Opciones = sw
PS
archivos de unidad generados automáticamente
Se pueden escribir a mano. Por lo general, sin embargo, tales .mounty .swaparchivos unitarios son generados automáticamente por programas conocidos como generadores . Dos de estos generadores son systemd-fstab-generatory systemd-gpt-auto-generator. Ambos se ejecutan temprano en el proceso de arranque y en respuesta a un systemctl daemon-reloadcomando, y (como puede ver arriba) generan una carga completa de archivos de unidad en un subdirectorio no documentado en /run/systemd/. systemd solo usa esos archivos unitarios generados .
El generador anterior lee /etc/fstaby reconoce varias extensiones systemd para ese formato de archivo. Como señalé en un comentario de respuesta, tradicionalmente las particiones de intercambio tienen el tipo de montajesw y así es como uno encontrará que otros sistemas operativos reconocen los registros de intercambio en esta tabla. Pero los softwares de Linux han tomado la alternativa de reconocer el tipo VFS en su lugar, buscándolo swapcomo el tipo VFS. systemd-fstab-generatorno es una excepción aquí, y así es como se interpreta /etc/fstabal convertirlo en los mecanismos nativos.
El último generador procesa la tabla de particiones EFI que se encuentra en el mismo disco que contiene la partición del sistema EFI, buscando entradas de la tabla de particiones EFI que tienen varios GUID de tipo de partición conocidos . Uno de esos GUID es el GUID convencional asignado a las particiones de intercambio de Linux; y si systemd-gpt-auto-generatorencuentra una partición con ese GUID (que satisface los criterios dados en el systemd doco) creará una .swapunidad para él; No /etc/fstabinvolucrado en absoluto .
Por supuesto, este proceso tiene muchos efectos secundarios. Por ejemplo, debido a que /etc/fstabno tiene una clave principal para la tabla, los registros pueden tener campos duplicados de "especificación" y "archivo" (es decir, "qué" y "dónde"). Sin embargo, en el mecanismo systemd nativo, el campo "archivo" (es decir, "dónde") es una clave única para las .mountunidades, incrustada en los nombres de las unidades. No hay dos .mountunidades que puedan compartirlo. Para las .swapunidades, el campo "spec" (es decir, "qué") es la clave única para las unidades. No hay dos .swapunidades que puedan compartir eso. Por lo tanto, no todos los registros /etc/fstabson necesariamente convertibles a los mecanismos nativos y funcionarán, especialmente si las personas hacen cosas como enumerar el mismo punto de montaje para dos propósitos diferentes o enumerar la misma partición de intercambio de dos maneras diferentes.
De manera similar, debido a que se ha traducido /etc/fstaben el mecanismo nativo y el mecanismo nativo del sistema tiene otras formas de activar unidades , el comportamiento es sutilmente diferente al de los sistemas operativos que no son del sistema. .mountPor defecto, una unidad se activará automáticamentesystemd-udevd , incluso después del arranque, en respuesta a la apariencia del dispositivo de almacenamiento montado. O se puede enumerar como Wants=o Requires=de alguna .serviceo .socketunidad, lo que significa que se (re) activará cuando lo estén. Hay incluso RequiresMountsFor=.
programas de instalación y la forma systemd
Tradicionalmente, los programas de instalación del sistema operativo y el administrador del sistema luego de reconfigurar el sistema tienen swentradas escritas en /etc/fstab. Y así es como el nativo .mounty las .swapunidades terminan siendo autogenerados. La utilidad de instalación / configuración "sabe" dónde se colocó el archivo de intercambio, porque en su interfaz de usuario el administrador del sistema hizo algún tipo de elección, y escribe un /etc/fstabpara que coincida. A veces, esa opción es que necesito que me hagas una partición de intercambio como parte de la instalación. ; a veces es Solo use la partición de intercambio que ya encontró en el disco. (instaladores mirando los tipos de partición, también).
Pero la gente de systemd tiene esta idea de sistemas operativos que se configuran automáticamente desde un /etcárbol en gran parte vacío , los llamados sistemas sin estado , y de eso se tratan mecanismos como el generador que lee la tabla de particiones EFI. En el plan de la gente systemd, no hay /etc/fstab, y de hecho no hay datos de configuración persistentes /etcen absoluto, y todo esto se deduce del contenido de la tabla de particiones en el disco , en cada arranque y en cada uno systemctl daemon-reload. Actualmente están promoviendo programas de instalación del sistema operativo que no escriben un/etc/fstab .
En el esquema tradicional, por supuesto, puede hacer que cada sistema operativo tenga su propia partición de intercambio privada, y no hacer que toquen entre sí las particiones de intercambio. Y, de hecho, si está utilizando hibernar a disco a través de una partición de intercambio y espera poder realizar un arranque múltiple a otro sistema operativo mientras está en hibernación (lo cual es una muy mala idea porque es muy fácil causar daños al sistema de archivos de esta manera ) eso será necesario.
En el esquema systemd, incluso si el sistema operativo aún no está como lo imaginan las personas systemd y "apátridas", los generadores antes mencionados funcionan; y así todas las particiones de intercambio (en el disco ESP / root) con el tipo de partición requerido son empleadas automáticamente por todos los sistemas operativos systemd. Dado que compartirán todas las particiones de intercambio descubiertas automáticamente, realmente no es necesario crear una partición de intercambio por sistema operativo instalado.
Otras lecturas