[RESOLVED] openSUSE on the Framework Laptop

Framework Laptop 13 Linux
15

I installed Tumbleweed and Wifi worked out of the box for me, no issues. Added context, I installed it with KDE Plasma, if you use a different Desktop Environment, your Wifi issues could vary.

1 Like
16

That should be unlikely as it’s kernel firmware, though some DEs may have issues with NetworkManager or wicked

1 Like
17

I was more thinking the extreme example of you decided to install Sway or i3, and those, being Tiling WIndow Managers, absolutely seem to require customization to be able to connect to Wifi.

18

I installed MicroOS (which is like 200 mb?) and it had the WiFi driver available during the installation.

2 Likes
19

KDE 5.24 has added a GUI interface for fprint, however there seems to be a bug with the device and I’d like some help confirming. Enrolling a fingerprint for a user works, however to use sudo one must set a fingerprint for the root user and this clobbers the record for any other user. I’m not sure where to go at this point.

20

You can fix this using sudoers:

https://www.reddit.com/r/openSUSE/comments/3s7wij/comment/cwv62y6/?utm_source=share&utm_medium=web2x&context=3

21

@Bundyo That would sacrifice some security. As you can see, a suse maintainer replies and explains this. I’d rather address the issue with the reader. Thanks.

1 Like
22

It depends on how your system is configured. By default openSUSE will set the root password to be the same as a user password during installation. That means if you’re on a single user system (as a laptop is likely to be) there’s really no security advantage.

Typically, I add my user to the usergroup wheel (usermod -aG wheel <myuser>), then I run sudo visudo and uncomment %wheel ALL=(ALL) ALL and comment

##Defaults targetpw # ask for the password of the target user i.e. root
##ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!

1 Like
23

These seem to be fixed as of 2/14/2022

26

I’ve created a terse guide for installing and configuring LEAP 15.3, including nice things like trackpad gestures. Enjoy.

OpenSUSE LEAP Framework Laptop Customizations

3 Likes
27

My install from today worked right out of the box with WiFi (didn’t have network during install, but the driver was there after).

28

Nice - while I want to use Tumbleweed, I appreciate you posting your infoz.
I was st0ked to read some good news about OpenSuse and the frame… I can’t wait to give it a spin. I was recently impressed by Tumbleweed; I’m an Arch user, and its pretty advanced and stable… hoping to at least give it a test drive on the Frame.work laptop.

1 Like
29

Due to the guides, etc, marking this solved as instructions were provided by the community.

30

Thanks for all the info and the steady updates - going to order a FW13 soon (Intel 13th gen or maybe AMD) and looking forward to trying openSUSE on it!

31

Hi everyone! I’ve been using OpenSUSE Tumbleweed (Gnome) since I got my Ryzen 7 Framework, and I’m loving it.
However I’ve had two issues that I wasn’t able to solve on my own (I only have some basic Linux knowledge, I basically know how to follow tutorials, and might even know what some of the commands do in the background).

  1. Sometimes the battery drains over night. It only happened twice, but I don’t know why. I think I left Signal open during that time and that may be the cause.
  2. Sometimes, the system locks the screen as if I pressed super + L and then hangs for a minute, then after closing and opening the lid it and logging in, it works again.
1 Like
32

hi @LukDeHuk ,

  1. you may want to observe battery drain behavior with upower logs
  2. try checking journalctl see if there’s kernel dump message, feels like the same behavior some users are seeing with fedora 39 beta

also make sure you’re on latest BIOS version for AMD, BIOS 3.03 of this writing.

1 Like
33

Already updated that, my Framework was kinda unusable before that. I only had to look at the iGPU and it crashed. But that’s working really well now! I upgraded while it was still a beta, but the version is the same so I don’t have to do it again, right?

I found how to read them out (/var/lib/upower/history-*) but I’m not sure how to interpret them.

I couldn’t find kernel dumps in the last few days when some of the issues arose, but VSCodium did dump a few times, maybe somethings up with that. I’ll investigate further. I didn’t log when I had what issues, so I can’t really compare the output from before a few days ago yet, but I’ll keep it in mind for the future.

Thanks!

EDIT:
Ok so I just had the issue again, went to bed at around 4 in the morning and woke up at around 12, battery went from 68% to 22%. upower doesn’t show anything in that timeframe, but journalctl does:

Nov 04 03:41:52 SusFrame systemd[1]: Reached target Sleep.
Nov 04 03:41:52 SusFrame systemd[1]: Starting System Suspend...
Nov 04 03:41:52 SusFrame rtkit-daemon[2466]: Successfully made thread 2833 of process 2798 owned by 'LukDeHuk' high priority at nice level 0.
Nov 04 03:41:52 SusFrame rtkit-daemon[2466]: Successfully made thread 2833 of process 2798 owned by 'LukDeHuk' RT at priority 20.
Nov 04 03:41:52 SusFrame systemd-sleep[1639]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend
Nov 04 03:41:52 SusFrame systemd-sleep[1633]: Entering sleep state 'suspend'...
Nov 04 03:41:52 SusFrame kernel: PM: suspend entry (s2idle)
Nov 04 03:41:52 SusFrame kernel: Filesystems sync: 0.023 seconds
Nov 04 12:03:24 SusFrame kernel: Freezing user space processes
Nov 04 12:03:24 SusFrame kernel: Freezing user space processes completed (elapsed 0.002 seconds)
Nov 04 12:03:24 SusFrame kernel: OOM killer disabled.
Nov 04 12:03:24 SusFrame kernel: Freezing remaining freezable tasks
Nov 04 12:03:24 SusFrame kernel: Freezing remaining freezable tasks completed (elapsed 0.092 seconds)
Nov 04 12:03:24 SusFrame kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 04 12:03:24 SusFrame kernel: queueing ieee80211 work while going to suspend
Nov 04 12:03:24 SusFrame kernel: ACPI: EC: interrupt blocked
Nov 04 12:03:24 SusFrame kernel: amd_pmc AMDI0009:00: Last suspend didn't reach deepest state
Nov 04 12:03:24 SusFrame kernel: ACPI: EC: interrupt unblocked
Nov 04 12:03:24 SusFrame kernel: [drm] PCIE GART of 512M enabled (table at 0x000000801FD00000).
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resuming...
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!
Nov 04 12:03:24 SusFrame kernel: nvme nvme0: Shutdown timeout set to 8 seconds
Nov 04 12:03:24 SusFrame kernel: nvme nvme0: 12/0/0 default/read/poll queues
Nov 04 12:03:24 SusFrame kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully.
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
Nov 04 12:03:24 SusFrame kernel: amdgpu 0000:c1:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
34

I just installed openSUSE Tumbleweed on my Ryzen 7 FW13. I’m absolutely loving it so far!

I haven’t really had time to use it much at all (still use my old laptop for work) or to do some more detailed setup. I will actually wipe the current install and start over because I did not enable disk encryption the first time around. Since I’m new to Tumbleweed I wanted to give it a little spin before putting any thought into the actual install.

So far I just installed the BIOS updates, updated fingerprint FW and tried if this runs at all. And after reading about all the woes people have with docks, graphical glitches, crashes, battery drain, video playback etc. I expected to be in for a rough ride. And… nothing. This just works! All three USB-C docks I have (two DELL screens with integrated docks and one from I-TEC) work (with PD, USB hub, network, display). I haven’t tried them at the same time tough as they are on different desks. I did have a crash after logging in in a dual-monitor setup, unplugging USB-C and then logging out, but I chalk that up to sddm or Plasma Wayland.

As for battery drain, this still needs to get better, but it is very usable as is for me. I haven’t done ANY tuning whatsoever, so what I see is in line with previous experience. I’ve never had a laptop that provided great battery life in Linux without at least a little tweaking.

As a side note, it’s funny to be back to SUSE. I started daily driving Linux with SUSE (5.3?) 25 years ago (happy days when KDE 1.0 arrived), but I haven’t used any of their distributions in the last 20 years or so.

@LukDeHuk If I get a chance tomorrow, I’ll have a look at my journalctl and upower logs after a night of suspend. But in the few days I’ve had the laptop, I haven’t seen the high drain in suspend you report, so I doubt I can be of much help.

35

Battery went from 64 to 58% during 10h suspend this night. Extrapolating (which won’t work, I know) that would mean almost a week in suspend to go from 100% to 0%. I can live with that.

My journalctl looks very much like yours, @LukDeHuk, plus some Wayland messages. Haven’t looked at upower.

36

Running openSUSE on my 12th gen, and without having checked numbers yet, I think I must be seeing high drain on suspend because I can never leave it suspended for more than one day without the battery draining completely. Any hints on what I should be looking for with upower?