Mounten Sie ein PV-Image als schreibgeschütztes Loop-Gerät (nochmals – früher hat es funktioniert)

Mounten Sie ein PV-Image als schreibgeschütztes Loop-Gerät (nochmals – früher hat es funktioniert)

Vor ein paar Jahren habe ich mein Netbook mit einer größeren Festplatte aufgerüstet. Ich wollte den Inhalt der alten Festplatte behalten, falls ich noch etwas davon haben wollte.

Also habe ich die Daten der alten Festplatte in eine Datei auf der neuen kopiert:

dd if=/dev/sdd5 of=~/fw-disk-image/fw-sdd5-linux-lvm-partition.raw

und ich habe ein Skript geschrieben/kopiert, um die LVMs auf dieser Partition als schreibgeschützte Dateisysteme zu mounten:

losetup -r /dev/loop1 ~/fw-disk-image/fw-sdd5-linux-lvm-partition.raw

pvscan
vgscan
vgchange -a y fw

cd /mnt/fw
for i in root tmp usr var home
  do
    mount -o ro /dev/fw/$i $i
  done

Nun hat das lange funktioniert und nun schlägt es plötzlich bei folgendem vgchange -a y fwBefehl fehl:

# vgchange -a y fw
  Error writing device /dev/loop1 at 4096 length 512.
  bcache_invalidate: block (4, 0) still dirty
  Failed to write mda header to /dev/loop1 fd -1
  Failed to update old PV extension headers in VG fw.
  Volume group "fw" not found
  Cannot process volume group fw

Ich vermute, dass vgchange nicht glücklich darüber ist, dass es nicht darauf schreiben kann, da ich ein schreibgeschütztes Loopback-Gerät erstellt habe. Ich denke, dass das Dateisystem bei der letzten Verwendung der Festplatte fehlerhaft war, aber das möchte ich ignorieren.

Auf meinem aktuellen System läuft derzeit:

Linux fw 4.19.0-8-686-pae #1 SMP Debian 4.19.98-1 (2020-01-26) i686 GNU/Linux

$ vgchange --version
vgchange --version
  LVM version:     2.03.02(2) (2018-12-18)
  Library version: 1.02.155 (2018-12-18)
  Driver version:  4.39.0
  Configuration:   ./configure --build=i686-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/i386-linux-gnu --libexecdir=${prefix}/lib/i386-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --exec-prefix= --bindir=/bin --libdir=/lib/i386-linux-gnu --sbindir=/sbin --with-usrlibdir=/usr/lib/i386-linux-gnu --with-optimisation=-O2 --with-cache=internal --with-device-uid=0 --with-device-gid=6 --with-device-mode=0660 --with-default-pid-dir=/run --with-default-run-dir=/run/lvm --with-default-locking-dir=/run/lock/lvm --with-thin=internal --with-thin-check=/usr/sbin/thin_check --with-thin-dump=/usr/sbin/thin_dump --with-thin-repair=/usr/sbin/thin_repair --enable-applib --enable-blkid_wiping --enable-cmdlib --enable-dmeventd --enable-dbus-service --enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-lvmpolld --enable-notify-dbus --enable-pkgconfig --enable-readline --enable-udev_rules --enable-udev_sync

Gibt es eine Möglichkeit, die LVs auf dieser Partition (erneut) zu mounten und sie dabei strikt schreibgeschützt zu halten?

Antwort1

Nachfolgend finden Sie eine Problemumgehung: Wenn LVM ein Lese-/Schreibblockgerät benötigt, erstellen wir eines mit einem Overlay-Blockgerät basierend auf dem schreibgeschützten Blockgerät (siehe diese andere Frage).

Als Root:

  1. Erstellen Sie eine Sparse-Datei mit der gleichen Größe wie das schreibgeschützte Blockgerät
    truncate -s`blockdev --getsize64 /dev/loop1` '/tmp/overlay.bin'
    
    (auch wenn größer als das aktuelle Dateisystem)
  2. Erstellen des Overlay-Blockgeräts
    loop=`losetup -f --show -- '/tmp/overlay.bin'`
    size=`blockdev --getsz /dev/loop1`
    printf '%s\n' "0 $size snapshot /dev/loop1 $loop P 8" | dmsetup create 'overlayloop1'
    
  3. Um zu verhindern, dass LVM doppelte PV mit derselben UUID bemängelt, bearbeiten Sie /etc/lvm/lvm.conf, um das ursprüngliche /dev/loop1 auszuschließen: entweder devices { scan = [ "/dev/mapper" ] }entweder devices { filter = [ "r|/dev/loop1|" ] }(siehediese FAQ im LVM-Wiki)
  4. Funktioniert jetzt vgchange -a y fw.

Während der Verwendung sollte die Datei /tmp/overlay.bin überwacht werden, sie sollte sich jedoch nicht vergrößern, insbesondere wenn das Dateisystem des LV schreibgeschützt gemountet ist.

So schließen Sie die Schleife:

  1. vgchange -a n fw
  2. dmsetup remove /dev/mapper/overlayloop1
  3. rm /tmp/overlay.bin
  4. losetup -d /dev/loop1

Antwort2

Nicht das Dateisystem war fehlerhaft (das kann sein, aber das ist hier nicht das Problem), sondern die LVM-Bcache-Struktur. Ich vermute, dass einige Standardeinstellungen geändert wurden und das der Grund ist, warum es nicht mehr funktioniert.

Vorschläge:

  1. Richte das Loop-Device einmal im rw-Modus ein. Das sollte das Problem beheben. Nach dem erfolgreichen vgchangekannst du das Loop-Device zerstören und erneut ro einrichten. Ohne das Dateisystem gemountet zu haben.
    Du kannst selbst ausprobieren, ob das das Problem löst, ohne das Loopdev rw zu machen: Du kannst ein weiteres Loopdev über eine 100M-Datei erstellen und einen Snapshot erstellen. Das müsstest du leider manuell mit machen dmsetup. Anschließend kannst du den Snapshot von den LVM-Tools scannen lassen. Alle Änderungen würden in den Snapshot geschrieben.

  2. Versuchenvgchange -a y --readonly fw

verwandte Informationen