mount dev, proc, sys dalam lingkungan chroot?


87

Saya mencoba membuat gambar Linux dengan paket pilihan.
Apa yang saya coba lakukan adalah membuat paket yang akan saya gunakan pada laptop XO, karena mengkompilasi paket membutuhkan waktu yang sangat lama pada perangkat keras XO yang sebenarnya, jika saya bisa membangun semua paket yang saya butuhkan dan hanya menginstalnya. gambar ke XO, saya bisa menghemat waktu dan ruang.

Ketika saya mencoba untuk menginstal beberapa paket, gagal untuk mengkonfigurasi karena tidak ada direktori proc, sys, dev. Jadi, saya belajar dari tempat lain bahwa saya perlu "me-mount" host proc, ... direktori ke lingkungan chroot saya.

Saya melihat dua sintaks dan tidak yakin yang mana yang akan digunakan.

Di mesin host:

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

dan sintaks lain (dalam lingkungan chroot):

  mount -t proc none /proc

Mana yang harus saya gunakan, dan apa bedanya?


Waspadalah: memberikan akses ke perangkat disk berarti Anda kehilangan beberapa manfaat ' chroot()'. Secara khusus, yang ditentukan dapat membaca file di luar bagian mereka dari sistem file jika Anda tidak hati-hati.
Jonathan Leffler

2
@ Jonathan Leffler: itu tidak terdengar seperti masalah untuk apa yang dia lakukan.
Zifre

@JonathanLeffler, pengguna root di chroot selalu bisa lolos dari chroot.
LtWorf

Jawaban:


43

Untuk /procdan /sys, saya kira Anda bisa menggunakan metode mana pun. Keduanya adalah sistem file khusus sehingga dapat dibuat ulang beberapa kali (metode bind mount menggunakan mount yang sama persis dengan sistem host, sedangkan metode lainnya menggunakan mount baru). Saya selalu melihat bind mount yang direkomendasikan dalam panduan, jadi saya akan menggunakannya. Sejauh yang saya tahu, tidak ada perbedaan yang sangat penting.

Namun, /devbiasanya tmpfs mount yang dikelola oleh udev, jadi itu harus sistem file yang sama seperti pada mesin host. Itu berarti bahwa Anda perlu menggunakan metode bind mount.

Jika chroot ini akan ada untuk sementara, Anda dapat memasukkan entri ini /etc/fstabpada sistem host untuk menyederhanakan banyak hal.


Saya ingin bertanya apakah masuk akal untuk menyalin (mengikat) proc / sys dari host ke mesin lain? Mengapa mereka harus cocok dengan mesin itu?
ransh

@ transh masuk akal jika Anda mengikat / proc ke $ chrootdir / proc, Anda akan memiliki kemungkinan untuk menangani proses dan apa yang terjadi di dalam / proc dari kedua sistem dari kedua sistem; misalnya: dari chroot Anda dapat memeriksa apakah suatu program berjalan pada host ... dll
Jonah

Mungkin sys typesistem file muncul ( hari ini ) tidak ada lagi?
174140

111

The Arch Linux Wiki menunjukkan perintah berikut:

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
Mereka juga sepertinya bekerja untuk saya di ubuntu.
isaaclw

4
Dalam kasus saya (juga Ubuntu) saya membutuhkan "mount -o bind / dev / pts dev / pts" juga.
Thomas

Harap sertakan tautan ke sumbernya.
terbang styrofoam

@styrofoamfly Ditambahkan.
gacrux

1
Pada 2019, wiki ArchLinux sekarang berfungsi --rbinduntuk sysdan dev.
Saad Malik

12

The Buku Panduan Gentoo khusus memanggil kedua perintah untuk re-mount / proc dan / dev. Saya sudah menggunakannya beberapa kali.

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

Saya curiga / sys hanya folder biasa, jadi Anda harus dapat membuat tautan keras.

ln /sys /mnt/chroot/sys

17
Anda tidak dapat memasang tautan ke direktori (biasanya) seperti yang Anda sarankan untuk / sys, dan jika Anda menggunakan symlink, tautan itu akan rusak begitu Anda melakukan chroot.

Mereka telah menambahkan beberapa yang baru, berdasarkan systemd. Mungkin ide yang bagus untuk menambahkannya.
AzP

1

Mungkin perlu diperhatikan dalam pertanyaan populer ini, bahwa Arch Linux telah membuat script arch-chroot ; unduharch-install-scripts-15-1-any.pkg.tar.xz

Ini yang menangani berbagai masalah terkait baik di Arch-Linux dan Manjaro , di mana saya berhasil menggunakannya juga. Mungkin lebih banyak Arch Turunan seperti Parabola juga kompatibel.

Sementara standar sederhana chrootke instalasi Manjaro sekunder tidak akan memungkinkan Anda untuk menjalankan

pacman --sync linux

(Peluru perak setelah sistem crash), mengganti garis dengan

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

akan memungkinkan Anda untuk memperbaiki instalasi Arch-derivate sekunder Anda via

pacman --sync linux

seperti pesona. Skrip bash arch-chrootmenangani /dev /sys /procdan masih banyak lagi, yang dibiarkan sendiri oleh standar chroot.

lihat juga: Menggunakan arch-chroot


-1

Ada sistem file pseudo dan lokasi tmpfs lainnya. Ini di debian:

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

Seharusnya tidak apa-apa untuk memasang usbfs, rpc_pipefsdan devptspseudo-filesystems dari dalam chroot. Saya merekomendasikan untuk tidak mengikat /procchroot /proc, karena kernel memiliki konsep namespaces, dan sebenarnya dapat meletakkan hal-hal yang berbeda di proc chroot.

Pembaruan: menurut utas milis ini , / sys tidak boleh di-mount, terutama jika proses chroot menggunakan namespace jaringan sendiri.

Merupakan ide yang buruk untuk memasang sistem /varatau /runke chroot, jika chroot memiliki namespace pid sendiri.


Spekulasi? Pada superuser (dan forum tumpukan lainnya) biasanya lebih baik untuk menunda, atau riset dan jawab dengan sumber tertaut, jika Anda tidak yakin. Ini untuk menghindari risiko menyebarkan petunjuk yang salah arah. Maaf jika mengecewakan dan semoga berhasil!
Simon B.

@SimonB. Saya telah menambahkan tautan ke milis yang mendukung gagasan bahwa / sys tidak boleh di-mount.
Brian Minton

Dengan pid namespace, Anda berbicara tentang fitur namespace pengguna yang lebih canggih yang dapat kita temukan di kernel linux modern (yaitu berdasarkan "wadah" fitur), sementara ketika kita menggunakan istilah chroot, kita merujuk pada perubahan namespace file tradisional ( dan tidak ada lagi).
Johan Boulé

-1

Cara termudah adalah menggunakan for for:

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.