update-grub findet keinen neuen Kernel nach btrfs Snapshot Rollback

[synapsenstau]

Moin,

Vorgeschichte:
Vor einiger Zeit wurde wurde ein PAM (Pluggable Authentication Modules) via apt aktualisiert. Dabei gab es wohl einen Fehler und beim nächsten Neustart konnte ich mich nicht am System anmelden (User und Pass waren unbekannt). Somit war es Zeit sich die btrfs Snapshot Funktion zu beschäftigen. Via Grub habe ich den automatisch erstellten Snapshot von vor dem apt upgrade Fehler ausgewählt und das System/Snapshot RO-gebootet und es lief wie erwartet Fehlerfrei. Im Anschluss habe ich dann mit

Code: Alles auswählen

snapper rollback --ambit=classic

den aktuellen Snapshot schreibbar gemacht, neu gebootet und alles schien wieder zu funktionieren.

Unerwartetes Problem:
Ein paar Tage später bemerkte ich, das die neuen Kernel, die via apt ausgeliefert wurden, nicht im Bootmenu auftauchen. Unter /boot sehe ich zwar die neuen initrd.img-xxx und vmlinuz-xxx, aber eine

Code: Alles auswählen

update-grub

findet sie nicht. Ich denke das ich beim Rollback wohl irgendein Fehler gemacht habe.

Vielleicht hat ja jemand ein Tipp für mich.

Edit: Update - Grub korrigiert

[isabena]

Code: Alles auswählen

grub-update

findet sie nicht.

hast du dich hier im post verschrieben ?
der Befehl lautet andersherum

[Bequimao]

# snapper rollback macht keinen existierenden Snapshot schreibbar, sondern erzeugt einen neuen Snapshot (rw) und setzt diesen als Default Subvolume. Das ist das Subvolume, das ohne weitere Optionen vom Befehl mount gemounted wird.

Du bietest keine Info über dein Setup. Wo liegt /boot? Auf einer separaten nicht-btrfs Partition, auf dem /root Subvolume oder auf einem anderen Subvolume? Ich nutze btrfs und snapper, habe aber noch nie btrfs mit dem Debian-Installer installiert.

Bitte poste folgende Ausgaben:

Code: Alles auswählen

# snapper list

# btrfs subvolume get-default /

# mount -l | grep btrfs | sort

# cat /boot/grub/grub.cfg

Grüße
Bequimão

[synapsenstau]

Du bietest keine Info über dein Setup. Wo liegt /boot? Auf einer separaten nicht-btrfs Partition, auf dem /root Subvolume oder auf einem anderen Subvolume? Ich nutze btrfs und snapper, habe aber noch nie btrfs mit dem Debian-Installer installiert.

Btrfs nutze ich schon länger und habe es meisten via Debian Installer einrichten lassen. Mit Snapper habe ich erst jetzt das erste mal auseinander gesetzt. /boot liegt auf dem btrfs root /. Die geforderten Daten:

snapper list
42012

btrfs subvolume get-default /

Code: Alles auswählen

ID 540 gen 54813 top level 257 path @snapshots/278/snapshot

mount -l | grep btrfs | sort

Code: Alles auswählen

/dev/nvme0n1p1 on /home type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=258,subvol=/@home)
/dev/nvme0n1p1 on /root type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=259,subvol=/@root)
/dev/nvme0n1p1 on /.snapshots type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=257,subvol=/@snapshots)
/dev/nvme0n1p1 on / type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=540,subvol=/@snapshots/278/snapshot)
/dev/nvme0n1p1 on /var/log type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,autodefrag,subvolid=260,subvol=/@var@log)

cat /boot/grub/grub.cfg
42013

[Bequimao]

Snapper rollback scheint ordnungsgemäß gelaufen zu sein. Das Root-Dateisystem auf dem neu erzeugten Subvolume ist als root gemounted.

Ich sehe aber an der grub.cfg, dass die 10_linux Section fehlt und stattdessen ein 09_siduction_btrfs vorliegt. Es handelt sich also um Siduction mit Siduction-spezifischen Änderungen an Grub. Hinweis im Eingangspost fehlt! Da solltest du logischerweise auch Hilfe im Siduction-Forum suchen.

Ich kann hier nur sagen, wie es bei mir unter Debian stable und testing läuft. Es ist ein Eigenbau nach openSUSE-Schema, keine Standardinstallation.

Nach einem # snapper rollback bootet das System im Gegensatz zu openSUSE nicht.
Ich muß dann folgende Schritte in chroot unternehmen:

1) Grub neu installieren
2) alle initrds neu erzeugen (dort sind Pfade und Subvol-Ids fest verdrahtet)
3) grub.cfg neu erzeugen.

Viele Grüße
Bequimão

[synapsenstau]

Ich habe es leider erst jetzt geschafft zu Antworten. Es gab bei mir eine unverhoffte Verbesserung. Das 'apt upgrade' vom Freitag Abend hat das Kernel Probelm behoben und am Samstag beim nächsten booten wurden alle Kernel angezeigt. Also das Problem scheint gelöst zu sein...

Ich danke dir trotzdem für deine Hilfe.