Entering the card name into a search engine and adding "Linux" gives some useful results, for example:

https://linux-hardware.org/index.php?id … -17aa-c024

Devuan's stable release is currently on kernel 5.10 so you should be fine as long as you install the firmware for the card.

I can't reproduce this in a fresh system (QEMU/KVM, chimaera netinstall upgraded to daedalus):

empty@devuan:~ $ grep efivars /etc/fstab /proc/self/mounts
/etc/fstab:efivarfs /sys/firmware/efi/efivars efivarfs ro 0 0
/proc/self/mounts:none /sys/firmware/efi/efivars efivarfs ro,relatime 0 0
empty@devuan:~ $ doas efibootmgr --create --label 'testing...' --loader 'test.efi' --disk /dev/vda
Could not prepare Boot variable: Read-only file system
5|empty@devuan:~ $ doas mount -o remount,rw /sys/firmware/efi/efivars                                     
empty@devuan:~ $ grep efivars /proc/self/mounts                                                           
none /sys/firmware/efi/efivars efivarfs rw,relatime 0 0
empty@devuan:~ $ doas efibootmgr --create --label 'testing...' --loader 'test.efi' --disk /dev/vda        
BootCurrent: 0006                             
Timeout: 0 seconds
BootOrder: 0007,0006,0000,0001,0005,0002,0003,0004
Boot0000* UiApp
Boot0001* UEFI QEMU DVD-ROM QM00003 
Boot0002* UEFI Misc Device
Boot0003* UEFI PXEv4 (MAC:525400123456)
Boot0004* UEFI PXEv6 (MAC:525400123456)
Boot0005* EFI Internal Shell
Boot0006* debian
Boot0007* testing...
empty@devuan:~ $ doas efibootmgr -b 7 -B
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0006,0000,0001,0005,0002,0003,0004
Boot0000* UiApp
Boot0001* UEFI QEMU DVD-ROM QM00003 
Boot0002* UEFI Misc Device
Boot0003* UEFI PXEv4 (MAC:525400123456)
Boot0004* UEFI PXEv6 (MAC:525400123456)
Boot0005* EFI Internal Shell
Boot0006* debian
empty@devuan:~ $ doas mount -o remount,ro /sys/firmware/efi/efivars
empty@devuan:~ $ doas efibootmgr --create --label 'testing...' --loader 'test.efi' --disk /dev/vda        
Could not prepare Boot variable: Read-only file system
5|empty@devuan:~ $ grep efivars /proc/self/mounts                                                         
none /sys/firmware/efi/efivars efivarfs ro,relatime 0 0
empty@devuan:~ $ grep efivars /etc/fstab
efivarfs /sys/firmware/efi/efivars efivarfs ro 0 0
empty@devuan:~ $

I do see an error message about /sys/firmware/efi/efivars being already mounted so I presume that comes from mountkernfs.sh because the  NVRAM variables are inaccessible but also re-mountable using the efivarfs identifier.

Can anybody else reproduce this?

EDIT: @rolfie: are you using the stock daedalus kernel? Which init system is this?

lol

Cheers.

Just a simple "HoaS thinks this bug might be relevant — can you get to the desktop with `startx` from a console login?" will suffice. @sunrat is a smart cookie so I'm sure they can take it from there.

EDIT: does your Pale Moon version carry the original branding?

That is categorically not true for OpenBSD. As blackhole has already mentioned the only non-free component of any OpenBSD system is the firmware, which is downloaded from http://firmware.openbsd.org/firmware/ by fw_update(8). The firmware is *not* part of the kernel and can only be downloaded after installation.

I only had to write the values once, for example:

# tee /sys/class/power_supply/BAT0/charge_control_start_threshold <<<"49"
# tee /sys/class/power_supply/BAT0/charge_control_end_threshold <<<"51"

^ That pins the battery between 49-51%, which results in it being bypassed once the battery is half full (or half empty, if you prefer).

Those values only change when I boot Windows. Otherwise the charge control ECU maintains the values set from Linux.

EDIT: as the OP is a Windows refugee they might appreciate this GUI that allows D-Bus control of charging thresholds by non-root users:

https://gitlab.com/wincak/threshy-gui

Backend here: https://gitlab.com/wincak/threshy

Might only work on ThinkPads though.

Debian is over 20 years old now and has never, in all that time, included any proprietary video drivers in an official release. What makes you think that will change any time soon? And why do you describe it as "odd"? Supplying proprietary drivers is expressly forbidden by Debian's Social Contract.

Don't use deb.multimedia.org, that place is poison for a clean De{bi,vu}an system.

Just download the cdemu tarball from upstream, unpack it, then run debuild -us -uc in that directory to build the .deb. The tarball contains a functional debian directory.

No. The options should be separated with a space, like this: quiet noefi.

Let's try

ls /etc/init.d/

That is confusing. I also mount efivarfs read-only with an fstab line in my Alpine Linux system and it works just fine there. I don't suppose that helps you though.

I think you might need to specify the filesystem type:

# mount -t efivarfs -o remount,ro /sys/firmware/efi/efivars

If that doesn't work then check dmesg, as suggested in the error.

Don't do that.

Soname bumps are a "feature" of the development branches. If you don't know how to handle them correctly then you probably shouldn't be using those branches.

Relevant bug report: https://bugs.debian.org/cgi-bin/bugrepo … ug=1024687

Should be fixed soon so revert that "fix", downgrade the relevant packages and wait.

Quite a few of them run Ubuntu, actually

There are other reasons: Windows doesn't allow edge scrolling with the touchpad; it doesn't have a PRIMARY clipboard (select the text to copy then middle-click to paste); amdgpu doesn't work so AMDGPU-PRO has worse framerates, runs hotter & drains more power; I can't see any of the source code. Under Linux I can see

archie:~$ ls /sys/class/power_supply/BAT0/charge_*
/sys/class/power_supply/BAT0/charge_behaviour
/sys/class/power_supply/BAT0/charge_control_end_threshold
/sys/class/power_supply/BAT0/charge_control_start_threshold
/sys/class/power_supply/BAT0/charge_start_threshold
/sys/class/power_supply/BAT0/charge_stop_threshold
archie:~$ cat /sys/class/power_supply/BAT0/status
Not charging
archie:~$

^ Setting those values allows me to fix the charge rate to 50% battery so I can leave the laptop plugged in (for best games performance) without wrecking the battery with continuous charge/discharge cycles.

This laptop is a few years old now:

archie:~$ cat /sys/class/power_supply/BAT0/cycle_count
59
archie:~$ cat /sys/class/power_supply/BAT0/energy_full_design
50450000
archie:~$ cat /sys/class/power_supply/BAT0/energy_full
50070000
archie:~$

Most of that damage was done by bloody Windows

I haven't tried 11 but I've had a few Windows 10 systems running for quite a while in that state, both bare metal & virtualised.

Why are you trying to steal this? Just buy the game on Steam or GOG. I won't help you pirate stuff.

Nice card :-)

I should have asked for vulkaninfo --summary but nevermind. Looks like VA-API, VDPAU-API, Vulkan & OpenGL are all supported.

Looks like Cinnamon might not have such an option. How silly. Do you see the artefacts with, for example, plain openbox?

Upload the image to https://postimages.org/ and paste the "thumbnail for forums" URL here.