Timeshift hat mir mein Arch Linux zerschossen ... Warum?

mit den Tipps das hast du doch jetzt soo schön erledigt

Zitat von GrapaPapa

Man entferne die subvolume ID Einträge in /etc/fstab und schon gehts auch mit timeshift.

Das ist die Lösung, konnte den Fehler reproduzieren. Hatte bei mir auch die IDs rausgeworfen, mich jetzt aber nicht mehr daran erinnert.

So sehen Subvolume-ID vor dem Rollback aus:

$ btrfs subvolume list /
ID 256 gen 159 top level 5 path @
ID 257 gen 159 top level 5 path @home
ID 258 gen 159 top level 5 path @log
ID 259 gen 128 top level 5 path @pkg
ID 260 gen 59 top level 5 path @.snapshots

Dazu die fstab

UUID=c4694... /         btrfs   rw,relatime,subvolid=256,subvol=/@     0 0
UUID=c4694... /home     btrfs   rw,relatime,subvolid=257,subvol=/@home 0 0
UUID=c4694... /var/log    btrfs   rw,relatime,subvolid=258,subvol=/@log  0 0
UUID=c4694... /var/cache/pacman/pkg   btrfs  rw,relatime,subvolid=259,subvol=/@pkg  0 0
UUID=c4694... /.snapshots     btrfs   rw,relatime,subvolid=260,subvol=/@.snapshots   0 0

Noch passen die IDs zusammen.

Aber nach dem Rollback haben die Subvolumes andere IDs bekommen. In der fstab stehen aber noch die alten ID und das Einbinden der Subvolumes schlägt fehl.

ID 274 gen 159 top level 5 path @
ID 273 gen 159 top level 5 path @home
ID 256 gen 125 top level 5 path timeshift-btrfs/snapshots/2024-03-28_07-45-06/@
ID 257 gen 141 top level 5 path timeshift-btrfs/snapshots/2024-04-07_15-37-13/@home
ID 258 gen 159 top level 5 path @log
ID 259 gen 128 top level 5 path @pkg
ID 260 gen 59 top level 5 path @.snapshots

Konnte das System wieder zum Laufen bekommen, in dem ich eine Live-Iso gestartet habe und in die /etc/fstab die neuen IDs eingetragen habe.

Würde auch als erste Maßnahme nach der Installation die subvolid=xxx in der fstab löschen. Dann sollte es keine Probleme geben.

Ich dachte immer die subvolid wäre essential?

Zitat von KTT73

Ich dachte immer die subvolid wäre essential?

Aus dem Arch-Wiki

Zitat

It is preferable to mount using subvol=/path/to/subvolume, rather than the subvolid, as the subvolid may change when restoring Snapshots, requiring a change of mount configuration.

Quelle: https://wiki.archlinux.org/title/Btrfs

Zitat

Aus dem Arch-Wiki

Quelle: https://wiki.archlinux.org/title/Btrfs

WOW, das steht irgendwie im Gegensatz zum deutschen Wiki oder ich verstehe es einfach nicht.

Arch auf BtrFS – wiki.archlinux.de

Zitat von KTT73

WOW, das steht irgendwie im Gegensatz zum deutschen Wiki oder ich verstehe es einfach nicht.

https://wiki.archlinux.de/title/Arch_auf_BtrFS

Die Deutsche Version müsste mal überarbeitet werden, die letzte Änderung liegt schon über zwei Jahre zurück. Ich schaue meistens nur auf die Engischen Seiten, die sind deutlich aktueller.

Zitat von DenalB

Es funktioniert!!!

Gratuliere!!

Habe einen Blick in mein Installationsscript geworfen und dabei diese Zeilen (wieder)entdeckt.

# fstab um subvolid bereinigen >> könnte sonst beim Snapper-Rollback Probleme bereiten
sed -i "s/,subvolid=256//" /etc/fstab
sed -i "s/,subvolid=257//" /etc/fstab
sed -i "s/,subvolid=258//" /etc/fstab
sed -i "s/,subvolid=259//" /etc/fstab
sed -i "s/,subvolid=260//" /etc/fstab
sed -i "s/,subvolid=261//" /etc/fstab

Das Subvolume-ID kommen aus dem Arch-Script genfstab, scheint das Archinstall-Script auch zu verwenden.

Zitat von DenalB

Es funktioniert!!!

Der subsolid-Eintrag in der fstab war schuld. Hatte mir auch nochmal meine gespeicherten fstab-Dateien aus Fedora und Nobara angeschaut. Hier gibt es ebenfalls keine subvolid-Einträge.

Ich habe aus meiner fstab nun alle subvolid-Einträge entfernt. Es gab noch mehr solcher Einträge, nicht nur für / und /home. Alle habe ich entfernt. Dann habe ich einen Snapshot erstellt und sogar ein paar Dateien aus meinem Home-Verzeichnis gelöscht. Ich wollte sichergehen, dass die Dateien nach dem Restore auch alle wieder da sind. Dann habe ich den Restore des Snapshots gemacht und nach dem Rechnerneustart waren alle gelöschten Dateien aus meinem Home-Verzeichnis wieder da.

Jetzt erklärt es sich auch, warum in der Vergangenheit nach einem Restore eines Snapshots für / trotzdem der Kernel wieder installiert war, den ich nach Erstellen des Snapshots erst installiert hatte. Wegen der durch den Restore geänderten subvolid wurde / gar nicht tatsächlich wiederhergestellt.

Krass ... Warum legt Arch Linux bei der Installation in der fstab überhaupt diese subvolid-Einträge an? In anderen Distributionen hatte ich dieses Problem nicht. Haben die alle keine subvolid-Einträge angelegt?

Jetzt weiß ich es und habe es mir in meine ToDo-Liste für nach der Arch-Installation geschrieben, dass ich die subvolid-Einträge aus der fstab direkt erstmal rausschmeiße. Vielen Dank an GrapaPapa und Sojan für den Hinweis auf die Lösung.

Alles anzeigen

Jetzt wo du es sagst...bei mir sind auch keine drin.

UUID=2e23fbb9-a043-430c-ab1d-566df3983b66 /              btrfs   subvol=/@,noatime,compress=zstd:3 0 0
UUID=2e23fbb9-a043-430c-ab1d-566df3983b66 /home          btrfs   subvol=/@home,noatime,compress=zstd:3 0 0
UUID=2e23fbb9-a043-430c-ab1d-566df3983b66 /var/cache     btrfs   subvol=/@cache,noatime,compress=zstd:3 0 0
UUID=2e23fbb9-a043-430c-ab1d-566df3983b66 /var/log       btrfs   subvol=/@log,noatime,compress=zstd:3 0 0

Danke!

in fast jedem meiner Einträge in der fstab stand auch etwas mit subvolid, habe ich nun auch entfernt.

# Static information about the filesystems. 
# See fstab(5) for details. 

# <file system> <dir> <type> <options> <dump> <pass> 
# /dev/nvme1n1p2 
UUID=baaea8d2-dc98-4a1d-a8a7-2e0bb31727f8       /               btrfs           rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@  0 0 

# /dev/nvme1n1p2 
UUID=baaea8d2-dc98-4a1d-a8a7-2e0bb31727f8       /home           btrfs           rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home      0 0 

# /dev/nvme1n1p2 
UUID=baaea8d2-dc98-4a1d-a8a7-2e0bb31727f8       /var/log        btrfs           rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@log       0 0 

# /dev/nvme1n1p2 
UUID=baaea8d2-dc98-4a1d-a8a7-2e0bb31727f8       /var/cache/pacman/pkg   btrfs           rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@pkg       0 0 

# /dev/nvme1n1p2 
UUID=baaea8d2-dc98-4a1d-a8a7-2e0bb31727f8       /.snapshots     btrfs           rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@.snapshots        0 0 

# /dev/nvme1n1p1 
UUID=F945-4CCD          /boot           vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro   0 2 




UUID=1e2f8d0c-b785-4c22-a139-ceed21d91ff6       /mnt/sda1       ext4            rw,suid,dev,exec,auto,nouser,async      0 0 

UUID=7E6421436421000F                           /mnt/sdb1       ntfs            rw,suid,dev,exec,auto,nouser,async      0 0

DenalB Das finde ich das schöne an Linux bzw. was mich derzeit extrem fasziniert. Die Auswahl, die Freiheit.

Wobei, gibt es da wesentliche Unterschiede zwischen Timeshift Snapshot und Snapper Snapshot?

Also du schriebst bei btrfs ist die Empfehlung scheinbar snapper statt timeshift (in Bezug auf Rollbacks, (wenn mal wirklich nötig), fing ich an nach Installwegen zu forschen und schaute viele Videos. bei einem hatte ich das gefühl, diese Schritte sind es und ich hatte letzte Nacht das probiert und klappte auch soweit...

Zitat von ghostbox

Wobei, gibt es da wesentliche Unterschiede zwischen Timeshift Snapshot und Snapper Snapshot?

Beides sind Werkzeuge, die dir den Umgang mit BTRFS erleichtern. Beide machen ihren Job, ist also eher eine Geschmacksfrage. Notwendig sind sie aber nicht, wie kim88 in Beitrag #7 gezeigt hat.