December 2018 - openSUSE Support - openSUSE Mailing Lists

[opensuse-support] fwupd problems on DELL XPS 13
by mh＠mike.franken.de 17 Dec '18

17 Dec '18

Hi *, I got a new DELL XPS 13 9370 up and running with openSUE Tumbleweed. Because of problems with the Atheros wifi device I want to update the BIOS. Running "fwupdmgr get-devices" gives "/usr/lib/fwupd/efi/fwupdx64.efi.signed cannot be found", though. The same messages occurs when restarting the fwupd daemon. Running the update with "fwupdmgr refresh" and "fwupdmgr update" gives: No upgrades for XPS 13 9370 Thunderbolt Controller, current is 33.00: 33.00=same, 28.00=older ignoring XPS 13 9370 System Firmware [8a21cacfb0a8d2b30c5ee9290eb71db021619f8b] as not updatable So the update of the Thunderbolt controller had succeeded in a previous run, but the firmware update itself does not run. I read a lot of things on the internet, but couldn't find a solution. One thing I read was to sign fwupdx64.efi with sbsign. This utility can be found in the sbsigntools package with was not included in one of the standard Tumbleweed repos. So I installed it from an openSUSE developer repo. Unfortunately I don't know what cert and key files to use for signing. So the questions are: 1. How to do a BIOS upgrade with fwupd in Tumbleweed the correct way? 2. If signing fwupdx64.efi is the correct way, what cert and key file to use? TIA. Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

3 7

[opensuse-support] Decrease number of snapper snapshots
by Maximilian Trummer 15 Dec '18

15 Dec '18

The btrfs wiki says: "qgroups with many snapshots slows down balance" [1]. According to this bug report [2] and also my own experience, btrfs balance can slow down the system to the point of freezing. Since snapper leaves 2-10 regular and 4-10 important snapshots and using YaST as well as zypper also creates a new one each time, you can easily end up with 20+ snapshots, leading to the freezes. Now my question, is it safe to set NUMBER_LIMIT="2-5" (instead of "2-10") and NUMBER_LIMIT_IMPORTANT="4-7" (instead of "4-10") in /etc/snapper/configs/root? As I understand the issue, this should alleviate the freezing issue a little until it's fixed for good. [1] https://btrfs.wiki.kernel.org/index.php/Status [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1063638 regards

2 1

[opensuse-support] 2018-2019 Board Elections underway
by Fraser_Bell 13 Dec '18

13 Dec '18

PLEASE: Do not reply on this list. Post all replies or comments on the openSUSE Project mailing list. This announcement, only, is meant to reach most lists as it involves Project Guidance and Future. 2018-2019 Board Elections underway. Call for Candidates. Membership Drive <url>https://news.opensuse.org/2018/12/13/2018-2019-elections-underway-with-call…</url> -- -Gerry Makaro openSUSE Board Elections Committee (election-officials **at** openSUSE.org) openSUSE Member openSUSE Global Moderator openSUSE Contributor YaST Contributor aka Fraser_Bell on the Forums, OBS, IRC, and mail at openSUSE.org Fraser-Bell on Github -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

1 0

[opensuse-support] TW fails compatibility with amdgpu graphics driver
by George from the tribe 07 Dec '18

07 Dec '18

After my tumbleweed upgrade last week, I am no longer able to boot into my system unless I use the 'nomodeset' configuration. In that case, I cannot get into a graphical target at all. This has only happened since the kernel upgrade to 4.19. Here is my hardware information # hwinfo --gfxcard 23: PCI 300.0: 0380 Display controller [Created at pci.378] Unique ID: svHJ.+ug88O0PpPA Parent ID: w+J7.XZwpGIabNM5 SysFS ID: /devices/pci0000:00/0000:00:03.1/0000:03:00.0 SysFS BusID: 0000:03:00.0 Hardware Class: graphics card Model: "ATI Baffin [Radeon RX 460]" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x67ef "Baffin [Radeon RX 460]" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x07e2 Revision: 0xff Driver: "amdgpu" Driver Modules: "amdgpu" Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable) Memory Range: 0xf0000000-0xf01fffff (ro,non-prefetchable) I/O Ports: 0xd000-0xdfff (rw) Memory Range: 0xfe800000-0xfe83ffff (rw,non-prefetchable) Memory Range: 0xfe840000-0xfe85ffff (ro,non-prefetchable) IRQ: 230 (67 events) Module Alias: "pci:v00001002d000067EFsv00001028sd000007E2bc03sc80i00" Driver Info #0: Driver Status: amdgpu is active Driver Activation Cmd: "modprobe amdgpu" Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #22 (PCI bridge) 28: PCI 01.0: 0300 VGA compatible controller (VGA) [Created at pci.378] Unique ID: vSkL.gwUVE8uFOP6 SysFS ID: /devices/pci0000:00/0000:00:01.0 SysFS BusID: 0000:00:01.0 Hardware Class: graphics card Model: "ATI Carrizo" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x9874 "Carrizo" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x07e2 Revision: 0xcc Driver: "amdgpu" Driver Modules: "amdgpu" Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable) Memory Range: 0xf0800000-0xf0ffffff (ro,non-prefetchable) I/O Ports: 0xf000-0xf0ff (rw) Memory Range: 0xfea00000-0xfea3ffff (rw,non-prefetchable) Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled) IRQ: 228 (49683 events) Module Alias: "pci:v00001002d00009874sv00001028sd000007E2bc03sc00i00" Driver Info #0: Driver Status: amdgpu is active Driver Activation Cmd: "modprobe amdgpu" Config Status: cfg=no, avail=yes, need=no, active=unknown Primary display adapter: #28 Here is what my system is using: # lspci -nnk | grep -A3 VGA 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev cc) Subsystem: Dell Device [1028:07e2] Kernel driver in use: amdgpu Kernel modules: amdgpu I tried to boot without nomodeset, and even though it does get to a point where I can type in my login id, it locks up soon after, whether or not I try to log in. It does not reach the display manager. I was not able to boot up to run level 3, though I only tried it once. Also, it does not create an Xorg.0.log file. Or rather, it creates one, but it is completely empty. I think there may be some compatibility issues within the new kernel and my hardware, perhaps? In any case, how can I get back into my system? Can I even reach runlevel 3 with network compatibility so that I could try and upgrade or downgrade my kernel while running in nomodeset? Do I need to file a bug report? -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: TW | Plasma 5.13 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: TW | Plasma 5.13 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

4 5

[opensuse-support] STDOUT of programs started from DE menu in syslog
by Peter Suetterlin 04 Dec '18

04 Dec '18

Hi list, I just noticed/realized that if I start an application via the DE menu, anything that this application prints to stdout is sent to systemd/journal/syslog. (in my case, it's kstars). If I start the application from a terminal, I get the output there, and nothing in syslog. Is there an easy way to change that behavior? I see (man systemd.exec) that in case of services you can prevent that using the StandardOutput= option. But how to do this for .desktop applications? Who is initiating that redirect on first place? Is it the DE, the window manager, or something else? -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

5 13