¿Cuál de los proc, sys, etc. debe montarse (o no) al enlazar en una distribución de "reemplazo"?

Esta respuesta a otra pregunta básicamente se reduce a chrootingresar en otra distribución de Linux para usarla principalmente como reemplazo de su padre demasiado restringido (pero insustituible). Las acciones sugeridas antes de ejecutar chroot, que me gustaría entender mejor, son:

cp /etc/resolv.conf etc/resolv.conf
cp -a /lib/modules/$(uname -r) lib/modules
mount -t proc archproc proc
mount -t sysfs archsys sys
mount -o bind /dev dev
mount -t devpts archdevpts dev/pts

• La copia resolv.confes clara (acceso a Internet / red), aunque no estoy seguro acerca de modulesesto, esto en realidad parecía innecesario al chrootingresar a un sistema Stage3 Gentoo, ¿verdad?
• Pero ¿por qué proc, sysy dev/ptsvolvió a montar en lugar de utilizar unen montado? ¿Cuál es la diferencia real en esta situación, que es "más correcta"?
• Este COMO bind-montajes procy dev, pero tampoco dev/ptsni sysse montan en absoluto. Además, se copia /etc/{hosts,fstab}a la nueva raíz. ¿Tiene sentido? ¿No debería incluir /etc/mdadm.confentonces también?

/etc/resolv.conf se copia para no perder los DNS.

/ lib / modules se copia porque puede ser necesario usar algún componente de hardware que no necesita estar presente al momento de configurar el chroot. Debe recordar que la pregunta original a la que hace referencia en su OP se refiere al reemplazo de un NAS OS con Arch Linux. Por lo tanto, necesitará controladores para Ethernet, posiblemente inalámbricos, varios componentes USB, etc. Copiar la carpeta / lib / modules asegura que el nuevo entorno podrá hacer frente a sus tareas futuras.

De hecho, tiene razón sobre el remontaje frente al montaje de unión. La página Wiki de Arch Linux en chroot usa el remontaje y el montaje de enlace según lo especifique, según la respuesta a la publicación a la que se refiere:

cd /mnt/arch
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/
mount -t devpts pts dev/pts/

(Creo que esto muestra que la sintaxis de sus líneas, copiadas de esta publicación , es incorrecta: el desarrollador que se va a montar precede al punto de montaje).

Sin embargo, la página de manual de Ubuntu en chroot cuenta una historia diferente:

sudo mount -o bind /proc /var/chroot/proc

Aquí / proc se monta en enlace, no se vuelve a montar.

De hecho, he intentado ambas cosas, y después de una breve prueba, no he podido notar ninguna diferencia. No es una gran prueba, lo admito, y así descansaré mi caso aquí para que no haya mucha diferencia.

• /etc/resolv.conf- necesita este archivo para resolver solicitudes DNS. No es necesario en algunas circunstancias:

  1. un cliente DHCP está disponible en el chroot, se ejecuta y el servidor DHCP devuelve la información adecuada (que suele ser el caso).

  2. no está interesado en la creación de redes (o más precisamente haciendo consultas DNS desde aplicaciones habituales que dependen /etc/resolv.conf) desde el interior del chroot.

• /lib/modules/$(uname -r)- Tiene sentido en caso de que necesite cargar módulos adicionales para el núcleo activo. Sin esto, estaría atrapado con lo que sea que tenga actualmente en ejecución. Por lo tanto, si tiene la intención de ejecutar el sistema chroot durante más tiempo, probablemente debería hacerlo. Por otro lado, en tal caso, probablemente debería usarlo pivot_rooten su lugar (que es lo que generalmente hace initrd al final de su vida útil). Si solo necesita hacerlo, por ejemplo, para instalar el gestor de arranque desde el chroot, no debería ser necesario (ya que todos los controladores necesarios deben estar cargados para que pueda hacer el chroot de todos modos).

• /procy /devson bastante obvios: contienen interfaces básicas del sistema.

• /sysIIRC no era que ampliamente utilizado de nuevo en 2007, que es lo que el Slackware (que en sí es bastante conservadora) Cómo hacer es anticuado. En estos días, es probable que su sistema falle de alguna manera sin él (por ejemplo, una vez que algo intenta enumerar algún tipo de hardware).

• /dev/pts- a lo largo de los años hubo varios cambios en la forma en /devque se maneja el árbol. En algún momento los dispositivos /dev/ptsfueron manejados por devfs- vea, por ejemplo, este hilo LKML para la discusión de posibles problemas.

• montaje de enlace: hay algunos aspectos interesantes de los montajes de enlace (se explican bastante bien en la mount(8)página de manual). Por ejemplo si tienes:

  /some/device on /x/a (rw)
  /x/a/A on /x/b (rw)
  

  y luego vuelva a montar /x/asolo lectura, no podrá cambiar nada /x/B. Lo cual es comprensible, pero podría sorprenderlo por primera vez. Otra buena pregunta es qué debería suceder /x/ben el ejemplo anterior cuando usted umount /x/a. Para mí, está lejos de ser obvio, que aún puede acceder al árbol debajo de él. Por lo tanto, el montaje de unión puede ser complicado. Funcionalmente, cuando se usa en todo el sistema de archivos, es lo mismo.

• otras cosas de /etc/: definitivamente tiene sentido copiar la configuración relevante que es útil. Copiar por ejemplo /etc/passwd, /etc/shadow, /etc/groups puede tener sentido, así como claves de servidor para sshd.

/procgestiona procesos y syscambia los parámetros del kernel o accede a la información del kernel actual.

Ahora, teniendo en cuenta que la unión implica una naturaleza bidireccional, procno debe montarse fuera del chroot como la mejor solución.

syspodría ser, pero se basa en el host del núcleo en ejecución actual y debe ser el mismo que dev, montado como enlace.

/dev/ptsya están disponibles como /devmontados en enlace, pero son parte del chroot, por lo que ptsse recomienda volver a montar el nuevo como mount -t devpts none /mnt/drive/dev/pts.