Warum stellt initramfs das Root-Dateisystem schreibgeschützt bereit?


12

Was ist der Grund dafür, dass das Root-Dateisystem roin initramfs (und in initrd) gemountet wird?

Im Gentoo initramfs-Handbuch wird beispielsweise das Root-Dateisystem mit folgenden Elementen bereitgestellt:

mount -o ro /dev/sda1 /mnt/root

Warum nicht das Folgende?

mount -o rw /dev/sda1 /mnt/root

Ich kann sehen, dass es wahrscheinlich einen guten Grund gibt (und es geht wahrscheinlich darum switchroot), aber es scheint nirgendwo dokumentiert zu sein.

Antworten:


19

Die anfängliche Ramdisk (initrd) ist normalerweise eine abgespeckte Version des Root-Dateisystems, die nur das enthält, was zum Mounten des eigentlichen Root-Dateisystems und zum Übergeben des Bootens erforderlich ist.

Die initrd existiert, weil in modernen Systemen der Bootloader nicht intelligent genug gemacht werden kann, um das Root-Dateisystem zuverlässig zu finden. Es gibt einfach zu viele Möglichkeiten für ein so kleines Programm wie den Bootloader. Berücksichtigen Sie NFS-Root, nicht standardmäßige RAID-Karten usw. Der Bootloader muss seine Arbeit nur mit dem BIOS und dem Code erledigen, der in den Bootsektor gepackt werden kann.

Die initrd wird an einem Ort gespeichert, den der Bootloader finden kann , und sie ist klein genug, damit der zusätzliche Speicherplatz normalerweise niemanden stört. (In kleinen eingebetteten Systemen gibt es normalerweise keine "echte" Wurzel, nur die initrd.)

Die initrd ist wertvoll: Ihr Inhalt muss unter allen Bedingungen erhalten bleiben, denn wenn die initrd kaputt geht, kann das System nicht booten. Eine Designentscheidung, die die Designer getroffen haben, um dies sicherzustellen, besteht darin, dass der Bootloader das initrd schreibgeschützt lädt. Es gibt auch andere Prinzipien, die darauf hinarbeiten, wie zum Beispiel bei kleinen Systemen, bei denen es keine "echte" Wurzel gibt, die Sie immer noch separat bereitstellen /tmp, /var/cacheund solche zum Speichern von Dingen. Das Ändern der initrd wird nur selten durchgeführt und sollte dann sehr sorgfältig durchgeführt werden.

Kommen sie zurück zu dem normalen Fall , wo es ist ein echtes Root - Dateisystem, wird es zunächst angebracht schreibgeschützt , da initrd war. Es wird dann aus den gleichen Gründen so lange wie möglich schreibgeschützt gehalten. Jegliches Schreiben in das eigentliche Stammverzeichnis, das durchgeführt werden muss, wird verschoben, bis das System vorzugsweise hochgefahren wird, oder zumindest bis spät im Startvorgang, wenn diese Voreinstellung nicht erfüllt werden kann.

Das Wichtigste in dieser schreibgeschützten Phase ist, dass das Root-Dateisystem überprüft wird, um festzustellen, ob es ordnungsgemäß bereitgestellt wurde. Das könnte der Bootloader sicherlich tun, anstatt es der initrd zu überlassen, aber was passiert dann, wenn das Root-Dateisystem nicht sauber abgemeldet wurde? Dann muss es anrufen fsck, um es zu überprüfen und möglicherweise zu beheben. Also, wo würde es initrdherkommen fsck, wenn es für diesen Schritt verantwortlich wäre , anstatt auf die Übergabe an die "echte" Wurzel zu warten? Man könnte sagen, dass Sie beim Erstellen fsckin das kopieren müssen initrd, aber jetzt ist es größer. Und obendrein, welche fsck werden Sie kopieren? Linux-Systeme verwenden regelmäßig etwa ein Dutzend verschiedene Dateisysteme. Kopieren Sie nur diejenige, die zum Zeitpunkt desinitrdgeschaffen? Erhöhen Sie die Größe, initrdindem Sie alle verfügbaren fsck.fooProgramme in das Programm kopieren , falls das Root-Dateisystem später auf einen anderen Dateisystemtyp migriert wird und jemand vergisst, die initrd neu zu erstellen?

Die Architekten des Linux-Boot-Systems haben sich mit Bedacht dafür entschieden, den initrd nicht mit diesen Problemen zu belasten. Sie haben die Überprüfung des realen Root-Dateisystems an das reale Root-Dateisystem delegiert, da dies besser möglich ist als die initrd.

Sobald der Startvorgang so weit fortgeschritten ist, dass dies sicher möglich ist, wird die initrd unter dem realen Stamm mit ausgetauscht pivot_root(8), und das Dateisystem wird im Lese- / Schreibmodus erneut bereitgestellt.


4
Das initramfs ist nicht schreibgeschützt gemountet. Der Kernel entpackt es in ein Lese- / Schreib-tmpfs, das als / gemountet ist. Auch pivot_root () wird in der jetzt veralteten initrd verwendet, jedoch nicht in einem initramfs, das die meisten Systeme heutzutage verwenden (obwohl die Datei immer noch initrd heißt). Mit der initrd fand pivot_root statt, bevor / sbin / init ausgeführt wurde, was zu fsck führte und r / w erneut bereitstellte. Bei einem initramfs werden nur alle Dateien im initramfs gelöscht, dann in das echte Stammverzeichnis und in execs / sbin / init chroots.
Psusi

0

Denn während des Startvorgangs ist das Root-Dateisystem zunächst immer schreibgeschützt. Sobald verschiedene Selbsttests abgeschlossen sind, wird das Root-Dateisystem erneut als Lese- / Schreibzugriff bereitgestellt und die anderen Dateisysteme werden bereitgestellt.


0

Ein Grund, über den ich nachdenken kann, ist die Verhinderung von Korruption. Beispielsweise können Sie das ext4-Dateisystem als ext2 bereitstellen (oder umgekehrt). Dies ist im Ro-Modus sicher, kann jedoch zu inkompatiblen Formatänderungen führen, wenn rw von initram bereitgestellt wird.

Oh, und es gibt noch einen weiteren Grund: initramfs hat wahrscheinlich kein fsck, aber Sie müssen möglicherweise das Dateisystem überprüfen, bevor Sie es rw mounten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.