Updating after a long time

Hello, sorry if this was posted before but i could not find it. I have been away from my pc since about april of last year and i was wondering if it was safe to update using just the 'update' command. I read that arch-based systems and other similar rolling releases can have issues after such gaps inbetween updates so if anyone can offer any help with that it would be greatly appreciated.

System:
  Kernel: 5.17.1-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 11.2.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=58d3aace-5477-467a-aae1-04bba92f4f0c rw rootflags=subvol=@
    quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    loglevel=3
  Desktop: KDE Plasma v: 5.24.4 tk: Qt v: 5.15.3 info: latte-dock
    wm: kwin_x11 vt: 1 dm: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Desktop Mobo: Micro-Star model: X470 GAMING PLUS MAX (MS-7B79)
    v: 3.0 serial: <superuser required> UEFI: American Megatrends v: H.60
    date: 06/11/2020
CPU:
  Info: model: AMD Ryzen 5 3600 bits: 64 type: MT MCP arch: Zen 2
    family: 0x17 (23) model-id: 0x71 (113) stepping: 0 microcode: 0x8701021
  Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
    L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 3 MiB desc: 6x512 KiB
    L3: 32 MiB desc: 2x16 MiB
  Speed (MHz): avg: 2414 high: 3648 min/max: 2200/4208 boost: enabled
    scaling: driver: acpi-cpufreq governor: schedutil cores: 1: 2525 2: 3648
    3: 2057 4: 2200 5: 2200 6: 2200 7: 2846 8: 2898 9: 2121 10: 1874
    11: 2200 12: 2200 bogomips: 86400
  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: Retpolines, IBPB: conditional, STIBP: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: Gigabyte
    driver: nvidia v: 510.54 alternate: nouveau,nvidia_drm pcie: gen: 3
    speed: 8 GT/s lanes: 16 bus-ID: 27:00.0 chip-ID: 10de:1c03
    class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.3 compositor: kwin_x11 driver: X:
    loaded: nvidia unloaded: modesetting alternate: fbdev,nouveau,nv,vesa
    gpu: nvidia display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 92 s-size: 530x301mm (20.87x11.85")
    s-diag: 610mm (24")
  Monitor-1: HDMI-0 res: 1920x1080 hz: 60 dpi: 92
    size: 531x299mm (20.91x11.77") diag: 609mm (23.99") modes: N/A
  OpenGL: renderer: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2
    v: 4.6.0 NVIDIA 510.54 direct render: Yes
Audio:
  Device-1: NVIDIA GP106 High Definition Audio vendor: Gigabyte
    driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
    bus-ID: 27:00.1 chip-ID: 10de:10f1 class-ID: 0403
  Device-2: AMD Starship/Matisse HD Audio vendor: Micro-Star MSI
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 29:00.4 chip-ID: 1022:1487 class-ID: 0403
  Sound Server-1: ALSA v: k5.17.1-zen1-1-zen running: yes
  Sound Server-2: sndio v: N/A running: no
  Sound Server-3: PulseAudio v: 15.0 running: no
  Sound Server-4: PipeWire v: 0.3.49 running: yes
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: Micro-Star MSI driver: r8169 v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 port: f000 bus-ID: 22:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: enp34s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 2.03 TiB used: 1.3 TiB (64.2%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Kingston model: SA2000M8250G
    size: 232.89 GiB block-size: physical: 512 B logical: 512 B
    speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: S5Z42105
    temp: 38.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Patriot model: Burst
    size: 223.57 GiB block-size: physical: 512 B logical: 512 B
    speed: 6.0 Gb/s type: SSD serial: <filter> rev: 61.2 scheme: GPT
  ID-3: /dev/sdb maj-min: 8:16 vendor: Kingston model: SV300S37A240G
    size: 223.57 GiB block-size: physical: 512 B logical: 512 B
    speed: 6.0 Gb/s type: SSD serial: <filter> rev: BBF0 scheme: MBR
  ID-4: /dev/sdc maj-min: 8:32 vendor: Western Digital
    model: WD10EZEX-08WN4A0 size: 931.51 GiB block-size: physical: 4096 B
    logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 serial: <filter>
    rev: 1A02 scheme: MBR
  ID-5: /dev/sdd maj-min: 8:48 vendor: Samsung model: SSD 860 EVO 500GB
    size: 465.76 GiB block-size: physical: 512 B logical: 512 B
    speed: 6.0 Gb/s type: SSD serial: <filter> rev: 3B6Q scheme: MBR
Partition:
  ID-1: / raw-size: 232.59 GiB size: 232.59 GiB (100.00%)
    used: 52.07 GiB (22.4%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
    used: 576 KiB (0.2%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
  ID-3: /home raw-size: 232.59 GiB size: 232.59 GiB (100.00%)
    used: 52.07 GiB (22.4%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-4: /var/log raw-size: 232.59 GiB size: 232.59 GiB (100.00%)
    used: 52.07 GiB (22.4%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-5: /var/tmp raw-size: 232.59 GiB size: 232.59 GiB (100.00%)
    used: 52.07 GiB (22.4%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 15.63 GiB used: 2.2 MiB (0.0%)
    priority: 100 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 46.0 C mobo: 39.0 C gpu: nvidia temp: 49 C
  Fan Speeds (RPM): fan-1: 0 fan-2: 1914 fan-3: 2180 fan-4: 0 fan-5: 0
    fan-6: 0 gpu: nvidia fan: 24%
  Power: 12v: N/A 5v: N/A 3.3v: 3.30 vbat: 3.31
Info:
  Processes: 349 Uptime: 13m wakeups: 479 Memory: 15.63 GiB
  used: 4.38 GiB (28.0%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 11.2.0 Packages: pacman: 1505 lib: 403 Shell: fish v: 3.4.1
  running-in: cool-retro-term inxi: 3.3.14
Garuda (2.5.6-2):
  System install date:     2022-03-17
  Last full system update: 2022-04-01
  Is partially upgraded:   No
  Relevant software:       NetworkManager
  Windows dual boot:       No/Undetected
  Snapshots:               Snapper
  Failed units:            bluetooth-autoconnect.service

Make a snapshot and

update

maybe a big download, but I think it will work fine.

2 Likes

This command is specifically designed to solve most of the issues which might occur, so yes.

5 Likes

Ok the update did work but it kinda broke my latte dock which i see now has been discontinued. Tried to return to a snapshot and i am now looking at grub

error: no such device [device id]
error: unknown filesystem
entering rescue mode...
grub rescue>

Tried a garuda live usb, it cannot chroot or repair my grub, any snapshots that i try to use, no matter how old are met with the same 452 out of range pointer eror and eventually back to grub repair. No idea what to do at this point.

You are trying to restore a snapshot from fourteen months ago? :face_with_raised_eyebrow: What is your goal here? To restore Latte Dock and never update again?

Latte Dock is all done, I think you should move on. Here is the guide for getting through the Latte Dock migration:

https://wiki.garudalinux.org/en/dr460nized-migration

1 Like

No, i made a snapshot today, before running the update. After the update was successful i restarted, mostly everything was fine. Some sticky notes-like widgets i had disappeared and i restored said snapshot in the hope of getting them back as i could not find them anywhere anymore. Trying to go back to said snapshot is what caused all this mess.

This happened because when you restored the snapshot, the OS was restored but the grub bootloader was not. Because of the significant time and version difference between then and now you are not able to boot your system anymore.

This is an easy fix. Boot a Garuda Linux live iso, chroot via sudo garuda-chroot -a and then reinstall grub via grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=garuda --recheck.

You said this doesn't work, but without logs it's impossible for us to know why this wouldn't work. We need you to share logs of everything you've tried, not just excerpts, but the whole thing whenever possible.

4 Likes

You can share logs from within the chroot by piping the command to termbin. eg:

your-darling-command-here | nc termbin.com 9999

will output a url post that here.

Running sudo garuda-chroot -a | nc termbin.com 9999 only outputs ERROR: No Linux partitions detected!
No url or anything else.

What does blkid output for you?

/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p1: LABEL_FATBOOT="NO_LABEL" LABEL="NO_LABEL" UUID="8A4D-F249" BLOCK_SIZE="512" TYPE="vfat" PARTUU
ID="a5d36813-e65f-b44d-8821-12b7e94ae63f"
/dev/nvme0n1p2: UUID="58d3aace-5477-467a-aae1-04bba92f4f0c" UUID_SUB="91b4e084-348e-48a8-a227-16467975256c" BL
OCK_SIZE="4096" TYPE="btrfs" PARTLABEL="root" PARTUUID="9ecbfd7e-d539-8f40-b158-a2035e19fed3"
/dev/sdd1: LABEL="Big Fast" UUID="240efd72-5288-488f-85f8-95b7a32574b5" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID
="df13a4f4-01"
/dev/sdb1: LABEL="more ssd" UUID="bdba6d69-954a-4ed0-b21e-2b0ded29be44" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID
="6e553c5b-01"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/sde2: SEC_TYPE="msdos" LABEL_FATBOOT="MISO_EFI" LABEL="MISO_EFI" UUID="CC34-06DF" BLOCK_SIZE="512" TYPE="
vfat"
/dev/sde1: BLOCK_SIZE="2048" UUID="2023-05-01-21-27-23-00" LABEL="GARUDA_DR460NIZED_RAPTOR" TYPE="iso9660"
/dev/sdc1: LABEL="Hdd" UUID="9653b6cb-a8c8-45de-8fc1-4b9c2b4a3fbc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="013
35e98-01"
/dev/sda1: LABEL="lmao" UUID="074ffcbe-bcaf-4de9-b7f0-2dad44815e9b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6b
17109a-68dc-4387-b821-392e92ea518b"
/dev/zram0: LABEL="zram0" UUID="a84be897-76d7-4b8e-abc1-4b32ff5e3bb7" TYPE="swap"
/dev/loop3: TYPE="squashfs"

Try using the chroot tool in the live ISO, or, even better:

you have to mount exactly /dev/nvme0n1p2 onto /mnt/broken and /dev/nvme0n1p1 should be your $esp later on.

By-the-way, I noticed only now. This was not meant to be run!

First you chroot, then you reinstall grub. And if you have troubles, you can pipe output from terminal to the internet in the suggested way (but from a live iso, it should be better to copy text from chroot terminal and past from the browser of the live iso into the forum).

6 Likes

Awesome, that did it! I am now back into my system.
Did an update, rebooted again, everything seems fine now.
Thank you very much!

3 Likes

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