![Puntos de montaje no vacíos con btrfs (SLES15): ¿son necesarios?](https://rvso.com/image/1672329/Puntos%20de%20montaje%20no%20vac%C3%ADos%20con%20btrfs%20(SLES15)%3A%20%C2%BFson%20necesarios%3F.png)
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 /mnt
y 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/cache
se montó, umount
tuvo éxito, pero aún ll /var/cache
mostraba 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 chroot
entorno, 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/root
Contiene un sistema de archivos Btrfs. Varias entradas en su fstab
montan diferentes subvolúmenes en diferentes puntos de montaje.
Hipótesis: el subvolumen predeterminado en el sistema de archivos Btrfs /dev/sys/root
es /@
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 /@/var
del árbol Btrfs como /var
en el árbol del sistema operativo. Quiero decir, si intentas acceder/var
antes /var
está 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á
/@/var
los Btrfs a/var
partir del sistema operativo.
Sucede /@/var
que Btrfs es un subvolumen.Ademásmontar subvol=/@/var
en /var
(del sistema operativo) hará que aparezca el mismo directorio que /var
(del sistema operativo). En concreto, si accedes ahora /var
entonces
- el sistema operativo comprobará si
/var
(del sistema operativo) es un punto de montaje; es y está asociado con/@/var
los Btrfs; - entonces el sistema operativo le mostrará
/@/var
los 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 /@/var
los Btrfs como /var
en el SO.
Varias otras entradas en su fstab
montaje 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=/var
el montaje, tendría sentido porque /var
Btrfs 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ó,
umount
tuvo éxito, pero aúnll …
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 fstab
montaje subvolúmenes diferentes donde las vería de todos modos. En estos casos, eliminando el contenido después de umount
eliminar 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:
- Su punto de montaje de ejemplo es
/var/cache
, supuestamente lo desmontó; pero no hay ninguno/var/cache
en lofstab
que publicaste. - Según lo que
fstab
publicaste, 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 encontrarnormal.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 fstab
del sistema operativo afectado. Sospecho /boot
que se utilizó el mismo sistema de archivos que /
, se montó innecesariamente y, por lo tanto, era propenso al escenario descrito de romper cosas.