Kiedy użyjesz pivot_root zamiast switch_root?


19

Chcę lepiej zrozumieć proces inicjowania Linuksa, aby móc uruchomić system za pomocą ceph zamiast NFS.

W trakcie tego procesu natknąłem się na dwie formy przełączania roota. Jeden o nazwie switch_root, a drugi o nazwie pivot_root. Skrypty te są uruchamiane z systemu plików w pamięci (initramfs) uzyskanego przez tftp przy użyciu procesu rozruchu pxe.

Kiedy użyjesz jednego nad drugim? Widziałem oba używane w niektórych skryptach inicjujących umieszczonych w katalogu głównym.

Odpowiedzi:


16

Znalazłem wspaniałą wyjaśnienie tutaj . Pozwólcie jednak, że spróbuję wprowadzić krótszy format tego, co zrozumiałem w odpowiedzi.

Krótsza wersja

  1. Podczas uruchamiania systemu potrzebuje wczesnej przestrzeni użytkownika. Można to osiągnąć za pomocą initramfs lub initrd.
  2. initrd jest ładowany do ramdysku, który jest rzeczywistym SYSTEMEM PLIKÓW .
  3. initramfs jest nie system plików .
  4. Dla initrd pivot_root jest używany, a dla initramfs switch_root jest używany.

Dłuższa wersja

A teraz szczegółowe wyjaśnienie tego, co przedstawiłem powyżej.

Chociaż zarówno initramfs, jak i initrd służą temu samemu celowi, istnieją 2 różnice. Najbardziej oczywistą różnicą jest to, że initrd jest ładowany do ramdysku. Składa się z rzeczywistego systemu plików (zazwyczaj ext2), który jest zamontowany na ramdysku. Z drugiej strony initramfs nie jest systemem plików. Jest to po prostu (skompresowane) archiwum cpio (typu newc), które jest rozpakowywane w tmpfs. Ma to efekt uboczny polegający na tym, że initramfs jest nieco bardziej zoptymalizowany i może ładować się trochę wcześniej w procesie rozruchu jądra niż initrd. Ponadto rozmiar initramfs w pamięci jest mniejszy, ponieważ jądro może dostosować rozmiar tmpfs do tego, co jest faktycznie załadowane, zamiast polegać na predefiniowanych rozmiarach ramdysku,

Istnieje również inna różnica w skutkach ubocznych: sposób obsługi urządzenia root (i przełączania się na nie). Ponieważ initrd to rzeczywisty system plików rozpakowany w pamięci RAM, urządzeniem głównym musi być tak naprawdę ramdysk. W przypadku initramfs istnieje jądro „rootfs”, które staje się tmpfs, do którego jest rozpakowywany initramfs (jeśli jądro ładuje initramfs; jeśli nie, to rootfs to po prostu system plików określony za pomocą parametru bootowania root = jądro), ale Tymczasowych plików rootf nie należy określać jako parametru root = boot (i nie byłoby na to sposobu, ponieważ nie jest do niego podłączone żadne urządzenie). Oznacza to, że nadal możesz przekazać swoje prawdziwe urządzenie root do jądra podczas korzystania z initramfs. Za pomocą initrd musisz przetworzyć to, czym jest prawdziwe urządzenie root. Ponadto, ponieważ „prawdziwy” urządzeniem root z initrd jest ramdysk, jądro musi naprawdę przełączać urządzenia root z jednego urządzenia rzeczywistego (ramdysk) na drugie (twój prawdziwy root). W przypadku initramfs przestrzeń initramfs (tmpfs) nie jest prawdziwym urządzeniem, więc jądro nie przełącza rzeczywistych urządzeń. Tak więc, podczas gdy komenda pivot_root jest używana z initrd, dla initramfs należy użyć innej komendy. Busybox zapewnia switch_root, aby to osiągnąć, a klibc oferuje new_root. dla initramfs należy użyć innego polecenia. Busybox zapewnia switch_root, aby to osiągnąć, a klibc oferuje new_root. dla initramfs należy użyć innego polecenia. Busybox zapewnia switch_root, aby to osiągnąć, a klibc oferuje new_root.


2
pivot_rootW przeszłości używałem initramfs, switch_rootwtedy nie istniało. switch_rootwydaje się być metoda wygoda pivot_rootktóry robi trochę więcej porządki i również ruchy /proc /sysi /devetc, a nie tylko samego korzenia
Daniel Alder

2
Nie możesz używać pivot_root na rootfsach initramfs, otrzymasz nieprawidłowy argument. Można obracać tylko prawdziwe systemy plików.
TiCPU,

@ TiCPU W takim razie, w jaki sposób Linux opuściłby przestrzeń wczesnego użytkownika?
Melab

Podane rozwiązanie wydaje się nieprawidłowe. Sam Linus mówi, że pivot_root () lub chroot () po prostu zmieni bieżące odwołanie do procesów /. Z mojego zrozumienia może to być dowolna ścieżka i nie ma ona nic wspólnego z rzeczywistymi „dyskami”.
erikbwork

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.