Verständnisproblem: snapper rollback und grub

[Sector13]

Hallo,

ich habe ein scheinbar großes Verständnisproblem zwischen einem snapper rollback und dem daraus resultierenden /boot/grub/grub.cfg file.

Wenn ich einen Rollback auf einem Snapshot mit Snapper durchführe. Dann wird von der Nummer zu der ich zurück will, eine Writeable Copy angelegt und diese als default-volume gesetzt. Soweit so gut.

Jetzt folgt der Reboot.

Alles hat funktioniert und der gesetzte Snapshot kann korrekt mit get-default ausgelesen werden.

Jetzt kommen wir zu meinem Problem. Folgt jetzt ein update-grub, entweder manuell oder bei einem Systemupdate, dann wird die grub.cfg z.b. wie folgt geändert:

linux /@snapshots/44/snapshot/boot/vmlinuz-5.14.0-2-amd64

Genau hier liegt aus meiner Sicht ein Fehler vor. Müsste es nicht heißen:

linux /@/boot/vmlinuz-5.14.0-2-amd64

Auf dieser Seite wird der Fehler auch beschrieben:

https://blog.cscholz.io/debian-einsatz-snapper/

Grub2 ist unter Debian so eingerichtet, dass bei der Verwendung von BTRFS Subvolumes das zu bootende Subvolume in der Datei /boot/grub/grub.cfg fest eingetragen ist.

Ich habe aber schon die hier beschriebene Lösung auf allen Scripten angewendet und dennoch wird immer wieder von einem update-grub der Snapshot fest gesetzt.

Kann mir vielleicht jemand sagen was da falsch läuft oder vielleicht ist es auch richtig und ich
habe es nicht verstanden.

Mit besten Grüßen

[Bequimao]

Hi,

Ich benutze ebenfalls btrfs und snapper, aber nicht grub von debian zum Booten, sondern grub einer anderen Distribution.

Damit das Booten nach snapper rollback korrekt funktioniert, gehe ich mit chroot in das Dateisystem root von Debian und rufe auf

Code: Alles auswählen

# update-initramfs -u -k all

# update-grub

Danach wird die Schablone von grub.cfg vom anderen Linux mit der Snapshot-nummer korrekt übernommen und gebootet.

Viele Grüße
Bequimão

[Sector13]

HI Bequimao,

sorry aber deine Erklärung verstehe ich jetzt nicht so ganz.

Danach wird die Schablone von grub.cfg vom anderen Linux mit der Snapshot-nummer korrekt übernommen und gebootet.

Ähm genau das ist doch das was ich nicht verstehe. Grub setzt doch den korrekten Snapshot( sieht man ja in meinem Post). Nur sollte nicht immer das normale @ (also das Ursprungs root volume) gesetzt werden und nicht in den snapshot gebootet werden.

[Sector13]

Ich habe mir mal OpenSuse in einer VM installiert um zu sehen wie es dort gelöst wurde. Dann habe ich mal einen Rollback ausgelöst und neu gebootet.
Nach einem grub update, habe ich mir dann mal die grub.cfg angesehen und dort wird, so wie ich es auch verstanden habe, nicht in den snapshot gebootet sondern es werden immer die
toplevel verweise auf root (@) genommen. Woher nimmt also Debian diesen Eintrag???

[Bequimao]

Ich wollte auch auch nur meinen aktuellen Stand beschreiben. Vor 3 oder 4 Jahren bin ich daran gescheitert, Debian mit /boot und grub auf btrfs Subvolumes überhaupt zum Booten zu bringen und nicht nur nach # snapper rollback.

openSUSE schafft es ja nach einem # snapper rollback direkt zu booten, ohne grub.cfg und die Initramdisk zu erneuern. Der Pfad zum Top Level Subvolume hat sich dann ja geändert. Das Verfahren im Arch Wiki, damaliger Stand, beschrieb ein Recovery ohne das Default-Subvolume zu ändern. Ich wüßte nicht, daß andere Verfahren wie timeshift oder Fedora Silverblue Ostree das Default-Subvolume neu setzen. Das Default-Subvolume ist das Subvolume, das von mount ohne zusätzliche Parameter gemountet wird.

Die Frage ist zuerst, ob der Debian Installer überhaupt die Installation von /boot auf btrfs zulässt. Wenn Debian eine separate, nicht-btrfs Partition für /boot erzwingt, stellt sich das Problem gar nicht. grub unter Debian ist dann nicht verpflichtet, das openSUSE-Schema zu unterstützen. Ich halte das openSUSE-Verfahren für einfach und logisch. Bei einem separaten /boot können sich ja die Kernel-Versionen und die Module unter /lib/modules auseinander entwickeln.

Viele Grüße,
Bequimão

[Sector13]

Die Frage ist zuerst, ob der Debian Installer überhaupt die Installation von /boot auf btrfs zulässt. Wenn Debian eine separate, nicht-btrfs Partition für /boot erzwingt, stellt sich das Problem gar nicht. grub unter Debian ist dann nicht verpflichtet, das openSUSE-Schema zu unterstützen. Ich halte das openSUSE-Verfahren für einfach und logisch. Bei einem separaten /boot können sich ja die Kernel-Versionen und die Module unter /lib/modules auseinander entwickeln.

Nutzt du jetzt Debian oder OpenSuse??? Bei Debian habe ich die Installation komplett auf Btrfs selber umgestellt. Die Boot Partition ist bei mir ein Btrfs filesystem. Ich habe generell nur /boot/efi nicht als Btrfs filesystem alles andere sind Btrfs subvolumes.

snapper rollback # macht intern nichts anderes als das default-subvolume auf den gewählten snapshot zu setzten. Was ich aber an der Grub routine nicht verstehe ist warum werden die Einträge auf den Snapshot gestellt und nicht wie bei OpenSuse unverändert gelassen.

[Bequimao]

Ich denke, daß ich mich klar ausgedrückt habe. Ich nutze beides im Multiboot-System.

Snapper funktioniert identisch. Der Unterschied ist, daß openSUSE direkt nach # snapper rollback bootet, während bei Debian in chroot grub.cfg und Initramdisk neu erzeugt werden müssen.

Bei einem erneuten Aufrub von update-grub ( # grub2-mkconfig -o ...) in openSUSE setzt grub in grub.cfg den Pfad auf das neue Default-Subvolume, hier

Code: Alles auswählen

linux   /@/.snapshots/152/snapshot/boot/vmlinuz-5.3.18-59.27-default root=/dev/mapper/vg1-mlvm12 rootflags=subvol=@/.snapshots/152/snapshot ro splash quiet showopts

Du hast im Eingangspost nicht klargemacht, welche Version funktioniert und welche nicht. Du hast die Installation selbst nach btrfs konvertiert oder sonstwie zusammen gebastelt. Folglich kannst du schwerlich argumentieren, daß da ein Bug vorliegt. Ich habe keine Zeit, um neu zu testen, da ich vorrangige Probleme habe.

Grüße
Bequimão

[Sector13]

Du hast im Eingangspost nicht klargemacht, welche Version funktioniert und welche nicht. Du hast die Installation selbst nach btrfs konvertiert oder sonstwie zusammen gebastelt. Folglich kannst du schwerlich argumentieren, daß da ein Bug vorliegt. Ich habe keine Zeit, um neu zu testen, da ich vorrangige Probleme habe.

Du verstehst die ganze Frage nicht.

Ich habe mir überhaupt nichts zusammen gebastelt ( Das warst nach deiner aussage eher du, weil du nicht den Default grub verwendest). Ich habe lediglich Debian auf einer Btrfs Partition in Subvolumes installiert. Was du da angeblich von OpenSuse zeigts kann ich nicht so nachvollziehen. Und das da ein Bug vorliegt habe ich auch gar nicht behauptet.

Was ich dir aber sagen kann ist das der Debian Grub (der Grub den Debian liefert) genau das macht was du da zeigst, nämlich den snapshot setzten der nach dem rollback das Default-subvolume ist. Und meine einzige Frage war ist das überhaupt richtig so. Weil eigentlich hatte ich das anderes verstanden.

Aber egal. Ich gebe es auf schein richtig zu sein. Hake ich ab.