[GUIDE] Tips for getting openSUSE fully up and running

Despite openSUSE not being one of the distros that was officially tested by the Framework team, it works surprisingly well on the Framework. There were just a couple of things that I needed to do to make openSUSE work as it should.

DISCLAIMER:

This is not a full out guide explaining how to set up openSUSE. It is only a mini-guide designed to explain the few things I needed to do to get full functionality on the Framework.

Pastebin containing all the sources I mentioned in my guide:

  1. Enabling the fingerprint sensor:
    Out of the box, openSUSE does not include the required packages for fingerprint
    functionality, and they need to be installed. You can install them by running:
    sudo zypper in libfprint-2-2 fprintd fprintd-lang fprintd-pam
    in the terminal.
  • Then you just need to run this command to complete the setup:
    pam-config --add --fprintd

  • Without even needing to log out or reboot, fingerprint authentication should be available right away within KDE System Settings, within the user section.
    (Credit to Framework Community Member “Fabian_Herschel” for providing some initial instructions on how to do this. I just modified their instructions a bit, to make it a bit easier to understand what the exact commands are that you need to run, in order to get fingerprint functionality working.)

    Note: If in the future you end up running into issues adding fingerprints, the fingerprints stored on the fingerprint sensor itself have most likely become corrupted is some way. I have noticed that not only does the “fprintd-delete” command not actually delete the fingerprints stored in your fingerprint sensor, but that corrupted fingerprint data persists across reinstalls of openSUSE, or even two different Linux distros too. Fortunately I was able to find a little python script that is designed to actually delete the fingerprints from the sensor itself, and after I ran that, the sensor worked fine again.

    Here’s how you run it:

    I: First go to the libfprint link in my sources pastebin

    II: Then copy the code found in the part of the issue that the link takes you to

    III: You then need to open a text editor and paste that code into there, and save it as anything.py

    IV: Right click on the program in your file manager, and go to properties

    V: check the “allow executing file as program” box

    VI: Then right click within any blank space within file manager, making sure you are currently in the same directory as the anything.py file you created, and click the menu item that says something like “open terminal here”

    VII: Run: sudo ./*anything*.py

    VIII: The program will now go about actually wiping the stored finger prints off of your fingerprint sensor. If all goes well, hopefully the next time you try to enroll your fingers, it will work!

Credit to Framework Community member @Bob_U, for showing this solution in a comment in another post a while back, as well as Benjemin Berg on Gitlab for writing the python script.

  1. Auto brightness functionality:
    I am pretty sure auto brightness works out of the box on openSUSE, but
    honestly I couldn’t really tell.
  • Just make sure that the
    iio-sensor-proxy
    package is installed.

  • I recommend just running
    sudo zypper in iio-sensor-proxy
    just to be safe.

  • If it does end up being installed already, zypper will say so.

  • If the package did end up needing to be installed, I would recommend rebooting after the package is done installing.

  • If it was already installed, or you have rebooted after installing it, then it is time to check if it is working.

  • This can be done by running:
    udevadm info --export-db | grep iio
    in the terminal.

  • If you see an output like this you should be good to go (it might not be exactly like this example, mine wasn’t):

P: /devices/platform/80860F41:04/i2c-12/i2c-BMA250E:00/iio:device0
N: iio:device0
E: DEVNAME=/dev/iio:device0
E: DEVPATH=/devices/platform/80860F41:04/i2c-12/i2c-BMA250E:00/iio:device0
E: DEVTYPE=iio_device
E: MAJOR=249
E: MINOR=0
E: SUBSYSTEM=iio
E: SYSTEMD_WANTS=iio-sensor-proxy.service
E: TAGS=:systemd:
E: USEC_INITIALIZED=7750292

(Credit to Telegram user “Arief” in the KDE telegram group for helping me with
this, as well as Framework Community member “dossman”.)

  • Check the “sources” pastebin to see where I was able to confirm that auto brightness was working.

Since writing that first section, I have learned some things. Even if you have iio-proxy is installed, KDE won’t use it, because I don’t think KDE officially supports auto brightness, unlike Gnome which I think does support auto brightness out of the box. Fortunately a Framework Community user made a very nice script that gets auto brightness working quite well in KDE. Thats what I will be going over now.

  1. (Part 2) Enabling Automatic Brightness Control in KDE:
  • First go to the GitHub link for the Auto Brightness script found in my “sources” pastebin, and click on the code button, and click download zip.

  • Then extract the zip, and copy the “AutomaticBrightness.sh” file to a safe location on your computer.

  • Next you need to open Settings, and go to Startup and Shutdown/Autostart/ and then add a login script. Choose the script you in the previous step.

  • You then are going to open up the terminal, as there is a package we need to install.

  • Once the terminal is open run
    sudo zypper in brightnessctl

  • We need brightnessctl because the script relies on it to adjust your screen’s beightness.

  • After the package is installed, you need to log out and back in. If all goes well, you should have auto brightness functionality within KDE!

Thanks GitHub user “steel99xl” for creating the script that allows for this.

  1. Enabling Brightness Hotkey Functionality:
    Note: It is currently not possible to have working auto brightness, and working brightness keys at the same time. From what I understand, Framework would have to release a driver to allow both to work at the same time, which does not currently exist for Linux at the moment unfortunately. The Framework has a compound device that handles auto brightness, and the functionality of the brightness keys. Linux doesn’t know how to handle this type of situation as of yet.
  • Open a terminal and enter:
    sudo nano /etc/modprobe.d/framework-als-blacklist.conf

  • Then add this line to the file:
    blacklist hid-sensor-hub

  • Restart your machine. Brightness hotkeys should now work!

(Credit to Framework Community member “dossman” for helping me out with this, and pointing me in the right direction, and thanks to Framework Community Member “Kieran_Levin” for actually providing the information needed to fix the issue with brightness hotkeys.)

  1. Improving sound quality of Framework Laptop:
    Out of the box the Framework sounds pretty alright, but it can sound so much better with the help of an audio preset. Of course, the Framework community being as awesome as it is, has made a few that work really well. I will tell you how to set them up.
  • First you need to install a program called EasyEffects which will allow you to take advantage of these audio presets. It can be found in my “sources” pastebin. The like I provided will take you to the project’s GitHub, just scroll down and click on the flatpak link, and go about installing the flatpak of EasyEffects. Unfortunately, libadwaita is very baked into it, meaning it looks very out of place in KDE, but until I figure out a KDE alternative, it is the best there is.

  • After EasyEffects is installed, head back to my “sources” pastebin, and click on the link for the Framework audio presets. This will take you to the GitHub of the Framework audio presets project. Once there, you then need to click the green “code” button and choose the “download zip” option.

  • Once the zip is downloaded, you need to extract it.

  • Once it is extracted, you need to open the “EasyEffects” program. If it isn’t visible, then you need to either log out and back in, or if that doesn’t make it appear, then you might need to restart. Flatpaks don’t show up without you re-logging in a lot of the time. Alternatively, if you don’t want to log out, you can run this terminal command to launch the program:
    flatpak run com.github.wwmm.easyeffects

  • Once the program opens, you then need to load in the audio preset of your choosing. While I think they all sound better than the stock speaker output, I personally think the two best ones are lappy_mctopface.json and philonmetal.json. Out of those two I personally prefer the former. Lappy was designed for when you were using your laptop on your lap (as the name might suggest), but I think it is the best overall.

  • To load the preset in, you just need to go to the “Presets” drop-down menu within EasyEffects, and choose your preset of choice. Once opened, just press the “load” button within the “Presets” drop-down to start using it.

  • Next play some audio to test it out! Hopefully it sounds much better to you than the stock sound output did. I know I said what my preferred presets were, but you should honestly test them all out, and see what one(s) suit you best. In my opinion they all sound better than the stock output.

  1. (Part 2) Keeping the effect running in the background:
    Now that the effect is set up, you probably would like to keep it running in the background most likely permanently, so you don’t have to worry about it anymore.
  • Click on the “3 dot menu” on the right side of the title bar, and click preferences.

  • First enable “Launch Service at System Startup”, to allow the effect to take place on boot.

  • Then disable “Shutdown on Window Closing”, so you can keep it running with EasyEffects closed.

  • Then close preferences, and head over to the “PipeWire” tab.

  • First thing to do is to disable the option to use the “Default Input”, and to set the built in speakers to to be the device that the program applies the effect to. If you don’t do this, then the effect will be applied to the current audio device in use, and I can imagine that wouldn’t be all too desirable when you are using headphones/earbuds instead.

You should be good to go! I hope you enjoy improved sound quality on your framework! The difference obviously ain’t gonna blow you away, but it is improved quite a bit, I think anyway. Out of the box I thought the Framework sounded alright to smash music out of when working or something, but now it sounds even better and clearer for that use case, which is nice.

(Credit to GitHub user “ceiphr” for creating the presets, and to GitHub user “wwmm” for creating EasyEffects. Lastly, thanks to the Framework community for allowing me to find the information on how to do this. Regrettably I forget which user exactly was the one to talk about these presets, and for that, I’m sorry. If you would like, please tell me if that was you in the comments.)

A couple non-framework specific, quality of life (in my opinion, anyway) improvements to do as well:

  1. Graphical/Display Settings:
    I personally recommend that you use Wayland over X11. Wayland may be a bit more buggy than X11 true, but on a laptop like the framework, it’s your best bet.
  • Not only is Wayland’s fractional scaling better than X11’s, but you get access to native touchpad gestures as well.

  • As for the scaling of the display, I recommend scaling the Framework’s display to 160%, anything less is just too small in my opinion.

  1. Recommended utility to improve battery management:
    OpenSUSE comes with TLP for battery life management by default, which works well and all, but I honestly recommend that you switch it out for auto-cpufreq instead. It does a better job, I think, at least from the times I’ve used it, and you don’t give up turbo boost either. From what I remember, I am pretty sure you lose turbo boost with TLP, but I could be wrong.

    Setting up auto-cpufreq:
    Note: I know there is a snap package of auto-cpufreq available, but I honestly do not like snaps, so I will not be going over how to install the snap. But if you want to go ahead and install snap support on openSUSE, and then install the auto-cpufreq snap feel free.

  • You can get auto-cpufreq from from the correct link in my “sources” pastebin.

  • The latest version available here is quite a bit outdated. Thanks to the help of an openSUSE user in the openSUSE Discord/IRC/Matrix group, I was able to build an up-to-date RPM of the auto-cpufreq package, it can be from the corrent link in my “sources” pastebin.

  • It needs to be installed via YAST or the terminal, as there are a few minor errors in some of the checking systems in the package, making discover not want to install the package.

  • I’d recommend installing the package using YAST. In KDE, YAST is not the default option for installing RPMS. To make YAST open an RPM, you need to right click on the RPM, and YAST should be an option under the “Open With” submenu.

  • YAST will begin to install the RPM, as it is doing so, an error will most likely appear. This error isn’t important and can be ignored. The package will install and function just fine despite the error.

  • Next open a terminal. The first thing that needs to be done is uninstall TLP so it doesn’t interfere with auto-cpufreq. This can be done with:
    sudo zypper rm TLP
    Reboot your laptop just to be safe.

  • Then we can enable auto-cpufreq with:
    sudo systemctl enable autocpu-freq && sudo systemctl start autocpufreq

  • Next check if it is running with:
    auto-cpufreq --monitor

  • If you get an output from this it’s working! You can then quit the monitoring process with CTRL+C. Doing this will not stop auto-cpufreq.

You now have a bit of a better battery management service on your Framework than what openSUSE comes with!

I hope that this guide was able to aid you in getting openSUSE up and running on your Framework device. If you have any questions/suggestions feel free to comment them below.

10 Likes

Thanks for the tips! I was just thinking about installing OpenSUSE TW. Currently running Arch but it seems isn’t the cutting edge they claim it is, they are still running gnome 42. OpenSUSE, Fedora, and even Ubuntu are already there :). Will be moving soon to OpenSUSE.

1 Like

@Ricardo I updated the guide to explain how to get improved speaker sound qualiy, if you wanna check it out.

Also its kinda odd that Arch doesn’t have gnome 43 yet, lol.

Thank you for your comment too btw.

1 Like

There is a type in fprintd in this line.

I’ll check out the audio stuff, thanks!

I’d also suggest just blindly nabbing the entire fonts pattern, and grabbing opi or zyp/zow(when it’s finished), the latter tools allow you to interact cleanly with the OBS.

I’d also recommend, heavily, grabbing packman as well.

@Senhara Again this wasn’t supposed to be a full guide. Just things specific to the Framework for the most part.

@Ricardo Thx.

Hi! I was running openSUSE for a while, then switched to Kubuntu for a bit. Now I am trying to reinstall openSUSE TW but am having trouble getting the installer to load on boot. I keep getting punted to a screen where I am told that the installer can’t find the repo, and to try and re-enter the URL. It seems like this is caused by a lack of ability to pick up my network card, and the installer isn’t loading the network module correctly. Interestingly, when I use a much older ISO, (on kernel 5.12) the same issue happens. If anyone had an ISO from kernel 5.18/19 sitting around I could give that a try to see if it is a kernel issue. Anyone have any ideas for how to resolve the issue?

1 Like

@Isaac_Peetoom_Heida Could it just be an issue with the installer? Have you tried using the offline installer? I have an offline installer with Snapshot20221029 that I used and I was able to connect just fine after installation.

@slothlike when I tried with the offline installer, the installer also failed to pick up my network card. Interestingly, when I tried the Krypton live image, it picked up the network card and showed my wifi network, but wouldn’t let me connect. If the offline image doesn’t seem to ship with the drivers required to pick up the network card, is it still a good idea to install?

@Isaac_Peetoom_Heida Right I should have clarified, when I tried the offline installer, it failed to recognize the network card but once it was installed it worked just fine. It also seems I’m not the only one:

That’s why I said it could just be a bug or issue with the installer itself. That being said, I’m not completely sure with the current version of the installer so I can’t say anything for certain.

3 Likes

@slothlike replying to you from my fresh install of openSUSE. Thanks for the help!

2 Likes

@Isaac_Peetoom_Heida I am sorry I wasn’t able to help, (like a lot of my projects I can never stick to them, this guide included :sweat_smile:), but I am glad you were able to get help! Thanks @slothlike.

I am now back on fedora after coming to the unfortunate realization that a large number of rpm packages out there favour RHEL distros over SUSE ones, but I still like openSUSE, and I am going to polish off this guide a bit more and hopefully keep up with the comments a bit better too!

Could you specify whether this post is for Tumbleweed or Leap in the title?

Hi, I have a few questions.

  1. Is the fingerprint setup still needed with Tumbleweed? In the Fedora 38 guide it’s not needed anymore but it was in Fedora 37. Furthermore, the openSUSE Wiki says that fingerprinters should be detected automatically.

  2. For enabling the brightness hotkeys the guide written by the OP recommends adding blacklist hid-sensor-hub to /etc/modprobe.d/framework-als-blacklist.conf. Meanwhile, the Ubuntu guide*, the Mint guide* and the Manjaro guide* say to add GRUB_CMDLINE_LINUX_DEFAULT="quiet splash module_blacklist=hid_sensor_hub" to /etc/default/grub, followed by sudo grub-update. The Fedora guide instead uses the command sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub". So there’s three different approaches, what’s the correct one for openSUSE, or do they all work?

  3. The Ubuntu, Mint and Manjaro guides also recommend adding GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme.noacpi=1" to /etc/default/grub, followed by sudo grub-update, for less battery drain from the SSD when suspending. For Fedora the guide instead uses the command sudo grubby --update-kernel=ALL --args="nvme.noacpi=1". This is missing from the OP’s guide, but as all other distros seem to need manual intervention I would assume that’s also the case for openSUSE, or does it automatically use the right battery-saving setting?

  4. The Ubuntu, Mint and Manjaro guides - but not Fedora! - furthermore recommend adding wifi.powersave = 2 to /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf in order to prevent Wifi dropoffs. Is this needed for openSUSE (specifically Tumbleweed) or does it “just work” like it apparently does on Fedora?

'* sorry, I had to remove the links because I am a new user and not allowed to use links for some silly reason! Just follow the link to the Fedora guide and then on the left you’ll see the Ubuntu/Mint/Manjaro guides.

Hi OP here. I unfortunately have switched to just using Arch on all of my systems so unfortunately I am not quite in the loop anymore of the status of how things work in openSUSE anymore unfortunately. As for that thing about improving SSD battery drain, I honestly just didn’t know that option existed. Thanks for bringing it to my attention though because it is something I actually kind of want to use now.

Linux Support Lead here. We have not vetted any distro not appearing on the Linux page. And this explains what all of this means.

It’s been a minute since I have run OpenSUSE myself. Running GRUB, I would emulate the Fedora guide (and the grub methods mentioned). Then after adding to grub config, grub2-mkconfig -o /boot/efi/EFI/grub.cfg

Basically repeat to match Fedora 37/38 guides.

Power save changes should not be needed on newer kernels (guides to be updated on that), but if you experience dropping of wifi, use them.

EasyEffects now has a package in zypper.
Also after running pam-config --add --fprintd,
I get:

WARNING: module /lib/security/pam_fprintd.so is not installed.

Some searching makes led me to bugs reported on a redhat forum and an openSuse forum. The recommended fixes did not work for me, wondering if anybody ran into anything similar.