☰

Nicht leere Einhängepunkte mit btrfs (SLES15): Werden diese benötigt?

tag-icon • tag-icon mount btrfs suse
Nicht leere Einhängepunkte mit btrfs (SLES15): Werden diese benötigt?

Ich habe viele Jahre Erfahrung mit UNIX, aber ich glaube, ich habe einen fatalen Fehler gemacht:

Als ich beim Booten Meldungen über nicht leere Einhängepunkte sah, nutzte ich die Gelegenheit, diese zu bereinigen, während ich ein System in eine neue Umgebung migrierte. Ich bootete das SLES-Rettungssystem, mountete das Root-Dateisystem und die grundlegende Systemstruktur (proc, sys, dev) auf und /mntführte dann chroot /mntund aus mount -va.

Damit alles gut aussieht, habe ich einige Konfigurationseinstellungen angepasst und beim Aushängen die Einhängepunkte überprüft. Beispiel: /var/cachewurde eingehängt, umountwar erfolgreich, ll /var/cachezeigte aber immer noch einen nicht leeren Einhängepunkt an, während das Dateisystem als nicht eingehängt angezeigt wurde. Also habe ich den Inhalt entfernt.

Grundsätzlich habe ich die Schritte für jedes gemountete Dateisystem wiederholt, dann die chrootUmgebung verlassen, den Rest ausgehängt und neu gestartet.

Leider lässt sich das System nicht starten, da GRUB eine Fehlermeldung anzeigt, dass es nicht gefunden werden kann normal.mod.

Handelt es sich hierbei also um eine Funktion von BTRFS-Subvolumes? Wer kann erklären, was da vor sich ging?

/etc/fstab

Wie von mir gewünscht /etc/fstab, weist ein typisches System Folgendes auf:

/dev/sys/root                              /            btrfs  defaults              0  0
/dev/sys/root                              /var         btrfs  subvol=/@/var         0  0
/dev/sys/root                              /usr/local   btrfs  subvol=/@/usr/local   0  0
/dev/sys/root                              /tmp         btrfs  subvol=/@/tmp         0  0
/dev/sys/root                              /srv         btrfs  subvol=/@/srv         0  0
/dev/sys/root                              /root        btrfs  subvol=/@/root        0  0
/dev/sys/root                              /opt         btrfs  subvol=/@/opt         0  0
UUID=9fd27493-d194-48ba-a4bc-3551123e0d3b  /home        xfs    defaults              0  0
/dev/sys/boot                              /boot        btrfs  defaults              0  0
UUID=0092-D1D5                             /boot/efi    vfat   utf8                  0  2
/dev/sys/root                              /.snapshots  btrfs  subvol=/@/.snapshots  0  0

Antwort1

So funktionierte es

/dev/sys/rootenthält ein Btrfs-Dateisystem. Mehrere Einträge in Ihrem fstabmounten verschiedene Subvolumes davon an verschiedenen Mountpunkten.

Hypothese: Das Standard-Subvolume im Btrfs-Dateisystem in /dev/sys/rootist /@und sobald es unter gemountet ist /, werden viele andere Subvolumes gemountetan ihren jeweiligen Einhängepunktenmacht wenig bis gar keinen Sinn, da die richtigen (und normalerweise nicht leeren) Verzeichnisse bereits dort sind, wo Sie sie erwarten.

(Um das Standarduntervolume anzuzeigen, führen Sie aus sudo btrfs subvolume get-default /.)

Bitte lesen Siedies ist eine weitere Antwort von mirund verstehen Sie den konzeptionellen Unterschied zwischen dem Btrfs-Verzeichnisbaum (und den Untervolumes) auf einem Gerät und der Verzeichnisstruktur in Ihrem Betriebssystem. Ohne dieses Wissen kann der Rest der aktuellen Antwort für Sie sehr verwirrend sein.

Wenn das Standard-Subvolume/@, /@aus dem Btrfs-Baum erscheint als /im OS-Baumzusammen mit allem darunterDiese Montageallein/@/varreicht es aus, z. B. das Verzeichnis aus dem Btrfs-Baum als /varim OS-Baum anzuzeigen . Ich meine, wenn Sie versuchen, darauf zuzugreifen/var Vor /varwird dann montiert

  • das Betriebssystem prüft, ob /var(vom Betriebssystem) ein Einhängepunkt ist; es ist nicht der Fall.
  • das Betriebssystem prüft also, ob /es sich um einen Einhängepunkt handelt. Dies ist der Fall und er ist mit /@dem Btrfs verknüpft.
  • Das Betriebssystem zeigt Ihnen also /@/vardas Btrfs als /varTeil des Betriebssystems an.

Es kommt vor, dass es sich /@/varbei Btrfs um ein Untervolume handelt.ZusätzlichBeim Mounten subvol=/@/varunter /var(des Betriebssystems) wird dasselbe Verzeichnis wie /var(des Betriebssystems) angezeigt. Insbesondere wenn Sie jetzt darauf zugreifen, /vardann

  • Das Betriebssystem prüft, ob /vares sich um einen Einhängepunkt handelt. Dies ist der Fall und er ist mit /@/vardem Btrfs verknüpft.
  • Das Betriebssystem zeigt Ihnen also /@/vardas Btrfs an.

Und wenn Sie /var(das Betriebssystem) aushängen, kehren Sie zum ersten Fall zurück.

Es spielt also keine Rolle, ob /var(das Betriebssystem) gemountet ist oder nicht (praktisch spielt es keine Rolle, es kann Feinheiten geben). Auf die eine oder andere Weise werden Sie /@/vardas Btrfs als /varim Betriebssystem sehen.

Mehrere andere Einträge in Ihrem fstabMount verschiedene Subvolumeswo man sie sowieso sehen würde. Ich verstehe den Sinn dieser Einträge nicht wirklich (der Sinn liegt vielleicht in irgendeiner Feinheit, die ich derzeit nicht erkennen kann, oder diese Einträge sind tatsächlich völlig sinnlos).

Zum Vergleich: Wenn /var(des Betriebssystems) mit gemountet wurde, subvol=/vardann würde das Mounten Sinn machen, weil /vardas Btrfs nicht unterhalb /@des Btrfs liegt und man es daher nicht erreichen kann, indem man /@das Btrfs einfach /vom Betriebssystem aus mountet.

Wie du es kaputt gemacht hast

… wurde gemountet, umountwar erfolgreich, ll …zeigte aber immer noch einen nicht leeren Mount-Punkt an, während das Dateisystem als nicht gemountet angezeigt wurde. Also habe ich den Inhalt entfernt.

Wie gesagt, mehrere Einträge in Ihrem fstabMount sind in verschiedenen Subvolumes vorhanden, wo Sie sie sowieso sehen würden. In diesen Fällen entfernen Sie den Inhalt, nachdem umountSie den Inhalt entfernt haben, den Sie zuvor gesehen haben umount. Sie dachten, Sie hätten verdeckte, irrelevante Inhalte entfernt, aber tatsächlich haben Sie die eigentlichen, wichtigen Inhalte entfernt.

Zwei Dinge passen allerdings nicht:

  1. Ihr Beispiel-Einhängepunkt ist , Sie haben ihn angeblich ausgehängt, aber in dem von Ihnen geposteten /var/cachesteht keins ./var/cachefstab
  2. Laut Ihrem fstabBeitrag /stammt (des Betriebssystems) von /dev/sys/root, während /boot(des Betriebssystems) von stammt /dev/sys/boot. Der beschriebene Mechanismus, Dinge kaputt zu machen, kann nicht angewendet werden. Dennoch behaupten Sie, dass „GRUB sich beschwert hat, dass es nicht finden kann normal.mod“, und daraus schließe ich, dass Sie die Dinge irgendwie kaputt gemacht haben /boot.

Deshalb vermute ich, dass das Veröffentlichte fstab(Sie haben es als „das, was ein typisches System hat“ beschrieben) nicht das ist,genau fstabdes betroffenen Betriebssystems. Ich vermute, /bootdass dort dasselbe Dateisystem wie verwendet wurde /, unnötigerweise gemountet war und daher anfällig für das beschriebene Szenario von Störungen war.

verwandte Informationen