montar dev, proc, sys em um ambiente chroot?


87

Estou tentando criar uma imagem do Linux com pacotes selecionados personalizados.
O que estou tentando fazer é criar manualmente os pacotes que vou usar em um laptop XO, porque a compilação de pacotes leva muito tempo no hardware XO real, se eu puder construir todos os pacotes necessários e apenas exibir o imagem ao XO, posso economizar tempo e espaço.

Quando tentei instalar alguns pacotes, ele não foi configurado devido à falta dos diretórios proc, sys, dev. Então, aprendi em outros lugares que preciso "montar" os diretórios proc, ... no meu ambiente chroot.

Eu vi duas sintaxe e não tenho certeza qual usar.

Na máquina host:

  mount --bind /proc <chroot dir>/proc 

e outra sintaxe (no ambiente chroot):

  mount -t proc none /proc

Qual devo usar e qual a diferença?


Cuidado: conceder acesso aos dispositivos de disco significa que você perde alguns dos benefícios de ' chroot()'. Em particular, o determinado pode ler arquivos fora de sua seção do sistema de arquivos, se você não tomar cuidado.
Jonathan Leffler

2
@ Jonathan Leffler: isso não soa como um problema para o que ele está fazendo.
Zifre 19/07/10

@JonathanLeffler um usuário root em um chroot sempre pode escapar do chroot de qualquer maneira.
LtWorf

Respostas:


43

Para /proce /sys, suponho que você possa usar qualquer um dos métodos. Ambos são sistemas de arquivos especiais para que possam ser recriados inúmeras vezes (o método de montagem de ligação usa exatamente a mesma montagem que o sistema host, enquanto o outro método usa uma nova montagem). Eu sempre vi a montagem de ligação recomendada nos guias, então eu usaria isso. Até onde eu sei, não há diferença realmente importante.

No entanto, /devgeralmente é uma montagem tmpfs gerenciada pelo udev, portanto, deve ser o mesmo sistema de arquivos da máquina host. Isso significa que você precisaria usar o método de montagem de ligação.

Se esse chroot permanecer por algum tempo, você poderá inserir essas entradas no /etc/fstabsistema host para simplificar as coisas.


Gostaria de perguntar se faz sentido copiar (ligar) o proc / sys do host para outra máquina? Por que eles deveriam combinar com essa máquina?
Ransh 30/03

@ransh faz sentido se você ligar / proc ao $ chrootdir / proc, você terá a possibilidade de lidar com o processo e o que está acontecendo dentro / proc dos dois sistemas dos dois sistemas; por exemplo: de chroot você pode verificar se um programa está em execução no host ... etc
Jonah

Talvez o sys typesistema de arquivos of ( hoje ) pareça não existir mais?
174140

111

O Arch Linux Wiki sugere os seguintes comandos:

cd /mnt/arch # or where you are preparing the chroot dir
mount -t proc proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/

2
Eles também pareciam funcionar para mim no ubuntu.
Isaaclw 28/09/12

4
No meu caso (também Ubuntu), eu também precisava de um "mount -o bind / dev / pts dev / pts".
Thomas

Por favor inclua o link para a fonte.
styrofoam fly

@styrofoamfly Adicionado.
Gacrux

1
A partir de 2019, o wiki do ArchLinux agora faz --rbindpara syse dev.
Saad Malik

12

O Manual do Gentoo chama especificamente esses dois comandos para remontar / proc e / dev. Eu os usei várias vezes.

mount -t proc none /mnt/chroot/proc
mount -o bind /dev /mnt/chroot/dev

Eu suspeito / sys é apenas uma pasta comum, então você deve poder criar um link físico.

ln /sys /mnt/chroot/sys

17
Você não pode vincular um diretório (normalmente) como sugere para / sys, e se você usar um link simbólico, ele será quebrado assim que você fizer o chroot.

Eles adicionaram alguns novos, baseados no systemd. Talvez seja uma boa ideia adicioná-los.
AZP

1

Pode ser interessante notar nesta pergunta popular, que o Arch Linux criou um script arch-chroot ; baixararch-install-scripts-15-1-any.pkg.tar.xz

Isso cuida de vários problemas relacionados, tanto no Arch-Linux quanto no Manjaro , onde eu também o usei com sucesso. Possivelmente mais derivados do Arch, como Parabola, também são compatíveis.

Embora um padrão simples chrootem uma instalação secundária do Manjaro não permita que você execute

pacman --sync linux

(a bala de prata após uma falha no sistema), substituindo a linha por

arch-chroot /run/media/*YOURSELF*/manja-disk2

permitirá que você conserte sua instalação secundária derivada do Arch via

pacman --sync linux

como um encanto. O script bash arch-chrootcuida /dev /sys /proce muito mais, que são deixados sozinhos pelo padrão chroot.

veja também: Usando arch-chroot


-1

Existem outros locais de pseudo sistemas de arquivos e tmpfs. Isto está no debian:

/dev/pts 
/run
/run/shm
/proc/sys/fs/binfmt_mist
/var/lib/nfs/rpc_pipefs
/proc/fs/nfsd
/proc/bus/usb

Ele deve estar bem para montar o usbfs, rpc_pipefse devptspseudo-sistemas de arquivos de dentro do chroot. Eu recomendo não vincular /procao chroot /proc, já que o kernel tem o conceito de namespaces e pode realmente colocar coisas diferentes no processo do chroot.

Atualização: de acordo com este encadeamento da lista de discussão , / sys não deve ser montado em ligação, especialmente se os processos chrootados estiverem usando seu próprio espaço para nome de rede.

É uma má ideia montar o sistema /varou /runno chroot, se o chroot tiver seu próprio espaço de nome pid.


Especulação? No superusuário (e em outros fóruns de pilha), geralmente é melhor adiar ou pesquisar e responder com fontes vinculadas, se você não tiver certeza. Isso evita o risco de espalhar dicas equivocadas. Desculpe se decepcionar e boa sorte!
Simon B.

@SimonB. Adicionei um link a uma lista de discussão que suporta a ideia de que / sys não deve ser montado em ligação.
Brian Minton 31/03

Com o namespace pid, você está falando sobre recursos de namespace de usuário mais avançados que podemos encontrar nos kernels modernos do linux (ou seja, os recursos "containers" são baseados)), enquanto quando usamos o termo chroot, nos referimos à alteração tradicional do namespace do arquivo ( e nada mais).
Johan Boulé

-1

A maneira mais fácil é usar um loop for:

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.