simon.schönbeck.dk

  • Persist Asus battery charge limit after reboot on Fedora

    Despite many issues reported over the last years about this problem, as of Fedora Kinoite 44 on kernel 7.1.3 with KDE Plasma 6.7.2 it is still not possible to persist the battery’s maximum charge limit upon a reboot. To be fair it is mainly due to the laptop manufacturers’ way of resetting the value to 100% charge level upon each boot.

    Having to remember and set this value upon each boot may seem like no task but it becomes a real nuisance after each update. Running Fedore Kinoite means that a reboot is needed after each system upgrade so it happens more often than perhaps in the past when only a kernel upgrade needed a reboot.

    In this scenario the 2024 Asus TUF laptop does accept custom set charge limits providing plenty of flexibility for multiple use cases. I would usually set it at 50% level unless the laptop is needed on batteries later where it can then be raised to 80% prior to leaving AC power. This should ensure future battery health for many years.

    The “Charge Limit” value is set inside the “Power Management” settings under “Configure Advanced Settings” in the top right corner. I would guess each laptop would have different options depending on what the hardware exposes to the system. By default the value is 100% after boot so simply change it to the value you desire. You will be asked to authenticate as it is a system wide setting.

    Avoiding this cumbersome task is rather simple though. Until it gets fixed we can just set the charge limit programmatically upon each boot. There are several ways to skin the cat so the following is in my opinion the simplest and cleanest one. Using the tmpfiles.d service we can do this pretty fast (if curious there are many systemd-tmpfiles uses).

    First we can actually check the current battery charge limit value (please note BAT0 may instead be BATn on your device, usually 0-4):

    $ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
100

    Then let us set and get the new value through here instead of using the GUI:

    $ echo 50 > /sys/class/power_supply/BAT0/charge_control_end_threshold
$ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
50

    This would work fine for a quick change but now we will create the instructions to tmpfiles to do it at boot instead:

    $ sudo vim /etc/tmpfiles.d/asus-battery.conf
$ cat /etc/tmpfiles.d/asus-battery.conf
# Type  Path                                                 Mode UID  GID  Age Argument
w-      /sys/class/power_supply/BAT0/charge_control_end_threshold -    -    -    -   50

    The formatting needs to be as is, so please bear in mind that depending on the width of your screen it may not be displayed properly right here, so if you copy and paste the content into a text editor it would be easier to see. The first line is just a comment for reference so you get the idea of each column, the real action happens in the second line. Here the value of 50 is written into “/sys/class/power_supply/BAT0/charge_control_end_threshold” just as we did manually before.

    After next reboot the system will automatically change the charge limit, to 50% in this case. Obviously just change this value to the desired default. Please note that you can always later modify temporarily the limit in the GUI settings as shown earlier. This last change would apply until next reboot only.

  • AppImages require FUSE to run in Fedora Kinoite 44

    When running the latest VictronConnect Linux AppImage (v6.34) on Fedora Kinoite 44 an error is reported and it fails to launch:

    dlopen(): error loading libfuse.so.2

    AppImages require FUSE to run.  
    You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option.  
    See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information

    Fedora actually came by default with both FUSE 2 and 3 but since version 44 FUSE 2 is no longer included due to security concerns.

    The option to run this AppImage and any other for that matter is to run it with the “–appimage-extract-and-run” parameter. This would simply extract its content directly on disk and delete it afterwards. Usually it would have run inside the FUSE virtual file system:

    $ Downloads/VictronConnect-x86_64_v6.34.appimage --appimage-extract-and-run

    The real solution would be for the Victron developers to use the latest AppImage which has FUSE 3 built-in.

  • EU Stars On My Passport (STAR-PASS)

    If you are a European Union citizen you may be interested in this initiative.

    After harmonising and integrating several important aspects in the EU I have always looked forward to when we will get a common EU passport. It is true that the burgundy red theme runs in most EU countries, however all passports still have each member’s national design.

    Now the STAR-PASS initiative tries to bring it up to the European Commission for review and implementation. All the details are well explained in the website so no reason to repeat them, but in summary it is meant to be an alternative option to the ordinary burgundy passport, that is, the citizen can choose the design when ordering the new passport.

    In my own view it should be the only option available, eliminating national designs altogether, but there are always reticent citizens, so at least having the two options is the fairest compromise.

    Ultimately this initiative does not eliminate national citizenships for only the common EU citizenship which already exists. It is purely a cosmetic change of the passport.

    You can sign the initiative by following the aforementioned link or directly on the European Comission’s petition collection website

    I used the eID option so did not have to input any data, just sign through electronic means.

  • Google Earth – Another instance of this application is already running

    Being unable to launch Google Earth Pro because it thinks it is already running seems to be happening frequently for me. I am using the Flatpak version if it matters.

    Despite killing the application there is still a lock file lingering preventing Google Earth Pro to launch. The error message is specifically:

    Google Earth
    Another instance of this application is already running.

    To launch Google Earth again you need to delete this stale lock file which is inside your user directory:

    rm -v $HOME/.var/app/com.google.EarthPro/.googleearth/instance-running-lock

    Once gone Google Earth Pro will run again without complaining.

  • Fedora Thunderbird Flatpak wrong file association

    I struggled for a while with jpg image files not properly opening with the “System Handler” in Thunderbird. Despite changing the file association setting back to “Always ask” to reset it, the wrong application opened the images.

    Usually one would just select another application in the list of applications but since it is a Flatpak the sandbox restricts access and none where displaying.

    Fiddling around I deleted the second order in the chain where Thunderbird Flatpak searches for the right application to open (after the handlers.json):

    rm ~/.var/app/net.thunderbird.Thunderbird/config/mimeapps.list

    After a restart the “System Handler” finally opened up the correct application as it was using the third level in the lookup chain, the XDG Desktop Portal, which gracefully forwarded the request to Loupe in this case.