Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] Masters of War (kde) - snapper funktioniert nicht wie erwartet  (Read 1754 times)

Offline dieres

  • User
  • Posts: 786
Moin,

Ich habe Masters of War (Release) mit sha256 geprüft und dann in einer virtuellen Qemu Maschine installiert um die Snapper Funktionalität zu testen. Dazu natürlich auch die Handbuchseiten dazu gelesen und u.a. das cleanup von 10m auf 4h umgestellt.

Danach habe ich nala upgrade --full ausgeführt, was erst einmal bei dpkg Meldung mit 0% hängenblieb, bis ich mit j <Enter> es geschafft habe, das das Upgrade weitermachte. bei 99% das gleiche Spiel. mache es jetzt mit dem Parameter -y. Aber nun zum eigentlichen Problem:
die snapshots werden angelegt, (warum eigentlich 2x pre bei einem post?) und ich kann sie bei einem Reboot im Grubmenü auswählen.
Ich habe dann darktable im normalen System installiert, noch einen manuellen snapshot mit snapper-gui erstellt und neu gebootet in den pre snapshot 1 vom nala upgrade.
Dort habe ich dann mit "snapper --ambit classic rollback" versucht das system auf den frühesten, snapshot 1 zurückzusetzten.
in der Konsole zeigt dann snapper list folgendes:

Code: [Select]
root@siduction:~# snapper list

  # | Typ    | Vorher # | Datum                       | Benutzer | Bereinigen | Beschreibung        | Benutzerdaten

----+--------+----------+-----------------------------+----------+------------+---------------------+--------------

 0  | single |          |                             | root     |            | current             |              
 1  | pre    |          | Di 03 Jan 2023 01:18:06 CET | root     | number     | apt                 |              
 2  | pre    |          | Di 03 Jan 2023 01:18:07 CET | root     | number     | apt                 |              
 3  | post   |        2 | Di 03 Jan 2023 06:49:24 CET | root     | number     | apt                 |              
 4  | pre    |          | Di 03 Jan 2023 13:30:08 CET | root     | number     | apt                 |              
 5  | pre    |          | Di 03 Jan 2023 13:30:08 CET | root     | number     | apt                 |              
 6  | post   |        5 | Di 03 Jan 2023 13:30:21 CET | root     | number     | apt                 |              
 7  | pre    |          | Mi 04 Jan 2023 00:26:45 CET | root     | number     | apt                 |              
 8  | pre    |          | Mi 04 Jan 2023 00:26:45 CET | root     | number     | apt                 |              
 9  | post   |        8 | Mi 04 Jan 2023 00:27:55 CET | root     | number     | apt                 |              
10  | pre    |          | Mi 04 Jan 2023 00:31:42 CET | root     | number     | apt                 |              
11  | pre    |          | Mi 04 Jan 2023 00:31:42 CET | root     | number     | apt                 |              
12  | post   |       11 | Mi 04 Jan 2023 00:31:48 CET | root     | number     | apt                 |              
13  | single |          | Mi 04 Jan 2023 00:34:34 CET | didi     |            | nach darktable      |              
14  | single |          | Mi 04 Jan 2023 00:40:33 CET | root     | number     | rollback backup     | important=yes

15+ | single |          | Mi 04 Jan 2023 00:40:33 CET | root     |            | writable copy of #1 |             

wenn ich jetzt neu boote hätte ich erwartet, das mein Standard booteintrag  mich ins system zum Zeitpunkt von snapshot 1 führt und darktable nicht mehr installiert wäre. Das ist aber nicht so. Der current "snapshot" des laufenden systems ist unverändert auf dem Stand vor dem Rollback.

Irgendetwas muss ich wohl nicht begreifen, was die snapshot Geschichte angeht oder der letzte Schritt den rollback read/write snapshot in grub auf current zu setzen funktioniert nicht.

Kann mich jemand erhellen wo mein Problem/Denkfehler liegt?

Und allen noch ein frohes neues Jahr
Dietrich

p.s. Im Grub Menü unter siduction snapshots werden auch nur die Einträge 1-13 angezeigt 14 und 15 fehlen, die werden erst  nach einem manuellen update-grub im normal gebooteten System im Grub Menü angezeigt.
« Last Edit: 2023/01/04, 14:09:57 by dieres »

Offline scholle1

  • User
  • Posts: 85
Hallo Dietrich,

habe das Verhalten mit siduction xfce verifiziert.
Liegt nicht an dir.
Hat alles zwei Tage vor dem Relaese noch richtig funktioniert. Wir sind gerade an der Ursachenforschung.
Je mehr Bürgerinnen und Bürger mit Zivilcourage ein Land hat, desto weniger Helden wird es einmal brauchen.
(Franka Magnani)

Offline dieres

  • User
  • Posts: 786
Danke fürs Überprüfen. Werde es wohl abwarten können:) und dann erstmal Erfahrung damit sammeln bevor ich es auf meinen Regulären PCs / Laptops installiere.

Offline scholle1

  • User
  • Posts: 85
Hi Dietrich,

ein Lösungsvorschlag:
  • Unmittelbar nach der Installation das default Subvolumen festlegen.
  • Die Datei /etc/grub.d/10_linux ändern.
  • Den Bootmanager grub aktualisieren.
  • Reboot.

So kannst du vorgehen:

1.
Nach dem ersten Boot in das frisch auf btrfs installierte System die vorhandenen Subvolumen anzeigen lassen und das Subvolumen @ als default setzen.

Code: [Select]
root@lap1:/# btrfs subvolume list /
ID 256 gen 752 top level 5 path @
ID 257 gen 724 top level 5 path @snapshots
ID 258 gen 755 top level 5 path @home
ID 259 gen 755 top level 5 path @root
ID 260 gen 773 top level 5 path @var@log
ID 262 gen 69 top level 258 path @home/.snapshots

root@lap1:/# btrfs subvolume set-default 256 /

2.
In der Datei /etc/grub.d/10_linux die Zeilen 85-90 auskommentieren.
Einen Editor mit ROOT-Rechten benutzen.
Vorher
Code: [Select]
case x"$GRUB_FS" in
    xbtrfs)
rootsubvol="`make_system_path_relative_to_its_root /`"
rootsubvol="${rootsubvol#/}"
if [ "x${rootsubvol}" != x ]; then
    GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
fi;;
    xzfs)
rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
;;
esac

Nachher
Code: [Select]
case x"$GRUB_FS" in
#    xbtrfs)
# rootsubvol="`make_system_path_relative_to_its_root /`"
# rootsubvol="${rootsubvol#/}"
# if [ "x${rootsubvol}" != x ]; then
#     GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
# fi;;
    xzfs)
rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
;;
esac

3.
Grub aktualisieren.
Code: [Select]
root@lap1:/# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/mow/theme.txt
Found linux image: /boot/vmlinuz-6.1.1-4-siduction-amd64
Found initrd image: /boot/initrd.img-6.1.1-4-siduction-amd64
Found memtest86+x64 image: /@/boot/memtest86+x64.bin
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Detecting snapshots ...
No snapshots found.
If you think an error has occurred , please file a bug report at " https://github.com/Antynea/grub-btrfs "
Unmount /tmp/grub-btrfs.lP3VjQ6pQj .. Success
done
root@lap1:/#

4.
Reboot. Von nun an sollten die Snapshots und ggf. Rollback funktionieren.
Ich empfehle ausdrücklich die Rollback von dem default Subvolumen bzw. Snapshot aus zu machen.
Der Befehl lautet dann:
Code: [Select]
snapper --ambit classic rollback #Wobei "#" die Nummer des gewünschten Snapshot ist.

Man muss berücksichtigen, dass nach einem Rollback auch die grub.cfk die des alten Snapshot ist und somit die neueren Snapshot, von dennen aus man den Rollback getätigt hat, nicht enthalten sind.
Das ist der Sinn des Rollback, den alten Zustand herstellen.
Erst ein weiterer Snapshot oder ein 'update-grub' im Rollback Ziel aktualisiert das dortige Grub-Menü.
Je mehr Bürgerinnen und Bürger mit Zivilcourage ein Land hat, desto weniger Helden wird es einmal brauchen.
(Franka Magnani)

Offline dieres

  • User
  • Posts: 786
Danke für Deine Mühe! Werde ich ausprobieren und versuchen alles zu verstehen. Und mir ein Vorgehen zu überlegen für den Fall, das das default @ nicht mehr bootet, sondern nur noch ein snapshot.

Offline dieres

  • User
  • Posts: 786
Ich habe jetzt mal  versucht über ein gebootetes LiveISO das default root @ und alle anderen subvols nach /mnt zu mounten und mit chroot /mnt /bin/bash ins System zu gehen und dort snapper auszuführen.

sudo su -

mount -t btrfs -o subvol=/@ /mnt
mount -t btrfs -o subvol=/@snapshots /mnt/.snapshots
mount -t btrfs -o subvol=/@home /mnt/home
mount -t btrfs -o subvol=/@root /mnt/root
mount -t btrfs -o subvol=/@var@log /mnt/var/log
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
mount --bind run /mnt/run
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts

chroot /mnt /bin/bash

wenn ich dann versuche snapper auszuführen bekomme ich folgende Meldung:


root@siduction:/# snapper list
Die Konfiguration "Root" ist nicht vorhanden. Snapper ist wahrscheinlich nicht konfiguriert.
Weitere Anweisungen finden Sie in 'man snapper'.


Was mache ich da falsch?



Offline dieres

  • User
  • Posts: 786
Solange das System bootet funktioniert jetzt alles mit Deinen vorgeschlagenen Änderungen. Danke:)

Offline scholle1

  • User
  • Posts: 85
@dieres
Da ich mit dem Verhalten von snapper beim Rollback auch nicht zufrieden war, sind einige Dateien, Scripte und systend Units entstanden. Du findest die Dateien und die Dokumentation auf siduction github "grub-btrfs-rollback_settings.

Mit diesem Set wird die Grub Menüdatei `grub.cfg` immer dann aktualisiert, wenn sich nach einem Snapshot, einem Rollback oder Reboot die Pfade des Btrfs-default-Subvolumen, des gebooteten Subvolumens oder des Grub-default-Menüeintrages unterscheiden.

Die Handhabung des Rollback unterscheidet sich von der Beschreibung im zur Zeit noch ausgelieferten Handbuch.
  • Rollback immer aus dem derzeitigen default Subvolumen mit Angabe der Subvolumen Nummer des Rollbackziels.
    snapper -a classic rollback #
  • Reboot in das Rollbackziel.
    Der Standard Booteintrag wurde aktualisiert und führt automatisch zum Rollbackziel.
    Auch im Rollbackziel wird die Grub Menüdatei `grub.cfg` automatisch aktualisiert.
  • a) Wenn das OS im Rollbackziel den Erwartungen entspricht, muss der Befehl
        grub-install ...
        ausgeführt werden, damit Grub fortan im Rollbackziel agiert.
    b) Wenn nicht, Reboot über das Untermenü "siduction snapshots" in das vorherige default Subvolumen. Mittels
        snapper list und btrfs sub list /
        die ID des vorherigen default Subvolumens ermitteln und mit
        btrfs sub set-defaulf <ID> /
        das default Subvolumen zurücksetzen. Nach einem erneuten Reboot über das Untermenü "siduction snapshots"
        wird die Grub Menüdatei `grub.cfg` automatisch aktualisiert.

Das ganze liegt zur Zeit noch nicht als Paket zur Installation mit apt vor. Wir arbeiten daran.
Bei einer nachträglichen Installation musst du berücksichtigen, dass die alten Snapshots nicht über das Dateienset verfügen, also die Funktionalität dort auch nicht enthalten ist.
Je mehr Bürgerinnen und Bürger mit Zivilcourage ein Land hat, desto weniger Helden wird es einmal brauchen.
(Franka Magnani)