Unterschied zwischen chroot switch_root u. pivot_root

[KBDCALLS]

Was sind die Unterschiede zwischen obegenannten chroot switch_root u. pivot_root ?

Bei switch_root läßt einen daß hier zurückschrecken.

• Code: Alles auswählen

  WARNUNG: switch_root  entfernt  rekursiv  alle  Dateien  und  Verzeichnisse  im  aktuellen
         Wurzeldateisystem.
  

Aber irgend wie ergibt das wenig Sinn , wenn das Urprungssystem unbrauchbar wird. Dann frage ich mich mal wofür das gut sein soll ?

[MSfree]

Bei switch_root läßt einen daß hier zurückschrecken.

Das hier dürfte als Blutdrucksenker helfen:
https://manpages.ubuntu.com/manpages/fo ... oot.8.html

switch_root wird, soweit ich das aus meiner LFS-Zeit in Erinnerung habe, beim Booten genutzt, um das provisorische /-Filesystem, das am Anfang des Bootprozeßes auf die initrd zeigt, später durch das /-Dateisystem zu ersetzen, das sich auf der HDD/SSD befindet.

Da wird auch nichts physikalisch entfernt. Da aber Dateien, die in der initrd liegen, nach dem Switch nicht mehr im Dateisystem vorhanden sind, sind sie defacto entfernt.

pivot_root ist mir bisher nicht über den Weg gelaufen.

[Meillo]

pivot_root habe ich selbst auch noch nicht genutzt, aber man vertauscht damit quasi die Hierarchie der Dateisysteme. Du hast ein Root-Filesystem in dem du unter /mnt ein anderes Root-Filesystem gemountet hast, um an dem zu bauen. Wenn du nun ein `chroot /mnt' machst, dann bist du im untergeordneten Dateisystem hast aber keinen Zugriff mehr auf das urspruengliche Root-Filesystem. Mit pivot_root hast du danach das ursprungliche Dateisystem z.B. unter /mnt gemountet. Du vertauschst also die beiden Dateisysteme.

Die Manpage pivot_root(2) erklaert mehr als pivot_root(8).

pivot_root() moves the root file system of the calling
process to the directory put_old and makes new_root the
new root file system of the calling process.

The typical use of pivot_root() is during system startup,
when the system mounts a temporary root file system
(e.g., an initrd), then mounts the real root file system,
and eventually turns the latter into the current root of
all relevant processes or threads.

An sich koennte man mit chroot und mount das auch umsetzen. Ich denke, der Grund, dass es pivot_root als Systemcall gibt, liegt daran, dass es im Hintergrund noch magisch in den Prozessen rumfummelt und Working Directories aendert.


Nachtrag:
Zu beachten ist, dass es alle drei Befehle als Admin-Kommandos gibt, zudem chroot(2) und pivot_root(2) auch als Systemcall, switch_root aber nicht.

[Livingston]

Der wesentliche Unterschied ist, dass einem switch_root gegenüber dem veralteten pivot_root viel Arbeit abnimmt und Fehlerquellen eliminiert.

Für pivot_root muss man drauf achten, alles an die richtigen Stellen gemountet zu haben, muss dann nach Ausführung noch ein chroot per exec ausführen, damit man auch die Shell mitnimmt und führt dadurch ein neuen Shell-Script aus, dass den alten initrd-Kram unmountet, sich von den Filedescriptoren stdin, stdout und stderr befreit, den Puffer des nicht mehr benötigten ram-devices per blockdev leert, um dann endlich ein exec auf init auszuführen.

Bei switch_root geschieht das alles in einem Rutsch. Dabei werden dann sauber alle Reste des initramfs entsorgt.

[KBDCALLS]

Hier https://unix.stackexchange.com/questio ... witch-root habe ich noch was zu dem Thema pivot_root vs. switch_root gefunden.

[Meillo]

Hier https://unix.stackexchange.com/questio ... witch-root habe ich noch was zu dem Thema pivot_root vs. switch_root gefunden.

Danke. Das war interessant zu lesen.

[Livingston]

Hier mal das Ende einer selbstgebastelten initrd mit pivot_root:

Code: Alles auswählen

...
# Vorher wurden Module geladen, LUKS-Passwort abgefragt und LVM gestartet
...
cd mnt				# Hierhin habe ich das Gerät gemountet, das "/" beherbergen soll
pivot_root . mnt		# Der eigentliche Wechsel des Root-Verzeichnisses
exec chroot . /bin/bash -c \	# Die Shell soll den Wechsel auch mitbekommen
"/bin/umount /mnt; \		# Der Mount-Point wurde ausgetauscht, /mnt wird nicht mehr gebraucht
				# Der alte initrd-Mechanismus benutzt ram-Devices -> das ungenutzte Gerät wird geleert:
/sbin/blockdev --flushbufs /dev/ram0; \
				# /sbin/init des Hauptsystems ersetzt vollständig den init-Prozess aus initrd.
				# Außerdem werden alle Brücken zur alten console abgerissen und neu belegt
				# und die vorher gesicherten Kernelparameter an init übergeben:
exec /sbin/init ${CMDLINE}" <dev/console >dev/console 2>&1

Ab der Zeile exec chroot . /bin/bash -c wird auf die Binaries und Verzeichnisse des Hauptsystems zurückgegriffen, nicht mehr auf Programme von initrd. ${CMDLINE} wird expandiert bevor dieser finale Wechsel stattfindet.

Nicht sehr elegant. Der neue Mechanismus für initramfs und switch_root nimmt einem das ganze Geraffel ab.
Diesen Code-Schnippsel habe ich übrigens vor ca. 15 Jahren nur für meine Privatforschung geschrieben. Produktiv würde ich den nicht einsetzen.