Qual de proc, sys etc. deve ser montado por bind (ou não) ao chrooting em uma distribuição de “substituição”?

Question

Esta resposta a outra pergunta basicamente resume-se a chroot ing em outra distribuição Linux para principalmente use isso como um substituto para seu pai muito restrito (mas insubstituível). As ações sugeridas antes de executar chroot , que eu gostaria de entender melhor, são:

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

• Copiar resolv.conf é claro (rede / acesso à internet), embora eu não tenha certeza sobre o modules - isso realmente parecia desnecessário quando chroot ing em um sistema G3 do stage3, certo?
• Mas por que proc , sys e dev/pts são remontados em vez de usar o bind-mounted? Qual é a diferença real nesta situação, que é "mais correta"?
• This How bind-mounts proc e dev , mas nem dev/pts nem sys estão montados em absoluto. Além disso, copia /etc/{hosts,fstab} para a nova raiz. Isso faz sentido? Eu não deveria incluir /etc/mdadm.conf então?

Answer 1

/etc/resolv.conf é copiado para não perder os DNSs.

/ lib / modules é copiado porque pode ser necessário usar algum componente de hardware que não precisa estar presente no momento da configuração do chroot. Você deve lembrar-se de que a pergunta original a que se refere no seu OP diz respeito à substituição de um NAS OS pelo Arch Linux. Assim, você precisará de drivers para ethernet, possivelmente sem fio, vários componentes USB e assim por diante. Copiar a pasta / lib / modules garante que o novo ambiente será capaz de lidar com suas tarefas futuras.

Você está realmente certo sobre re-montagem vs. montagem de bind. A página Wiki do Arch Linux no chroot usa a montagem de novo e a montagem de ligação conforme você especificar, conforme a resposta para o post que você se refere:

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

(acho que isso mostra a sintaxe de suas linhas, copiada de este post , está errado: o dev a ser montado precede o ponto de montagem).

No entanto, a página de manual do Ubuntu no chroot conta uma história diferente:

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

Aqui / proc é montado em encadernação, não é montado novamente.

Eu realmente tentei as duas coisas, e depois de um breve teste, não consegui perceber nenhuma diferença. Não muito de um teste, reconhecidamente, e assim descansarei meu caso aqui que não deveria fazer muita diferença.

    

Answer 2

• /etc/resolv.conf - você precisa deste arquivo para resolver solicitações de DNS. Não é necessário em algumas circunstâncias:

  1. um cliente DHCP está disponível no chroot, ele é executado e o servidor DHCP retorna as informações apropriadas (o que geralmente é o caso).

  2. você não está interessado em fazer networking (ou, mais precisamente, fazer consultas DNS a partir de aplicativos comuns que dependem de /etc/resolv.conf ) de dentro do chroot.

• /lib/modules/$(uname -r) - faz sentido caso você precise carregar módulos adicionais para o kernel ativo. Sem isso você estaria preso com o que você está executando atualmente. Portanto, se você pretende executar o sistema chrooted por mais tempo, provavelmente deve fazê-lo. Por outro lado, nesse caso, você provavelmente deve usar pivot_root (que é o que geralmente o initrd faz no final da sua vida). Se você só precisa fazer isso, por exemplo Para instalar o bootloader a partir do chroot, ele não deve ser necessário (já que todos os drivers necessários devem ser carregados para que você possa fazer o próprio chroot de qualquer maneira).

• /proc e /dev são bastante óbvios - eles contêm interfaces básicas do sistema.

• /sys foi o IIRC não que foi amplamente usado em 2007, que é o que o Slackware (que em si é bastante conservador) How-to é datado. Atualmente, seu sistema provavelmente falhará de alguma forma sem ele (por exemplo, uma vez que algo tenta enumerar algum tipo de hardware).

• /dev/pts - ao longo dos anos, houve várias alterações em como o /dev tree é manipulado. Em algum momento, os dispositivos em /dev/pts foram manipulados por devfs - veja, por exemplo, este encadeamento LKML para discussão de possíveis problemas.

• bind mounting - há alguns aspectos interessantes de montagens de bind (bastante explicadas em mount(8) man page). Por exemplo, se você tiver:

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

  e depois remontar /x/a somente leitura, você não poderá alterar nada em /x/B . O que é compreensível, mas pode surpreendê-lo pela primeira vez. Outra boa pergunta é o que deve acontecer com /x/b no exemplo acima quando você umount /x/a . Para mim, está longe de ser óbvio que você ainda pode acessar a árvore abaixo dela. Portanto, a montagem de bind pode ser complicada. Funcionalmente, quando usado em todo o sistema de arquivos, é o mesmo.

• outras coisas de /etc/ - definitivamente faz sentido copiar uma configuração relevante que seja útil. Copiando, e. /etc/passwd , /etc/shadow , /etc/groups pode fazer sentido, assim como as chaves do servidor para sshd .

Answer 3

/proc gerencia processos e sys altera parâmetros do kernel ou informações de acesso do kernel atual.

Agora, levando em consideração que bind implica em uma natureza bidirecional, proc não deve ser montado fora do chroot como a melhor solução.

sys poderia ser, mas ele depende do host do kernel em execução atual e deve ser o mesmo que dev , montado como ligação.

/dev/pts já estão disponíveis, pois /dev é montado por ligação, mas faz parte do chroot, portanto, o novo pts é recomendado como mount -t devpts none /mnt/drive/dev/pts .