[-] vepro@lemmy.world 4 points 1 year ago

This worked, Thanks!

13
submitted 1 year ago* (last edited 1 year ago) by vepro@lemmy.world to c/support@lemmy.world

I'd like to unmod myself from !geometrydash@lemmy.world, but I don't see any button to do it, and by quick research the actions suggested do not appear for me.

I don't see an option via a comment of mine:

And neither over the sidebar:

[-] vepro@lemmy.world 1 points 1 year ago

Only difference in info I can see is that display name ends with :0 instead of :0.0. Depending on your DE, you might fiddle with display settings there. Are you running X natively and not XWayland?

[-] vepro@lemmy.world 1 points 1 year ago

Already used these drivers on previous installation, was 525 iirc (Linux Mint), but also went from 530 to 535 on Arch and it persisted. Thing is problem started the exact day I also flashed BIOS firmware so it's likely that it could come from there, but trying lts kernel now

11
submitted 1 year ago* (last edited 8 months ago) by vepro@lemmy.world to c/archlinux@lemmy.ml

Update 02/2024

The Problem has been solved by disabling TPM in UEFI Setup. TPM seems to be bugged with some CPUs. Before updating the BIOS, TPM was probably disabled by vendor, hence it didn't appear initially.

If you experience freezes right before poweroff, try disabling TPM in UEFI/BIOS settings if it isn't in use.

Symptoms

  • Complete Freeze after:
preparing to enter ACPI S5 state
Reboot: Power Down
  • seemlingly random (can successfully shutdown maybe 10 times in a row, then suddenly freezes again)
  • seems to happen more often as uptime grows
  • Case Fans still spin, LEDs and Lights stay on
  • Monitors stay on, still react to HDMI/DP Hotplugging (unplug/plug)
  • REISUB/REISUO doesn't work
  • Disks are already powered off and disconnected
  • USB devices (eg. keyboard unresponsive)

Since When

  • After switching to Arch and flashing BIOS Firmware 7C88v18 to MSI B460M-A Pro Board
  • Arch Linux is ruled out by me since it's very unlikely Userland plays a role, and already used Linux before without the problem
  • Gone from linux ~6.2.10 to 6.4.8, Kernel bug unlikely

Attempted:

  • Reflash 7C88v18 from a FAT32 formatted partition (USB)
  • Add reboot=pci or reboot=acpi acpi=force to kernel cmdline
  • run fwupd
  • Stop X and wait a bit for processes to clear up (???)
  • intel-ucode is installed:
~> pacman -Qi intel-ucode | head -2
Name                     : intel-ucode
Version                  : 20230613-1
  • Other threads on the Internet seem to have easier reproducibility (always happening), solutions were about either kernel cmdline or outdated kernel (If I didn't see a thread with my exact problem, apologies)

Hardware Info

~> pacman -Qi nvidia | head -2
Name                     : nvidia
Version                  : 535.86.05-8
~> cat /sys/class/dmi/id/board_* 2>/dev/null
Default string
B460M-A PRO (MS-7C88)
Micro-Star International Co., Ltd.
1.0
~> LC_ALL=C lscpu | grep -i 'model name'
Model name:                      Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
~> sudo journalctl -k --grep=microcode
[...] kernel: microcode: updated early: 0xf0 -> 0xf6, date = 2022-12-26
[...] kernel: SRBDS: Mitigation: Microcode
[...] kernel: microcode: Microcode Update Driver: v2.2.

Misc

  • Did I just miss something obvious?
  • I don't want to go back to an outdated BIOS firmware
  • lscpu, nvidia-smi and other info added if needed
  • I have another device (ASUS Board, similar CPU) with similar arch linux setup (nouveau instead of propietary nvidia there), no problems on that device
8
submitted 1 year ago* (last edited 1 year ago) by vepro@lemmy.world to c/archlinux@lemmy.ml

This concerns a multi monitor setup with different refresh rates (e. g. 1 with 60hz and 1 with 144hz).

The text below is part of the linked article. If you have both nvidia and picom installed, check both sections.

NVIDIA (propietary)

  • Open nvidia-settings
  • Go to 'X Server Display Configuration'
  • In the bottom right, Click on 'Advanced...' if it says 'Advanced...'
  • Make sure anything regarding 'force composition pipeline' is checked off
  • Make sure you selected the highest refresh rates possible. You can either select it through the settings, configure it with xrandr or with your DEs Display Settings, is applicable

picom

  • Make sure to start picom with --no-vsync

Misc

If it still doesn't work, try settings these environment variables:

CLUTTER_DEFAULT_FPS=<your highest refresh rate>
__GL_SYNC_DISPLAY_DEVICE=<your highest refresh rate display>
__GL_SYNC_TO_VBLANK=0

Find the DISPLAY_DEVICE name with xrandr | grep connected

Add the text block above to /etc/environment (Tip: Use EDITOR=<your editor, if EDITOR is not set anywhere else> sudoedit instead of sudo nano or sudo vim)

-> sudoedit /etc/environment

[-] vepro@lemmy.world 2 points 1 year ago

It was from a GitHub Gist but idk which exactly it was, there are multiple. Keep in mind some files need to have copy-on-write deactivated (swapfile, VirtualBox disk images). The Arch Wiki mentions when copy-on-write should be turned off for a file

[-] vepro@lemmy.world 1 points 1 year ago

What do you mean with "birds part"? Learned from YouTube Videos, Arch Wiki, and experimenting on bare metal and in Virtualbox. Hardest part for me when installing Arch 1st time was partitioning and bootloaders

[-] vepro@lemmy.world 3 points 1 year ago

You might install an older kernel version from /var/cache/pacman/pkg and then regenerate the initramfs. If not using NVIDIA, it's very easy to have multiple kernels installed (e. g. linux, linux-lts) to have another option if one kernel causes trouble.

I'd generally recommend having the lts or mainline kernel additionally if you use custom kernels, like zen or self compiled

[-] vepro@lemmy.world 3 points 1 year ago

I wrote this more or less for fun; it is slightly more extensive than the installation guide geared for a more advanced setup. The wiki is mentioned in the article as well and is encouraged to be used too

[-] vepro@lemmy.world 1 points 1 year ago

The Bootloader itself cannot be encrypted afaik, but the Kernel and initrd can reside on a LUKS Volume (GRUB_USE_CRYPTODISK). But, in order to prevent having to input your passphrase twice, you need to use a keyfile, and I have no experience with that, so I have gone another route. I don't think that a kernel and initrd necessarily need to be encrypted

47
submitted 1 year ago by vepro@lemmy.world to c/archlinux@lemmy.ml

This covers obtaining the ISO, connecting to Wi-Fi, partitioning, formatting, mounting, installing, setting up encryption and installing GRUB, in one article. Also includes some tips, like quickly mounting from install medium. Maybe this helps someone.

[-] vepro@lemmy.world 1 points 1 year ago

Do you have GRUB installed into the ESPs fallback path? (esp/EFI/BOOT/BOOTX64.EFI) I haven't tried grub-install --removable yet, but maybe stuff got confused.

[-] vepro@lemmy.world 1 points 1 year ago

Had the problem only on one machine. Do you have, by chance, a MSI motherboard? Can't myself think of other causes and having the kernel and initrd on btrfs instead of ext4 can't be the problem?

7
submitted 1 year ago* (last edited 1 year ago) by vepro@lemmy.world to c/archlinux@lemmy.ml

When installing the GRUB version above, I got symbol grub_is_shim_lock_enabled not found and can't boot, so I downgraded back to grub-2:2.06.r566.g857af0e17-1-x86_64. I tried --disable-shim-lock but it didn't help. I don't secure boot and don't use TPM.

Package was pushed just 5 hours ago, anyone by chance ran into the same problem?

EDIT: Tried again today, worked. Problem was likely caused because I installed GRUB into the "arch" NVRAM entry (esp/EFI/arch) instead of the Fallback which my board only supports (esp/EFI/BOOT). To do this add --removable to grub-install. The full procedure is:

# grub-install --removable /dev/sdX ## or /dev/nvme0nX
# grub-mkconfig -o /boot/grub/grub.cfg
[-] vepro@lemmy.world 2 points 1 year ago

Maybe Guides / Information could be shown on the lemmy web frontend by default to lower the entry barrier?

117
submitted 1 year ago by vepro@lemmy.world to c/fediverse@lemmy.world

To support decentralization and spread, should lemmy.world close registration at some point to prevent a performance overload due to too many users? Of course, if registration is disabled, there could be a hint placed somewhere near that from other instances you can interact with content on lemmy.world just like you had registered on it. There could be a link to join-lemmys instance overview.

0
submitted 1 year ago by vepro@lemmy.world to c/fediverse@lemmy.world

I stumbled upon this, but I don't know how it would affect the fediverse. The integrated account migration / moving sounds interesting, but on the other hand, it seems to belong to a company rather than a standardization comitee (W3C ActivityPub). I think it should be prevented that there will be a ActivityPub and AT fediverse that are completely isolated from each other (fragmentation)

[-] vepro@lemmy.world 2 points 1 year ago

I assume that there is something that is O(N), which explains why wait time scales with community size (amount of posts, comments)

view more: next ›

vepro

joined 1 year ago