Manakah dari proc, sys dll. Yang harus diikat-mount (atau tidak) ketika chroot menjadi distribusi "pengganti"?


9

Jawaban untuk pertanyaan lain ini pada dasarnya bermuara pada chrootdistribusi Linux lain untuk menggunakannya terutama sebagai pengganti induknya yang terlalu terbatas (tapi tak tergantikan). Tindakan yang disarankan sebelum menjalankan chroot, yang ingin saya pahami lebih baik, adalah:

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
  • Menyalin resolv.confjelas (akses jaringan / internet), sementara saya tidak yakin tentang modules- ini sebenarnya tidak perlu ketika chrootmasuk ke sistem stage3 Gentoo, kan?
  • Tapi mengapa proc, sysdan dev/ptsremounted daripada menggunakan bind-mount? Apa perbedaan sebenarnya dalam situasi ini, yang "lebih benar"?
  • HowTo ini mengikat procdan terpasang dev, tetapi tidak dev/ptsjuga systidak dipasang sama sekali. Selain itu menyalin /etc/{hosts,fstab}ke root baru. Apakah itu masuk akal? Tidakkah seharusnya saya memasukkannya /etc/mdadm.confjuga?

1
Itu harus sebagian besar identik; pertimbangkan filesystem reguler: mereka tidak harus di-mount dua kali (kecuali mereka sadar cluster) namun kernel melakukan hal itu; jadi itu pada dasarnya ditangani seperti bind mount secara internal.
frostschutz

Jawaban:


9

/etc/resolv.conf disalin agar tidak kehilangan DNSs.

/ lib / modules disalin karena karena itu mungkin perlu menggunakan beberapa komponen perangkat keras yang tidak perlu ada pada saat pengaturan chroot. Anda harus ingat bahwa pertanyaan awal yang Anda rujuk dalam OP Anda menyangkut penggantian NAS OS dengan Arch Linux. Dengan demikian Anda memerlukan driver untuk ethernet, mungkin nirkabel, berbagai komponen USB, dan sebagainya. Menyalin folder / lib / modules memastikan bahwa lingkungan baru akan dapat mengatasi tugas-tugasnya di masa depan.

Anda memang benar tentang pemasangan ulang vs pemasangan bind. Halaman Arch Linux Wiki pada chroot memang menggunakan re-mount dan bind-mount seperti yang Anda tentukan, sesuai jawaban untuk posting yang Anda lihat:

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

(Saya pikir ini menunjukkan sintaks dari baris Anda, disalin dari posting ini , salah: dev yang akan dipasang mendahului titik mount).

Namun, halaman manual Ubuntu pada chroot menceritakan kisah yang berbeda:

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

Di sini / proc sudah di-bind-mount, bukan di-mount kembali.

Saya sebenarnya sudah mencoba kedua hal itu, dan setelah tes singkat, saya tidak dapat melihat perbedaan apa pun. Tidak banyak tes, diakui, dan dengan demikian saya akan mengistirahatkan kasus saya di sini bahwa itu seharusnya tidak membuat banyak perbedaan.


6
  • /etc/resolv.conf- Anda memerlukan file ini untuk menyelesaikan permintaan DNS. Itu tidak perlu dalam beberapa keadaan:

    1. klien DHCP tersedia di chroot, itu dijalankan dan server DHCP mengembalikan informasi yang sesuai (yang biasanya terjadi).

    2. Anda tidak tertarik pada jaringan (atau lebih tepatnya membuat permintaan DNS dari aplikasi biasa yang mengandalkan /etc/resolv.conf) dari dalam chroot.

  • /lib/modules/$(uname -r)- Masuk akal jika Anda mungkin perlu memuat modul tambahan untuk kernel aktif. Tanpa ini, Anda akan terjebak dengan apa pun yang sedang berjalan. Karenanya, jika Anda bermaksud untuk menjalankan sistem chroot untuk waktu yang lebih lama, Anda mungkin harus melakukannya. Di sisi lain, dalam hal demikian Anda mungkin harus menggunakan pivot_rootsebagai gantinya (yang biasanya dilakukan initrd di akhir masa pakainya). Jika Anda hanya perlu melakukannya misalnya menginstal bootloader dari chroot, itu tidak perlu (karena semua driver yang diperlukan harus dimuat agar Anda dapat melakukan chroot itu sendiri).

  • /procdan /devagak jelas - ini berisi antarmuka sistem dasar.

  • /sysadalah IIRC tidak yang banyak digunakan kembali pada tahun 2007 yang adalah apa yang Slackware (yang sendiri agak konservatif) Bagaimana-untuk tanggal. Saat ini sistem Anda mungkin gagal entah bagaimana tanpanya (misalnya sekali ada sesuatu yang mencoba menghitung beberapa jenis perangkat keras).

  • /dev/pts- selama bertahun-tahun ada beberapa perubahan pada cara /devpenanganan pohon. Di beberapa titik perangkat di /dev/ptsditangani oleh devfs- lihat misalnya utas LKML ini untuk diskusi tentang kemungkinan masalah.

  • bind mounting - ada beberapa aspek menarik dari bind mounts (agak dijelaskan dengan baik di mount(8)halaman manual). Misalnya jika Anda memiliki:

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

    dan kemudian remount /x/ahanya-baca, Anda tidak akan dapat mengubah apa pun /x/B. Yang bisa dimengerti, tetapi mungkin mengejutkan Anda untuk pertama kalinya. Pertanyaan bagus lainnya adalah apa yang harus terjadi dengan /x/bcontoh di atas ketika Anda umount /x/a. Bagi saya itu jauh dari jelas, bahwa Anda masih dapat mengakses pohon di bawahnya. Oleh karena itu pemasangan bind dapat menjadi rumit. Secara fungsional, ketika digunakan pada seluruh sistem file, itu sama.

  • hal-hal lain dari /etc/- itu pasti masuk akal untuk menyalin konfigurasi yang relevan yang berguna. Menyalin misalnya /etc/passwd, /etc/shadow, /etc/groups mungkin masuk akal, serta kunci server untuk sshd.


Kedua jawaban itu kira-kira sama bagusnya - jadi saya melempar koin mana yang harus saya terima ...
Tobias Kienzler

0

/procmengelola proses dan sysmengubah parameter kernel atau mengakses info dari kernel saat ini.

Sekarang, dengan mempertimbangkan bahwa mengikat menyiratkan sifat dua arah, proctidak boleh dipasang di luar chroot sebagai solusi terbaik.

sysbisa saja, tetapi ini bergantung pada host kernel yang sedang berjalan, dan harus sama dengan dev, di-mount sebagai bind.

/dev/ptssudah tersedia seperti /devbind-mount, tetapi merupakan bagian dari chroot, jadi remounting yang baru ptsdirekomendasikan sebagai mount -t devpts none /mnt/drive/dev/pts.

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.