Wiederherstellen eines XFS-Dateisystems mit `ftype = 1`

1900
jjlin

Ich habe ein CentOS 7-System, bei dem das Stammdateisystem XFS ist (erstellt mit ftype=0der Standardeinstellung von CentOS zum Zeitpunkt der Installation des Systems). Leider overlay2erfordert der Docker- Speichertreiber, dass das Dateisystem erstellt wurde mit ftype=1:

https://docs.docker.com/storage/storagedriver/overlayfs-driver/#prerequisites

Jetzt möchte ich die Wurzel-FS mit neu erstellen ftype=1. Ich dachte daran, das wie folgt zu tun:

  1. Booten Sie in eine Art Rettungsbild.
  2. xfsdump das Root-FS an einen entfernten Ort.
  3. Erstellen Sie die Root-FS mit ftype=1.
  4. xfsrestore das Root-FS aus dem Remote-Dump.

Ich bin mir jedoch nicht sicher, ob die xfsdumpAusgabe etwas mit der ftypeEinstellung zu tun hat . Gibt es also Probleme mit xfsrestoreeinem XFS-Dateisystem mit einer anderen ftypeEinstellung?

Oder gibt es einen besseren Ansatz, um dieses spezifische Problem zu lösen (das bedeutet nicht, das gesamte System neu zu installieren, neu zu partitionieren usw.)?

3

1 Antwort auf die Frage

4
jjlin

Meine vorgeschlagene Methode schien gut zu funktionieren. Hier ist mein Verfahren:

  1. Starten Sie in CentOS-7-x86_64-LiveGNOME-1804.iso.
  2. Öffnen Sie ein Terminal und sudo -s.
  3. Scannen Sie nach LVM-Volumes: vgscan
  4. In die entsprechende Volumengruppe wechseln ( centosin meinem Fall):vgchange -ay centos
  5. Suchen Sie nach den logischen Volumes in dieser Gruppe: lvscan
  6. Erstellen Sie einen Einhängepunkt für das Root-FS: mkdir /mnt/root
  7. Hängen Sie den logischen Datenträger ein, der dem Stamm-FS entspricht: mount /dev/centos/root /mnt/root
  8. Auf Remote-Host ausgeben: xfsdump -J - /mnt/root | ssh <host> 'cat >/data/rootfs.dump'
  9. Hängen Sie die Root-FS ab: umount /mnt/root
  10. Erstellen Sie den Stamm-FS neu: mkfs.xfs -f -n ftype=1 /dev/centos/root
  11. Mounten Sie die neu erstellte Wurzel FS: mount /dev/centos/root /mnt/root
  12. Wiederherstellen von Remote-Host: ssh <host> 'cat /data/rootfs.dump' | xfsrestore -J - /mnt/root
  13. Starten Sie neu. Alles sollte so sein, wie es vorher war, aber xfs_info /jetzt zeigen ftype=1.

Hinweis: Mein xfsdumpAnruf hat zu einer Reihe von Warnungen auf dem Formular geführt

xfsdump: WARNING: failed to get bulkstat information for inode 10485897

Laut jemandem, der ein XFS-Entwickler zu sein scheint ( http://xfs.9218.n7.nabble.com/xfs-and-lvm-snapshots-td1241.html ):

Sie können ignoriert werden. Hierbei handelt es sich um Inodes, die zuvor nicht verknüpft waren, sich jedoch noch teilweise auf dem Snapshot-Volume befinden und für die By-Handle-Interfaces sichtbar sind, die xfsdump zum Extrahieren aller Inodes im Snapshot verwendet.

Vergessen Sie nicht, Ihre Dracut initramfs und / oder GRUB config auf UUID-Referenzen zu überprüfen: `mkfs.xfs` generiert eine neue UUID, und grub / initramfs kann diese mit der alten Referenz nicht finden. Bei Bedarf umbauen! Alex Mazzariol vor 5 Jahren 1
@AlexMazzariol Ich bin nicht auf dieses Thema gestoßen, und ich bin neugierig warum. Ist deine Installation ziemlich Standard? Jedenfalls denke ich, dass es eine gute Idee sein kann, [`xfs_admin] (https://linux.die.net/man/8/xfs_admin) zu verwenden, um die UUID (` -u`) zu erhalten, bevor sie neu erstellt wird , setzen Sie (UUID) die UUID im wiederhergestellten FS auf das Original zurück. jjlin vor 5 Jahren 0
Ja, sowohl bei LVM als auch bei der einfachen Partitionierung und bei einfacher CentOS-Installation. In beiden Fällen werden die Partitionen unter "/ etc / fstab" durch UUID identifiziert, und Dracut erkennt den Stamm nach "mkfs.xfs" nicht. Wenn LVM nicht verwendet wird, hat GRUB die alten UUIDs als `root =` an den Kernel übergeben. Kann gelöst werden, indem Sie grub-options und dracut neu erstellen oder, wie Sie gesagt haben, die vorherige UUID mit `xfs_admin` wiederherstellen. Alex Mazzariol vor 5 Jahren 0

Verwandte Probleme