"대체"배포판에 chroot 할 때 proc, sys 등 중 어느 것이 바인드 마운트되어야합니까?

다른 질문에 대한이 답변은 기본적 chroot으로 다른 Linux 배포판 으로 귀결 되어 주로 너무 제한적이지만 대체 할 수없는 부모의 대체품으로 사용합니다. 실행하기 전에 제안 된 조치 chroot는 다음과 같습니다. 더 잘 이해하고 싶습니다.

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

• resolv.conf확실하지는 않지만 복사 는 명확합니다 (네트워크 / 인터넷 액세스) -stage3 젠투 시스템에 modules연결할 때 실제로는 불필요 해 보였습니다 chroot.
• 그러나 bind-mounted를 사용하는 대신 왜 proc, sys및 dev/pts다시 마운트됩니까? 이 상황에서 "더 정확한" 실제 차이점 은 무엇입니까 ?
• 이 하우투의 바인드 마운트 proc및 dev하지만, 어느 dev/pts도는 sys모두에 장착되어있다. 또한 /etc/{hosts,fstab}새 루트로 복사 합니다. 말이 돼? 그때도 포함 시켜서는 안 /etc/mdadm.conf됩니까?

DNS를 잃지 않도록 /etc/resolv.conf가 복사됩니다.

/ lib / modules는 chroot를 설정할 때 필요하지 않은 일부 하드웨어 구성 요소를 사용해야 할 수 있기 때문에 복사됩니다. OP에서 언급 한 원래 질문은 NAS OS를 Arch Linux로 교체하는 것과 관련이 있습니다. 따라서 이더넷, 무선, 다양한 USB 구성 요소 등을위한 드라이버가 필요합니다. / lib / modules 폴더를 복사하면 새로운 환경이 향후 작업에 대처할 수 있습니다.

당신은 실제로 다시 마운트 대 바인드 마운트에 대해 맞습니다. chroot 의 Arch Linux Wiki 페이지는 지정한 게시물에 대한 답변에 따라 사용자가 지정한대로 다시 마운트 및 바인드 마운트를 사용합니다.

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

( 이 게시물 에서 복사 한 라인 구문 이 잘못되었다고 생각합니다. 마운트 할 dev가 마운트 지점보다 우선합니다).

그러나 chroot 의 Ubuntu 매뉴얼 페이지 에는 다른 이야기가 있습니다.

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

여기서 / proc은 바인드 마운트되어 있고 다시 마운트되지는 않습니다.

나는 실제로 두 가지를 모두 시도했으며 간단한 테스트 실행 후 차이점을 알 수 없었습니다. 물론 많은 테스트가 필요하지 않으므로 여기서는 큰 차이가 없어야합니다.

• /etc/resolv.conf-DNS 요청을 해결하려면이 파일이 필요합니다. 일부 상황에서는 필요하지 않습니다.

  1. chroot에서 DHCP 클라이언트를 사용할 수 있고 DHCP 클라이언트가 실행되고 DHCP 서버가 적절한 정보 (보통 경우)를 반환합니다.

  2. /etc/resolv.confchroot 내부 에서 네트워킹에 의존하거나 더 의존하는 일반적인 응용 프로그램에서 DNS 쿼리를 작성하는 데 관심이 없습니다 .

• /lib/modules/$(uname -r)-활성 커널에 추가 모듈을로드해야하는 경우에 적합합니다. 이것이 없으면 현재 실행중인 모든 것에 고착 될 것입니다. 따라서 chroot 된 시스템을 더 오랫동안 실행하려는 경우 아마도 그렇게해야합니다. 반면에, 그런 경우에는 아마도 pivot_root대신에 사용해야 합니다 (일반적으로 수명이 끝날 때 initrd가하는 것임 ). 예를 들어 chroot에서 부트 로더를 설치하는 것만으로는 필요하지 않습니다 (어쨌든 chroot 자체를 수행하려면 필요한 모든 드라이버를로드해야하므로).

• /proc그리고 /dev오히려 명백하다 -이 기본 시스템 인터페이스가 포함되어 있습니다.

• /sysIIRC 아니었다 것을 널리 (자체가 보수적이다) 슬렉웨어는 방법에 일자 무엇 인 2007 년에 다시 사용된다. 요즘 시스템은 어떤 식 으로든 실패 할 가능성이 있습니다 (예를 들어 어떤 유형의 하드웨어를 열거하려고 시도하는 경우).

• /dev/pts-수년에 걸쳐 /dev나무가 처리 되는 방식이 몇 가지 변경되었습니다 . 어느 시점에서 장치는 다음 /dev/pts과 같이 처리되었습니다 . 가능한 문제에 대한 설명은 이 LKML 스레드 를 devfs참조하십시오 .

• 바인드 마운팅-바인드 마운팅에는 흥미로운 부분이 있습니다 ( mount(8)man 페이지 에서 자세히 설명 합니다). 예를 들어 다음과 같은 경우 :

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

  그런 다음 /x/a읽기 전용으로 다시 마운트 하면에서 아무것도 변경할 수 없습니다 /x/B. 이해할 수 있지만 처음으로 놀라게 할 수 있습니다. 또 다른 좋은 질문은 /x/b당신이 위의 예제에서 어떤 일이 발생해야 하는가 umount /x/a입니다. 나를 위해, 당신은 여전히 ​​그 아래의 나무에 액세스 할 수 있다는 것은 분명하지 않습니다. 따라서 바인드 장착이 까다로울 수 있습니다. 기능적으로 전체 파일 시스템에서 사용될 때와 동일합니다.

• 다른 것들 /etc/-사용중인 관련 구성을 복사하는 것이 합리적입니다. 예를 들어, 복사 /etc/passwd, /etc/shadow, /etc/groups 수 에 대한 감각뿐만 아니라 서버 키를 만들 sshd.

/proc프로세스를 관리하고 sys커널 매개 변수 또는 현재 커널의 액세스 정보를 변경합니다.

이제 바인드 가 양방향 특성을 의미한다는 점을 고려하면 proc최상의 솔루션으로 chroot 외부에 마운트해서는 안됩니다.

sys가능하지만 현재 실행중인 커널 호스트에 의존 dev하며 바인드로 마운트 된 것과 동일해야합니다 .

/dev/pts/dev바인드 마운트 상태 로 이미 사용 가능 하지만 chroot의 일부이므로 새 마운트를 다시 마운트하는 pts것이 좋습니다 mount -t devpts none /mnt/drive/dev/pts.