Restored Timeshift snapshot doesn't stick around

midlane_jake · 28 January 2022 13:21

So I screwed up my system a while ago and it wouldn't boot. But with timeshift to the rescue, I could successfully hop back to a working snapshot. However I can't for the life of me figure out how to make this snapshot my real new current system. I can edit boot parameters to target the snapshot like you see in my inxi (this is what I guess timeshift does when I hit restore), but then I seem to find myself in some Limbo, and updates I make don't persist into new snapshots. Then in a few days Timeshift will remove the snapshot I'm on while it's running... . Restoring the latest snapshot at this point zips me back to the state before I screwed up my system.

Edit: These are the steps I took:

When the system wouldn't boot, I booted a working snapshot through GRUB.
I opened timeshift, and hit restore on the same snapshot.

Thankful for help!

inxi:

```
System:
  Kernel: 5.15.13-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0
    parameters: BOOT_IMAGE=/timeshift-btrfs/snapshots/2022-01-28_14-00-01/@/boot/vmlinuz-linux-zen
    root=UUID=69c29b79-da5a-4df5-a53b-917ce7295884 rw
    rootflags=subvol=timeshift-btrfs/snapshots/2022-01-28_14-00-01/@ quiet splash
    rd.udev.log_priority=3 vt.global_cursor_default=0 systemd.unified_cgroup_hierarchy=1
    loglevel=3 mem_sleep_default=deep
  Desktop: i3 4.20.1 info: i3bar vt: 7 dm: LightDM 1.30.0 Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Desktop System: Gigabyte product: X570 AORUS ULTRA v: -CF serial: <superuser required>
  Mobo: Gigabyte model: X570 AORUS ULTRA serial: <superuser required>
    UEFI: American Megatrends LLC. v: F33i date: 04/23/2021
CPU:
  Info: model: AMD Ryzen 9 5900X bits: 64 type: MT MCP arch: Zen 3 family: 0x19 (25)
    model-id: 0x21 (33) stepping: 0 microcode: 0xA201009
  Topology: cpus: 1x cores: 12 tpc: 2 threads: 24 smt: enabled cache: L1: 768 KiB
    desc: d-12x32 KiB; i-12x32 KiB L2: 6 MiB desc: 12x512 KiB L3: 64 MiB desc: 2x32 MiB
  Speed (MHz): avg: 4029 high: 4830 min/max: 2200/4950 boost: enabled scaling:
    driver: acpi-cpufreq governor: performance cores: 1: 3601 2: 4212 3: 3708 4: 3795 5: 3798
    6: 3751 7: 4174 8: 4655 9: 4172 10: 4676 11: 3689 12: 3714 13: 3613 14: 3801 15: 4830 16: 3831
    17: 3783 18: 4503 19: 4511 20: 4293 21: 3677 22: 3664 23: 3608 24: 4647 bogomips: 177602
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
    mitigation: Full AMD retpoline, IBPB: conditional, IBRS_FW, STIBP: always-on, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA GA104 [GeForce RTX 3070] vendor: Micro-Star MSI driver: nvidia v: 470.74
    alternate: nouveau,nvidia_drm bus-ID: 08:00.0 chip-ID: 10de:2484 class-ID: 0300
  Device-2: Logitech Webcam C930e type: USB driver: snd-usb-audio,uvcvideo bus-ID: 3-6.3:5
    chip-ID: 046d:0843 class-ID: 0102 serial: <filter>
  Display: x11 server: X.Org 1.21.1.3 compositor: picom v: git-dac85 driver: loaded: nvidia
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 108 s-size: 602x342mm (23.7x13.5") s-diag: 692mm (27.3")
  Monitor-1: DP-0 res: 2560x1440 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27")
  OpenGL: renderer: NVIDIA GeForce RTX 3070/PCIe/SSE2 v: 4.6.0 NVIDIA 470.74 direct render: Yes
Audio:
  Device-1: NVIDIA GA104 High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel
    v: kernel bus-ID: 08:00.1 chip-ID: 10de:228b class-ID: 0403
  Device-2: AMD Starship/Matisse HD Audio vendor: Gigabyte driver: snd_hda_intel v: kernel
    bus-ID: 0a:00.4 chip-ID: 1022:1487 class-ID: 0403
  Device-3: SteelSeries ApS Arctis Pro Wireless type: USB
    driver: hid-generic,snd-usb-audio,usbhid bus-ID: 3-6.1.3:8 chip-ID: 1038:1294 class-ID: 0300
  Device-4: Logitech Webcam C930e type: USB driver: snd-usb-audio,uvcvideo bus-ID: 3-6.3:5
    chip-ID: 046d:0843 class-ID: 0102 serial: <filter>
  Sound Server-1: ALSA v: k5.15.13-zen1-1-zen running: yes
  Sound Server-2: sndio v: N/A running: no
  Sound Server-3: JACK v: 1.9.20 running: no
  Sound Server-4: PulseAudio v: 15.0 running: yes
  Sound Server-5: PipeWire v: 0.3.43 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel bus-ID: 03:00.0 chip-ID: 8086:2723
    class-ID: 0280
  IF: wlp3s0 state: down mac: <filter>
  Device-2: Intel I211 Gigabit Network vendor: Gigabyte driver: igb v: kernel port: f000
    bus-ID: 04:00.0 chip-ID: 8086:1539 class-ID: 0200
  IF: enp4s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: br-a75c55ff1e63 state: down mac: <filter>
  IF-ID-2: docker0 state: down mac: <filter>
  IF-ID-3: virbr0 state: down mac: <filter>
Bluetooth:
  Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8 bus-ID: 3-5:2 chip-ID: 8087:0029
    class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 0 state: down bt-service: enabled,running rfk-block:
    hardware: no software: yes address: <filter>
Drives:
  Local Storage: total: 1.48 TiB used: 309.93 GiB (20.4%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/sda maj-min: 8:0 vendor: Intel model: SSDSC2CT120A3 size: 111.79 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 300i scheme: GPT
  ID-2: /dev/sdb maj-min: 8:16 vendor: Western Digital model: WD10EARS-00Y5B1 size: 931.51 GiB
    block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s type: N/A serial: <filter> rev: 0A80
    scheme: MBR
  ID-3: /dev/sdc maj-min: 8:32 vendor: Samsung model: SSD 850 PRO 512GB size: 476.94 GiB
    block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 2B6Q
    scheme: MBR
Partition:
  ID-1: / raw-size: 78.12 GiB size: 78.12 GiB (100.00%) used: 41.5 GiB (53.1%) fs: btrfs
    dev: /dev/sda2 maj-min: 8:2
  ID-2: /boot/efi raw-size: 1000 MiB size: 998 MiB (99.80%) used: 560 KiB (0.1%) fs: vfat
    dev: /dev/sda1 maj-min: 8:1
  ID-3: /home raw-size: 476.93 GiB size: 476.93 GiB (100.00%) used: 268.43 GiB (56.3%) fs: btrfs
    dev: /dev/sdc1 maj-min: 8:33
  ID-4: /var/log raw-size: 78.12 GiB size: 78.12 GiB (100.00%) used: 41.5 GiB (53.1%) fs: btrfs
    dev: /dev/sda2 maj-min: 8:2
  ID-5: /var/tmp raw-size: 78.12 GiB size: 78.12 GiB (100.00%) used: 41.5 GiB (53.1%) fs: btrfs
    dev: /dev/sda2 maj-min: 8:2
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 31.35 GiB used: 2.8 MiB (0.0%) priority: 100 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 16.8 C mobo: N/A gpu: nvidia temp: 32 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 0%
Info:
  Processes: 527 Uptime: 1m wakeups: 0 Memory: 31.35 GiB used: 4.17 GiB (13.3%) Init: systemd
  v: 250 tool: systemctl Compilers: gcc: 11.1.0 Packages: pacman: 1641 lib: 465
  Client: Unknown Client: garuda-assistant inxi: 3.3.12
```

SGS · 28 January 2022 13:26

In snapshot open timeshift and restore this snapshot. Then reboot, normal way.

midlane_jake · 28 January 2022 13:30

Hey, thanks for quick reply. That's what I did, I updated my question to clarify this.

SGS · 28 January 2022 13:41

Then reboot. Do not make updates in this snapshot.
Grub will boot in the restored snapshot, than, maybe update, if bugs are fixed.

midlane_jake · 28 January 2022 14:23

I did reboot several times after restoration, and the changes I make are persisted through reboots. My problem is that it seems to me timeshift doesn't recognize that I actually chose this snapshot to become my new current, and deletes the snapshot according to schedule. Is the BOOT_IMAGE path correct?

BOOT_IMAGE=/timeshift-btrfs/snapshots/2022-01-28_14-00-01/@/boot/vmlinuz-linux-zen
    root=UUID=69c29b79-da5a-4df5-a53b-917ce7295884 rw
    rootflags=subvol=timeshift-btrfs/snapshots/2022-01-28_14-00-01/@

I sort of would have expected something like timeshift-btrfs/snapshots/current to indicate this is a live snapshot, but maybe this is how it's supposed to be since you didn't comment on it.

But anyway, I might have screwed up last restore somehow and went through the steps again like you said. I guess I'll see in a few days if timeshot rips this snapshot out from under me as well.

meanruse · 28 January 2022 15:23

I think the problem is you are still booting from a snapshot?

I'd try reverting the boot options to whatever they used to be before

then update-grub and reboot.

Disclaimer

Take my words with a big grain of salt, it's just an educated guess, definitely not an expert advice -- I didn't know what a btrfs was two months ago.

Better yet, wait for someone to confirm or call me out for the BS...

There should also be some Garuda tool to repair boot, look around here -- I can't remember and I'm busy at the moment. Hope it helps, sorry if I just told you how to brick it for good (just joking, shouldn't do any more damage... I think).

midlane_jake · 28 January 2022 21:28

Ok problem solved.

tl;dr: /@ is the primary root path, everything under /timeshift-btrfs/snapshots/<date>/@ should only be booted into temporary while fixing a system.

--

@meanruse Your thought did occur to me as well, but I don't know what the boot parameter was before However after some researching it seemed like /@ was that "current" path I was looking for, i.e. remove the /timeshift-btrfs/snapshots/<date>-part.

I edited the boot parameter to /@ only - this booted me into system pre-borked state. From this state I used Timeshift to restore the snapshot I had used most recently which effectively copied /timeshift-btrfs/snapshots/<date> into the currently running /@. After a reboot and checking that the restoration worked, I ran update-grub which permanently got rid of the snapshot-path.

It turns out that somehow while screwing around trying to get my system to boot I had changed grub to premanently boot into a snapshot, and my guess is when I did Timeshift restore I just copied another snapshot into THAT snapshot, which a few days later was just removed by timeshift since it cycles snapshots..

filo · 28 January 2022 22:43

Well done. Anyway, I belive the solution should be given to @meanruse , who gave you the idea to play around with the boot parameter. Then for sure you implemented it correctly.
It's just a formal detail, but that's what the "solution" mark is for in the end.

midlane_jake · 28 January 2022 22:50

Absolutely. Thanks for your help guys!

meanruse · 29 January 2022 07:43

Glad to know I did not help you to wreck your box, and sorry for partial information but I was in a rush. On the other hand, if it prompted more research, even better.
You definitely have the right mindset for problem solving.
P.S. I don't really mind who the solution is awarded to, so far as it's all roses in the end and we grow together, I am happy. I learned something too and that's my reward.

system · 31 January 2022 07:44

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.