chroot 환경에서 dev, proc, sys를 마운트 하시겠습니까?


87

사용자 지정 선택 패키지로 Linux 이미지를 만들려고합니다.
내가하려고하는 것은 XO 랩톱에서 사용할 패키지를 직접 만드는 것입니다. 패키지를 컴파일하는 데 필요한 모든 패키지를 빌드하고 플래시를 플래시 할 수 있다면 실제 XO 하드웨어에서 실제로 시간이 오래 걸리기 때문입니다. 이미지를 XO에 저장하면 시간과 공간을 절약 할 수 있습니다.

일부 패키지를 설치하려고 할 때 proc, sys, dev 디렉토리가 없어서 구성하지 못했습니다. 그래서 다른 곳에서 호스트 proc 디렉토리를 "chroot"환경에 "마운트"해야한다는 것을 알게되었습니다.

나는 두 가지 구문을 보았고 어느 것을 사용 해야할지 확실하지 않습니다.

호스트 머신에서 :

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

또 다른 구문 (chroot 환경에서) :

  mount -t proc none /proc

어느 것을 사용해야합니까? 차이점은 무엇입니까?


주의 : 디스크 장치에 대한 액세스 권한을 부여하면 ' chroot()' 의 이점 중 일부가 손실됩니다 . 특히,주의하지 않으면 결정된 파일 시스템의 섹션 외부에서 파일을 읽을 수 있습니다.
Jonathan Leffler

2
@Jonathan Leffler : 그가하는 일에 문제가되지는 않습니다.
Zifre

@JonathanLeffler chroot의 루트 사용자는 항상 chroot를 벗어날 수 있습니다.
LtWorf

답변:


43

들어 /proc/sys, 나는 당신이 두 방법을 사용할 수도있을 것 같군요. 둘 다 특수 파일 시스템이므로 여러 번 다시 작성할 수 있습니다 (바인드 마운트 방법은 호스트 시스템과 동일한 마운트를 사용하는 반면 다른 방법은 새 마운트를 사용함). 나는 항상 가이드에서 권장되는 바인드 마운트를 보았으므로 그것을 사용할 것입니다. 내가 아는 한, 중요한 차이점은 없습니다.

그러나 /dev일반적으로 udev가 관리하는 tmpfs 마운트이므로 호스트 시스템과 실제로 동일한 파일 시스템이어야합니다. 즉, 바인드 마운트 방법을 사용해야합니다.

이 chroot가 잠시 동안있을 경우 이러한 항목을 /etc/fstab호스트 시스템에 배치하여 작업을 단순화 할 수 있습니다.


호스트에서 다른 컴퓨터로 proc / sys를 복사 (바인딩)하는 것이 합리적인지 묻고 싶습니다. 왜 그 기계와 일치해야합니까?
ransh

@ransh / proc을 $ chrootdir / proc에 바인드하면 감지됩니다. 두 시스템 모두에서 두 시스템의 / proc 내부에서 진행되는 프로세스와 프로세스를 처리 할 수 ​​있습니다. 예 : chroot에서 프로그램이 호스트에서 실행 중인지 확인할 수 있습니다 ... etc
Jonah

아마 sys type파일 시스템의가 (나타납니다 오늘 더 이상 존재하지 않는)?
174140

111

아치 리눅스 위키는 다음 명령을 제안한다 :

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
그들은 또한 우분투에서 나를 위해 일하는 것 같았습니다.
isaaclw

4
제 경우에는 (또한 우분투) "mount -o bind / dev / pts dev / pts"도 필요했습니다.
토마스

출처에 대한 링크를 포함하십시오.
스티로폼 비행

@styrofoamfly가 추가되었습니다.
gacrux

1
2019로, 아치 리눅스 위키 지금 수행 --rbind을 위해 sysdev.
Saad Malik

12

젠투 핸드북은 특별히 다시 장착 / proc 디렉토리와 / dev에 대한이 두 가지 명령을 호출합니다. 나는 여러 번 사용했습니다.

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

/ sys는 단지 일반 폴더라고 생각하므로 하드 링크를 만들 수 있어야합니다.

ln /sys /mnt/chroot/sys

17
/ sys에 대해 제안한 것처럼 디렉토리를 하드 링크 할 수 없으며 (심지어) 심볼릭 링크를 사용하면 chroot하자마자 끊어집니다.

그들은 systemd를 기반으로 새로운 것을 추가했습니다. 아마도 그것들을 추가하는 것이 좋습니다.
AzP

1

이 대중적인 질문에서 Arch Linux가 스크립트를 arch-chroot 로 만들었다는 점에 주목할 가치가 있습니다 . 다운로드arch-install-scripts-15-1-any.pkg.tar.xz

이것도 Arch-LinuxManjaro 에서 다양한 관련 문제를 처리 하여 성공적으로 사용했습니다. 아마도 더 Arch- 유도체 와 같은 포물선 단지뿐만 아니라 호환됩니다.

chroot보조 Manjaro 설치에 대한 간단한 표준 은 실행을 허용하지 않지만

pacman --sync linux

(시스템 충돌 후 은색 탄환)

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

를 통해 보조 아치 파생 설치를 수정할 수 있습니다.

pacman --sync linux

매력처럼. bash 스크립트 arch-chroot/dev /sys /proc표준에 의해 단독으로 남겨진 훨씬 더 많은 것을 처리합니다 chroot.

또한 참조 : arch-chroot 사용


-1

다른 의사 파일 시스템과 tmpfs 위치가 있습니다. 이것은 데비안에 있습니다 :

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

마운트 괜찮해야한다 usbfs, rpc_pipefs그리고 devpts는 chroot 내에서 의사 파일 시스템. 나는 두시길 하지 바인딩 /proc는 chroot 년대에 /proc커널이 네임 스페이스의 개념을 가지고 있기 때문에, 실제로는 chroot의 PROC에서 다른 것을 넣을 수 있습니다.

업데이트 : 이 메일 링리스트 쓰레드 에 따르면 , 특히 chroot 된 프로세스가 자체 네트워크 네임 스페이스를 사용하는 경우 / sys를 바인드 마운트하지 않아야합니다.

chroot에 자체 pid 네임 스페이스가있는 경우 시스템 /var또는 /runchroot에 마운트하는 것은 좋지 않습니다 .


추측? 수퍼 유저 (및 다른 스택 포럼)에서는 확실하지 않은 경우 일반적으로 링크 된 소스를 사용하여 조사하고 응답하는 것이 좋습니다. 이것은 잘못된 힌트를 퍼뜨리는 위험을 피하기위한 것입니다. 실망과 행운이 있다면 미안합니다!
Simon B.

@SimonB. / sys를 바인드 마운트해서는 안된다는 생각을 지원하는 메일 링리스트에 대한 링크를 추가했습니다.
Brian Minton

pid 네임 스페이스를 사용하면 최신 Linux 커널에서 찾을 수있는 고급 사용자 네임 스페이스 기능 (즉 "컨테이너"기능을 기반으로하는 기능)에 대해 이야기하는 반면 chroot라는 용어를 사용하면 전통적인 파일 네임 스페이스 변경 ( 그리고 다른 것은 없습니다).
Johan Boulé

-1

가장 쉬운 방법은 for 루프를 사용하는 것입니다.

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.