I3 only redraws when switching between workspaces

Hello all!

I've been struggling with a recent issue since I've upgraded my system and did a restart. Ever since that, my WM seems to be broken. Basically when i start the system, and log in the screen "freezes" but whatever I do in the background still works and executes, without any visual changes. I use the i3WM version of Garuda and had no issues with it ever so far until now. I know that stuff does work in the background because when I switch between workspaces (open a terminal on ws. 1, I can't see the window, then I switch to ws. 2, then switch back to ws. 1 and the terminal is there), then the screen and everything is redrawn, and I see what I did before switching. Other than this very painful workaround I get absolutely no visual feedback on whatever I do on the system, and I can't seem to fix it.

Usually I have somewhat of an idea about what the issue might be, but not this time. The only idea I came up with was to reset i3 config at ~/.config/i3 to the default one found in the /etc folder, and to reset the config file found at ~/.condig/i3status to the default one too, but this did not fix my redrawing graphical issue, even after a restart.

I've tried upgrading again everything, tried doing several restarts, but nothing worked so far.

I'd like to ask for help with this above issue, maybe someone has an idea about what might be the problem.

diag output:

System:
  Kernel: 6.0.9-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=bc61e47e-bd51-4e16-83c4-fd7d9a67f43b rw rootflags=subvol=@
    quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    resume=UUID=39952a4e-28ef-4ebe-bebf-7ed65cfbb27f loglevel=3
  Desktop: i3 v: 4.21.1 info: i3bar vt: 7 dm: LightDM v: 1.32.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Kvm System: QEMU product: Standard PC (i440FX + PIIX, 1996)
    v: pc-i440fx-6.1 serial: <superuser required> Chassis: type: 1
    v: pc-i440fx-6.1 serial: <superuser required>
  Mobo: N/A model: N/A serial: N/A BIOS: SeaBIOS
    v: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org date: 04/01/2014
CPU:
  Info: model: Common KVM bits: 64 type: MCP SMP arch: Netburst Presler
    level: v1 built: 2006 process: Intel 65nm family: 0xF (15) model-id: 6
    stepping: 1 microcode: 0x1
  Topology: cpus: 2x cores: 4 smt: <unsupported> cache:
    L1: 2x 256 KiB (512 KiB) desc: d-4x32 KiB; i-4x32 KiB L2: 2x 16 MiB (32 MiB)
    desc: 4x4 MiB L3: 2x 16 MiB (32 MiB) desc: 1x16 MiB
  Speed (MHz): avg: 2095 min/max: N/A cores: 1: 2095 2: 2095 3: 2095 4: 2095
    5: 2095 6: 2095 7: 2095 8: 2095 bogomips: 33521
  Flags: ht lm nx pae sse sse2 sse3
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX unsupported
  Type: l1tf mitigation: PTE Inversion
  Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode;
    SMT Host state unknown
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: retbleed status: Not affected
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Retpolines, STIBP: disabled, RSB filling,
    PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Red Hat Virtio GPU driver: virtio-pci v: 1 alternate: virtio_pci
    bus-ID: 00:02.0 chip-ID: 1af4:1050 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.4 compositor: Picom v: git-5d150
    driver: X: loaded: modesetting alternate: fbdev,vesa gpu: virtio_gpu
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 270x203mm (10.63x7.99")
    s-diag: 338mm (13.3")
  Monitor-1: Virtual-1 model: QEMU Monitor built: 2014 res: 1024x768 hz: 75
    dpi: 100 gamma: 1.2 size: 260x195mm (10.24x7.68") diag: 325mm (12.8")
    ratio: 4:3 modes: max: 1024x768 min: 640x480
  API: OpenGL Message: Unable to show GL data. Required tool glxinfo
    missing.
Audio:
  Message: No device data found.
  Sound API: ALSA v: k6.0.9-zen1-1-zen running: yes
  Sound Server-1: PulseAudio v: 16.1 running: no
  Sound Server-2: PipeWire v: 0.3.60 running: yes
Network:
  Device-1: Intel 82371AB/EB/MB PIIX4 ACPI vendor: Red Hat Qemu virtual
    machine type: network bridge driver: piix4_smbus v: N/A modules: i2c_piix4
    port: N/A bus-ID: 00:01.3 chip-ID: 8086:7113 class-ID: 0680
  Device-2: Red Hat Virtio network driver: virtio-pci v: 1
    modules: virtio_pci port: e0e0 bus-ID: 00:12.0 chip-ID: 1af4:1000
    class-ID: 0200
  IF: ens18 state: up speed: -1 duplex: unknown mac: <filter>
  Device-3: Red Hat Virtio network driver: virtio-pci v: 1
    modules: virtio_pci port: e100 bus-ID: 00:13.0 chip-ID: 1af4:1000
    class-ID: 0200
  IF: ens19 state: down mac: <filter>
  Device-4: Red Hat Virtio network driver: virtio-pci v: 1
    modules: virtio_pci port: e120 bus-ID: 00:14.0 chip-ID: 1af4:1000
    class-ID: 0200
  IF: ens20 state: down mac: <filter>
Drives:
  Local Storage: total: 75 GiB used: 37.49 GiB (50.0%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/sda maj-min: 8:0 vendor: QEMU model: HARDDISK size: 75 GiB
    block-size: physical: 512 B logical: 512 B speed: <unknown> type: N/A
    serial: <filter> rev: 2.5+ scheme: MBR
Partition:
  ID-1: / raw-size: 57.81 GiB size: 57.81 GiB (100.00%)
    used: 37.49 GiB (64.9%) fs: btrfs dev: /dev/sda1 maj-min: 8:1
  ID-2: /home raw-size: 57.81 GiB size: 57.81 GiB (100.00%)
    used: 37.49 GiB (64.9%) fs: btrfs dev: /dev/sda1 maj-min: 8:1
  ID-3: /var/log raw-size: 57.81 GiB size: 57.81 GiB (100.00%)
    used: 37.49 GiB (64.9%) fs: btrfs dev: /dev/sda1 maj-min: 8:1
  ID-4: /var/tmp raw-size: 57.81 GiB size: 57.81 GiB (100.00%)
    used: 37.49 GiB (64.9%) fs: btrfs dev: /dev/sda1 maj-min: 8:1
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 17.19 GiB used: 0 KiB (0.0%)
    priority: -2 dev: /dev/sda2 maj-min: 8:2
  ID-2: swap-2 type: zram size: 68.71 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
Sensors:
  Src: lm-sensors+/sys Message: No sensor data found using /sys/class/hwmon
    or lm-sensors.
Info:
  Processes: 226 Uptime: 6m wakeups: 1 Memory: 68.71 GiB used: 2.25 GiB (3.3%)
  Init: systemd v: 252 default: graphical tool: systemctl Compilers:
  gcc: 12.2.0 Packages: pm: pacman pkgs: 1587 libs: 341 tools: pamac,paru,yay
  pm: rpm pkgs: 0 Shell: Zsh v: 5.9 running-in: alacritty inxi: 3.3.23
e[1;34mGaruda (2.6.9-1):e[0m
e[1;34m  System install date:e[0m     2022-06-10
e[1;34m  Last full system update:e[0m 2022-11-22
e[1;34m  Is partially upgraded:  e[0m No
e[1;34m  Relevant software:      e[0m NetworkManager
e[1;34m  Windows dual boot:      e[0m <superuser required>
e[1;34m  Snapshots:              e[0m Snapper
e[1;34m  Failed units:           e[0m bluetooth-autoconnect.service 

Hi @DreggHunShot, welcome to the community. :slightly_smiling_face:

Try creating a new user from a TTY and log in as them to determine if the issue is related to the profile, or system-wide. Something like this:

useradd -m -G wheel -s fish *username*

More here: Users and groups - ArchWiki

1 Like

Hi!
Thank you for the quick reply!
I've added a new user with the command you provided, restarted the system and successfully logged in with the new user, and I'm still having the same issue unfortunately. Now I even get a "You have an error in your i3 config file" with this new user that I wasn't getting before.

Any other ideas what might be the problem? Any diagnostics I can do which might help?

Thanks

Try rolling back to a snapshot from before this upgrade to test if the upgrade broke something.

It looks like you are running in a VM. Has anything changed with the VM recently, or the host OS?

4 Likes

Thank you, restoring from a snapshot worked as a workaround. Only the oldest snapshot worked, but at least it wasn't deleted yet so the system works again. Still no idea about the root cause, but I'm making a VM backup too now just to be safe.
Yes, I run the system in a VM, in a Proxmox environment. Nothing has changed with the VM itself as far as i know, other than me upgrading. I'll try to upgrade it again now that I have a backup, and will see if it breaks again. If it does, then for now I'll just run the old version since I use the system for work and Q4 is extremely busy.

I've did the above. When restored it's fine, but after upgrading it breaks again. So there's a workaround but no ultimate solution, something breaks with the update. I hope it'll get fixed sometime soon and I can upgrade later then :slight_smile:

Thank you for the snapshot restore solution!

Cheers,

Btw,

Installing in virtual machines is not recommended as it might result in a bad experience!

###### From download page.

1 Like

This is not great to hear, but I wasn't aware of this before, so thank you for bringing it to my attention. Unfortunately there is no bare metal install option for me in this situation, but I'll keep this in mind in the future.

You could just wait several days or a week and then try updating again, with your fingers crossed that whatever is breaking your system has been fixed. If the update still causes the same problem, you will have the unpleasant task of trying to identify which is the problematic package, so you can hold it back or get rid of it.

In the meanwhile, I would test if it is a kernel issue by taking the update, then installing the LTS kernel and booting with that. If you get the broken environment on the LTS kernel, it is less likely that the kernel update is what is breaking your system. You can always just roll back to your working snapshot if the LTS kernel doesn't work out.

3 Likes

Alright, thank you. I'll wait a bit then and retry the upgrade later, if it won't work, then it's time for some deep diving and looking for the problematic package.

I'll test the kernel-thing on this weekend, and post the results / experiences.

Okay, long time no progress on this because Q4 got extremely busy for me at work, but finally I was able to go after this and debug.

As it turns out the picom config located at ~/.config/picom.conf was responsible for all the problems. I'm not exactly sure what broke things in the config (I don't remember ever touching it by hand before or modifying it), but as an attempt to fix things, I've downloaded the sample config from
https://raw.githubusercontent.com/yshui/picom/next/picom.sample.conf

and just adjusted some of the settings by hand, and everything is fixed now.

So if anyone faces a similar issue, maybe picom.conf is the root cause.

Thank you all for the help and the suggestions!

The issue has been resolved now :slight_smile:

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