Puntos de montaje no vacíos con btrfs (SLES15): ¿son necesarios?

Puntos de montaje no vacíos con btrfs (SLES15): ¿son necesarios?

Tengo muchos años de experiencia en UNIX, pero creo que cometí un error fatal:

Al ver mensajes durante el arranque sobre puntos de montaje que no estaban vacíos, aproveché la oportunidad para limpiarlos mientras migraba un sistema a un nuevo entorno. Arranqué el sistema de rescate SLES, monté el sistema de archivos raíz y la estructura básica del sistema (proc, sys, dev) en /mnt, luego hice chroot /mnty mount -va.

Entonces todo se veía bien, ajusté algunos ajustes de configuración y mientras lo desmontaba verifiqué los puntos de montaje. Por ejemplo: /var/cachese montó, umounttuvo éxito, pero aún ll /var/cachemostraba un punto de montaje no vacío mientras que el sistema de archivos se mostraba no montado. Entonces eliminé el contenido.

Básicamente repetí los pasos para cada sistema de archivos montado, luego salí del chrootentorno, desmonté el resto y reinicié.

Lamentablemente, el sistema no arranca porque GRUB se quejó de que no puede encontrarlo normal.mod.

Entonces, ¿es esta una característica de los subvolúmenes btrfs? ¿Quién puede explicar lo que estaba pasando?

/etc/fstab

Como me pidieron /etc/fstab, esto es lo que tiene un sistema típico:

/dev/sys/root                              /            btrfs  defaults              0  0
/dev/sys/root                              /var         btrfs  subvol=/@/var         0  0
/dev/sys/root                              /usr/local   btrfs  subvol=/@/usr/local   0  0
/dev/sys/root                              /tmp         btrfs  subvol=/@/tmp         0  0
/dev/sys/root                              /srv         btrfs  subvol=/@/srv         0  0
/dev/sys/root                              /root        btrfs  subvol=/@/root        0  0
/dev/sys/root                              /opt         btrfs  subvol=/@/opt         0  0
UUID=9fd27493-d194-48ba-a4bc-3551123e0d3b  /home        xfs    defaults              0  0
/dev/sys/boot                              /boot        btrfs  defaults              0  0
UUID=0092-D1D5                             /boot/efi    vfat   utf8                  0  2
/dev/sys/root                              /.snapshots  btrfs  subvol=/@/.snapshots  0  0

Respuesta1

como funciono

/dev/sys/rootContiene un sistema de archivos Btrfs. Varias entradas en su fstabmontan diferentes subvolúmenes en diferentes puntos de montaje.

Hipótesis: el subvolumen predeterminado en el sistema de archivos Btrfs /dev/sys/rootes /@y una vez montado en /, se montan muchos otros subvolúmenesen sus puntos de montaje particularestiene poco o ningún sentido porque los directorios correctos (y generalmente no vacíos) ya están donde los espera.

(Para ver el subvolumen predeterminado, ejecute sudo btrfs subvolume get-default /).

Por favor leeesta otra respuesta miay comprender la diferencia conceptual entre el árbol de directorios (y subvolúmenes) Btrfs en un dispositivo y la estructura de directorios en su sistema operativo. Sin este conocimiento, el resto de la respuesta actual puede resultarle muy confuso.

Si el subvolumen predeterminado es/@, /@del árbol Btrfs aparece como /en el árbol del SOjunto con todo lo que hay debajo. Este montajesoloes suficiente ver, por ejemplo, el directorio /@/vardel árbol Btrfs como /varen el árbol del sistema operativo. Quiero decir, si intentas acceder/var antes /varestá montado entonces

  • el sistema operativo comprobará si /var(del sistema operativo) es un punto de montaje; que no es;
  • entonces el sistema operativo verificará si /(del sistema operativo) es un punto de montaje; es y está asociado con /@los Btrfs;
  • entonces el sistema operativo le mostrará /@/varlos Btrfs a /varpartir del sistema operativo.

Sucede /@/varque Btrfs es un subvolumen.Ademásmontar subvol=/@/varen /var(del sistema operativo) hará que aparezca el mismo directorio que /var(del sistema operativo). En concreto, si accedes ahora /varentonces

  • el sistema operativo comprobará si /var(del sistema operativo) es un punto de montaje; es y está asociado con /@/varlos Btrfs;
  • entonces el sistema operativo le mostrará /@/varlos Btrfs.

Y si desmontas /var(del sistema operativo), volverás al primer caso.

Por lo tanto, no importa si /var(el sistema operativo) está montado o no (prácticamente no importa, puede haber sutilezas). De una forma u otra verás /@/varlos Btrfs como /varen el SO.

Varias otras entradas en su fstabmontaje de diferentes subvolúmenesdonde los verías de todos modos. Realmente no veo el sentido de estas entradas (alguna sutileza que no puedo identificar en este momento puede ser el objetivo; o estas entradas son totalmente inútiles).

A modo de comparación: si /var(del sistema operativo) se montó con subvol=/varel montaje, tendría sentido porque /varBtrfs no está debajo /@de Btrfs y, por lo tanto, no se puede alcanzar simplemente montando /@Btrfs a /partir del sistema operativo.


como lo rompiste

… se montó, umounttuvo éxito, pero aún ll …mostraba un punto de montaje no vacío mientras que el sistema de archivos se mostraba no montado. Entonces eliminé el contenido.

Como dije, varias entradas en su fstabmontaje subvolúmenes diferentes donde las vería de todos modos. En estos casos, eliminando el contenido después de umounteliminar el contenido que viste antes umount. Pensó que había eliminado contenidos sombreados e irrelevantes, pero en realidad eliminó los contenidos importantes y reales.

Sin embargo, hay dos cosas que no encajan:

  1. Su punto de montaje de ejemplo es /var/cache, supuestamente lo desmontó; pero no hay ninguno /var/cacheen lo fstabque publicaste.
  2. Según lo que fstabpublicaste, mientras /(del sistema operativo) proviene de /dev/sys/root, /boot(del sistema operativo) proviene de /dev/sys/boot. El mecanismo descrito de romper cosas no puede aplicarse. Sin embargo, afirmas que "GRUB se quejó de que no puede encontrar normal.mod" y de esto deduzco que de alguna manera rompiste las cosas /boot.

Por lo tanto, sospecho que lo publicado fstab(usted lo describió como "lo que tiene un sistema típico") no es elexacto fstabdel sistema operativo afectado. Sospecho /bootque se utilizó el mismo sistema de archivos que /, se montó innecesariamente y, por lo tanto, era propenso al escenario descrito de romper cosas.

información relacionada