users June 2024

users@lists.fedoraproject.org

72 participants
59 discussions

smokeping alternative?
by Alex 27 Jun '24

27 Jun '24

Hi, I've been using smokeping to monitor network problems for what seems like decades. It now seems to have been removed from the internet, lol. What are you using to monitor network drop-outs and latency and traffic problems? I'm already using munin to monitor service performance, and nagios to monitor services, but I'm looking for something that can graph latency in the same way as smokeping used to. Ideas greatly appreciated.

3 6

Using Signal-Desktop w Fedora 40
by Max Pyziur 27 Jun '24

27 Jun '24

Greetings, Is there a way of using Signal-Desktop with Fedora 40. C'era una volta/once upon a time, there was. But all of the instructions for finding rpms, installation, etc., are either stale or unusable (installation fails; too many depencies that are not findable). Suggestions? Thank you, Max Pyziur pyz(a)brama.com

5 8

NetworkManager fights selinux
by Robert McBroom 27 Jun '24

27 Jun '24

Fedora 40 system cold boot shows 10 selinux errors from NeworkManager on files in /run/NeworkManager. The contents of this directory seem to be created during the boot process. They are owned by root and writeable, but apparently not in the correct selinux context. My attempt to submit a bug to bugzilla failed for some reason. This status has persisted through several of the latest kernels. The connection to the network ethernet and wifi worked. SELinux is preventing NetworkManager from 'create' accesses on the directory devices. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that NetworkManager should be allowed create access on the devices directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'NetworkManager' --raw | audit2allow -M my-NetworkManager # semodule -X 300 -i my-NetworkManager.pp Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:init_var_run_t:s0 Target Objects devices [ dir ] Source NetworkManager Source Path NetworkManager Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.22-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.22-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 6.9.4-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jun 12 13:33:34 UTC 2024 x86_64 Alert Count 21 First Seen 2024-05-28 00:04:33 EDT Last Seen 2024-06-27 10:24:55 EDT Local ID 63afcb5d-e83d-4a9e-8a3a-8d3abdac3b16 Raw Audit Messages type=AVC msg=audit(1719498295.202:132): avc: denied { create } for pid=7409 comm="NetworkManager" name="devices" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=1 Hash: NetworkManager,NetworkManager_t,init_var_run_t,dir,create SELinux is preventing NetworkManager from open access on the file /run/NetworkManager/conf.d/10-globally-managed-devices.conf. Plugin: restorecon SELinux denied access requested by NetworkManager. /run/NetworkManager/conf.d/10-globally-managed-devices.conf may be mislabeled. /run/NetworkManager/conf.d/10-globally-managed-devices.conf default SELinux type is NetworkManager_var_run_t, but its current type is init_var_run_t. Changing this file back to the default type may fix your problem. File contexts can be assigned to a file in the following ways. Files created in a directory receive the file context of the parent directory by default. The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhcpc_t type and creating a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. If you believe this is a bug, please file a bug report against this package. SELinux is preventing NetworkManager from 'setattr' accesses on the file lo.nmconnection. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that NetworkManager should be allowed setattr access on the lo.nmconnection file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'NetworkManager' --raw | audit2allow -M my-NetworkManager # semodule -X 300 -i my-NetworkManager.pp Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:init_var_run_t:s0 Target Objects lo.nmconnection [ file ] Source NetworkManager Source Path NetworkManager Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.22-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.22-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 6.9.4-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jun 12 13:33:34 UTC 2024 x86_64 Alert Count 40 First Seen 2024-05-28 00:04:36 EDT Last Seen 2024-06-27 10:24:55 EDT Local ID 93e082cc-423c-4a80-96d7-58e62cf9f527 Raw Audit Messages type=AVC msg=audit(1719498295.857:143): avc: denied { setattr } for pid=7409 comm="NetworkManager" name="lo.nmconnection" dev="tmpfs" ino=2901 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 Hash: NetworkManager,NetworkManager_t,init_var_run_t,file,setattr

1 0

Latest upgrade KDE Wayland high CPU
by richard emberson 27 Jun '24

27 Jun '24

Just upgraded from 6.8.8-300.fc40.x86_64 to 6.9.5-200.fc40.x86_64. With both using KDE Wayland. With 6.9.5-200.fc40 there is high idle CPU usage: around 35% for /usr/bin/plasmashell --no-respawn around 25% for /bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_oPtMqQ --xwayland and 20% for [kworker/u18:2-events_unbound] There are a bunch of kworkers that for a time take up 20% CPU (such as [kworker/1:2-events] and others) With version 6.8.8-300.fc40 where was no such high CPU usage. What to do? Thanks Richard

2 2

F40 kernel 6.9.* and VMware 17.5.* question
by Mark C. Allman 27 Jun '24

27 Jun '24

Anyone have VMware Workstation or Player 17.5.1 or 17.5.2 working on the 6.9.* kernels? The kernel modules from VMware haven't worked in quite a while. They don't compile for the 6.9.* kernels, and, if I'm remembering correctly, they don't compile when running the 6.8.* kernels either. I have the code for vmnet and vmmon from https://github.com/mkubecek/vmware-host-modules/tree/workstation-17.5.1. There are all kinds of exceptions when the kernel modules are loaded at boot time. I tried running vmplayer as a test -- it "ran" but trashed the kernel and required hard reboots. One of the tests totally bricked my laptop (that was fun to recover). I'm currently running kernel 6.9.5-200.fc40.x86_64and all packages are up to date. The laptop is a Dell Inspiron 7591, Core i7-10510U CPU, 16GB of ram. -- Mark

5 6

update
by Patrick Dupre 27 Jun '24

27 Jun '24

Hello, When I make dnf system-upgrade download --releasever=40 --allowerasing Numerous packages are going to be removed. How can I get the list of these packages? Thanks =========================================================================== Patrick DUPRÉ | | email: pdupre(a)gmx.com ===========================================================================

2 1

Cannot enable extensions after upgrade from F39 to F40
by Jacek Pliszka 26 Jun '24

26 Jun '24

Hi! I have upgraded from F39 to F40 and my gnome shell extensions stopped working. e.g. $ gnome-extensions list | grep dock dash-to-dock(a)micxgx.gmail.com $ gnome-extensions enable dash-to-dock(a)micxgx.gmail.com $ gnome-extensions list --enabled returns nothing. Any hints? I have some deja vu that it is flat/snap related somehow...

1 0

password issue with f40
by Michael Hennebry 26 Jun '24

26 Jun '24

I recently installed F40 from DVD. F40 and I are having a difference of opinion regarding what password I gave the initial user. F40 is winning. I find it hard to believe I typed in the same wrong password twice, but it's F40's opinion that counts. I try to login: click on the user and type in my password. F40 just goes back to the select a user screen. There is only one user. My usual strategy is to boot a live disk and to edit the passwd and shadow files directly. It did not work. Now F40 no longer even gives me a chance to type in a password. It just blinks at me and goes right back to the select a user screen. What is going on? How do I fix it? I would much prefer not to reinstall. Even if I have to reinstall, I would like to know what is going on. My line from /etc/passwd : hennebry::1000:1000:The Michael:/home/hennebry:/bin/bash My line from /etc/shadow : hennebry::19893:0:99999:7::: -- Michael hennebry(a)mail.cs.ndsu.NoDak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods

14 35

Interesting mount problem - F40
by Frank Bures 24 Jun '24

24 Jun '24

Hi, I have a small SSD that I use for /boot and /boot/efi partitions - /dev/sda I boot from /dev/sda I have another small SSD that I use as a dd backup of /dev/sda - /dev/sdg After update to a new kernel, I dd the /dev/sda to /dev/sdg so that in case of a failure I could boot from /dev/sdg. This scenario worked perfectly till several weeks ago. What is happening now is that the machine boots from /dev/sda, but then mounts /dev/sdg for its /boot and /boot/efi. So in df I see /dev/sdg instead of /dev/sda that the machine booted from. I solved the problem by editing /etc/fstab and pointing /boot and /boot/efi to the relevant /dev/sda[1-2] instead of the original UUID. Question: is this solution OK or have I done something wrong? Is there a better way of solving this? Thanks Frank -- <listfrank1(a)gmail.com>

9 12

Risc-v computer with Fedora on it?
by Ryan Bach 24 Jun '24

24 Jun '24

I can't wait until this is real.

4 10