2010-07-18 19:06:10 +0000 2010-07-18 19:06:10 +0000
92
92

mount dev, proc, sys w środowisku chroot?

Próbuję stworzyć obraz Linuksa z wybranymi pakietami.
To, co staram się zrobić, to ręcznie wykonać pakiety, których zamierzam użyć na laptopie XO, ponieważ kompilacja pakietów trwa naprawdę długo na prawdziwym sprzęcie XO, jeśli mogę zbudować wszystkie pakiety, których potrzebuję i po prostu błysnąć obrazem do XO, mogę zaoszczędzić czas i miejsce.

Kiedy próbowałem zainstalować kilka pakietów, nie udało mi się skonfigurować z powodu braku katalogów proc, sys, dev. Tak więc, dowiedziałem się z innych miejsc, że muszę “zamontować” hosta proc, … katalogi do mojego środowiska chroot.

Widziałem dwie składnie i nie jestem pewien, który z nich użyć.

W hosta maszyny:

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

i innej składni (w środowisku chroot):

mount -t proc none /proc

Który z nich należy użyć, i jaka jest różnica?

Odpowiedzi (6)

118
118
118
2012-04-26 06:10:11 +0000

Arch Linux Wiki sugeruje następujące komendy:

cd /mnt/arch # or where you are preparing the chroot dir
mount -t proc proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/
45
45
45
2010-07-19 01:02:06 +0000

Dla /proc i /sys, przypuszczam, że możesz użyć każdej z tych metod. Obydwie są specjalnymi systemami plików, więc mogą być odtwarzane dowolną ilość razy (metoda bind mount używa dokładnie tego samego montowania co system nadrzędny, podczas gdy druga metoda używa nowego montowania). Zawsze widziałem montowanie wiązań zalecane w przewodnikach, więc użyłbym tego. Z tego co wiem, nie ma żadnej istotnej różnicy.

Jednakże, /dev jest zazwyczaj montowaniem tmpfs, które jest zarządzane przez udev, więc musi to być ten sam system plików, co na komputerze głównym. Oznacza to, że trzeba będzie użyć metody montażu wiązania.

Jeśli ten chroot będzie przez jakiś czas, można umieścić te wpisy w /etc/fstab na systemie hosta, aby uprościć rzeczy.

13
13
13
2010-07-19 00:05:08 +0000

Podręcznik Gentoo Handbook specjalnie wywołuje te dwie komendy w celu ponownego zamontowania /proc i /dev. Używałem ich kilka razy.

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

Podejrzewam, że /sys to tylko zwykły folder, więc powinieneś być w stanie zrobić twardy link.

ln /sys /mnt/chroot/sys
1
1
1
2016-04-17 15:36:51 +0000

Warto w tym popularnym pytaniu zaznaczyć, że Arch Linux wykonał skrypt arch-chroot ; pobierz arch-install-scripts-15-1-any.pkg.tar.xz

Ten, który zajmuje się różnymi związanymi z tym problemami zarówno w Arch-Linux jak i Manjaro , gdzie również z powodzeniem go wykorzystałem. Ewentualnie więcej Arch- divates jak Parabola są kompatybilne równie dobrze.

Podczas gdy prosty standardowy chroot w drugorzędnej instalacji Manjaro nie pozwoli Ci uruchomić

pacman --sync linux

(srebrny pocisk po awarii systemu), zastąpienie linii

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

pozwoli Ci naprawić drugorzędną instalację Arch-derivate przez

pacman --sync linux

jak urok. Skrypt bash arch-chroot zajmuje się /dev /sys /proc i wiele innych, które są pozostawione same sobie przez standardowy chroot.

patrz również: Użycie arch-chroot

-1
-1
-1
2019-01-20 13:32:32 +0000

Najprostszym sposobem jest użycie pętli:

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
-1
-1
-1
2012-10-15 21:06:00 +0000

Istnieją inne pseudo systemy plików i lokalizacje tmpfs. To jest na debianie:

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

Powinno być w porządku montowanie pseudo-systemów plików usbfs, rpc_pipefs i devpts z wnętrza chroota. Rekomenduję nie wiązanie /proc z /proc chroot, ponieważ jądro ma koncepcję przestrzeni nazw, i może faktycznie umieścić różne rzeczy w proc chroot.

Update: zgodnie z tym wątkiem listy mailingowej , /sys nie powinien być montowany w powiązaniu, szczególnie jeśli chrootowane procesy używają własnej sieciowej przestrzeni nazw.

To zły pomysł, aby zamontować systemowe /var lub /run na chroot, jeśli chroot ma własną przestrzeń nazw pid.