"대체" 배포판으로 루트를 전환할 때 어떤 proc, sys 등을 번들로 마운트해야 합니까(또는 번들로 마운트하지 않아야 합니까)?

"대체" 배포판으로 루트를 전환할 때 어떤 proc, sys 등을 번들로 마운트해야 합니까(또는 번들로 마운트하지 않아야 합니까)?

이것은 다른 질문에 대한 답변입니다기본적으로 다른 Linux 배포판으로 귀결되므로 chroot주로 지나치게 제한되어 있지만 대체할 수 없는 상위 배포판을 대체하는 데 사용할 수 있습니다. 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확실하지는 않지만 복제는 명확합니다(네트워크/인터넷 액세스). modules이는 실제로 stage3 Gentoo 시스템에 들어갈 때 불필요해 보입니다. 그렇죠?chroot
  • 그런데 proc바인드 설치를 사용하는 대신 다시 설치하는 이유는 무엇입니까? 무엇인가요sysdev/pts실제이 경우 "더 정확한" 것은 무엇입니까?
  • 이 작동 방법마운트 proc및 을 바인딩 dev하지만 마운트가 전혀 없습니다 dev/pts또는 . sys또한 /etc/{hosts,fstab}새 루트 디렉터리에 복사됩니다. 말이 돼? 나도 /etc/mdadm.conf포함되어서는 안 되는 걸까?

답변1

DNS를 잃지 않으려면 /etc/resolv.conf를 복사하십시오.

chroot를 설정할 때 필요하지 않은 일부 하드웨어 구성 요소를 사용해야 할 수도 있으므로 /lib/modules가 복사됩니다. 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/

(내 생각에 이것은 다음에서 복사한 행의 구문을 보여주는 것 같습니다.이 게시물, 틀렸습니다: 마운트할 개발자가 마운트 지점 앞에 있습니다.

하지만, 그chroot의 우분투 매뉴얼 페이지다른 이야기를 들려줍니다:

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

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

실제로 두 가지 방법을 모두 시도해 보았지만 짧은 테스트 실행 후에도 아무런 차이를 발견할 수 없었습니다. 물론 이것은 그다지 큰 테스트가 아니므로 큰 영향을 미치지 않을 것이므로 여기서는 제 의견을 제쳐두겠습니다.

답변2

  • /etc/resolv.conf- DNS 요청을 해결하려면 이 파일이 필요합니다. 어떤 경우에는 필요하지 않습니다.

    1. DHCP 클라이언트는 chroot에서 사용할 수 있고 실행되며 DHCP 서버는 적절한 정보를 반환합니다(일반적으로 그렇습니다).

    2. /etc/resolv.confchroot 내부의 네트워크(또는 더 정확하게는 이에 의존하는 일반 애플리케이션의 DNS 쿼리)에는 관심이 없습니다.

  • /lib/modules/$(uname -r)- 활성 커널에 대해 다른 모듈을 로드해야 하는 경우에 적합합니다. 이것이 없으면 현재 실행 중인 작업을 계속할 수 없습니다. 따라서 장기간 루트가 지정된 시스템을 실행하려는 경우 이 작업을 수행해야 합니다. 반면에, 아마도 이 경우에 이를 사용해야 할 것입니다 pivot_root(보통 initrd가 수명 주기 마지막에 수행하는 작업입니다). chroot에서 부트로더를 설치하는 것과 같이 이 작업만 수행해야 하는 경우에는 이것이 필요하지 않습니다(chroot 자체를 수행하려면 필요한 모든 드라이버를 로드해야 하기 때문입니다).

  • /proc그리고 /dev그것은 매우 분명합니다. 기본 시스템 인터페이스가 포함되어 있습니다.

  • /sysIIRC 아닌가요?저것2007년부터 널리 사용되었으며, 여기서 Slackware(자체는 매우 보수적) How-to가 쓸모 없게 되었습니다. 요즘에는 이것이 없으면 시스템이 어떤 방식으로든 실패할 가능성이 높습니다(예: 특정 유형의 하드웨어를 열거하려고 시도하는 경우).

  • /dev/pts- /dev나무를 다루는 방법에 있어서 수년에 걸쳐 약간의 변화가 있었습니다. 어느 시점에서 장치는 /dev/pts다음으로 구성됩니다.devfs- 예를 들어 참조하세요.이 LKML 스레드발생할 수 있는 문제에 대해 논의합니다.

  • 마운트 바인드 - 마운트 바인드에는 몇 가지 흥미로운 측면이 있습니다( mount(8)맨 페이지에 잘 설명되어 있습니다). 예를 들어 다음과 같은 경우가 있습니다.

    /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.

답변3

/proc프로세스를 관리하고 sys커널 매개변수를 변경하거나 현재 커널에 대한 정보에 액세스합니다.

이제 고려해보면제본양방향 특성을 의미하므로 procchroot 외부에 설치하지 않는 것이 가장 좋습니다.

sys예, 하지만 현재 실행 중인 커널 호스트에 따라 다르며 dev동일한 호스트에 대한 바인딩으로 마운트되어야 합니다.

/dev/pts이미 /dev바인드 설치로 사용할 수 있지만 chroot의 일부이므로 pts새로 설치하는 것이 좋습니다 mount -t devpts none /mnt/drive/dev/pts.

관련 정보