users April 2022

users@lists.fedoraproject.org

84 participants
82 discussions

Pipewire update reset audio devices AGAIN
by Richard Shaw 26 Apr '22

26 Apr '22

So after updating my system and rebooting, I found all of my audio settings lost AGAIN. I know it's "new" and all, but when are things going to settle down? $ dnf history info 287 | grep pipe Upgrade pipewire-0.3.50-1.fc35.i686 @updates Upgraded pipewire-0.3.49-1.fc35.i686 @@System Upgrade pipewire-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-0.3.49-1.fc35.x86_64 @@System Upgrade pipewire-alsa-0.3.50-1.fc35.i686 @updates Upgraded pipewire-alsa-0.3.49-1.fc35.i686 @@System Upgrade pipewire-alsa-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-alsa-0.3.49-1.fc35.x86_64 @@System Upgrade pipewire-gstreamer-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-gstreamer-0.3.49-1.fc35.x86_64 @@System Upgrade pipewire-jack-audio-connection-kit-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-jack-audio-connection-kit-0.3.49-1.fc35.x86_64 @@System Upgrade pipewire-libs-0.3.50-1.fc35.i686 @updates Upgraded pipewire-libs-0.3.49-1.fc35.i686 @@System Upgrade pipewire-libs-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-libs-0.3.49-1.fc35.x86_64 @@System Upgrade pipewire-pulseaudio-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-pulseaudio-0.3.49-1.fc35.x86_64 @@System Upgrade pipewire-utils-0.3.50-1.fc35.x86_64 @updates Upgraded pipewire-utils-0.3.49-1.fc35.x86_64 @@System

4 9

Re: Fedora trashes my NTFS drive
by Roger Heflin 26 Apr '22

26 Apr '22

On Mon, Apr 25, 2022 at 10:11 AM Lily White <lilywhite2005(a)outlook.com> wrote: > I got a spare drive and it does work (at least for now, this drive > worked for a while before everything broke). So I sent my old drive back > to Sandisk and I'll see if it was with that specific model. > > I'll also wait for some time and see if wear and tear may cause problems. > > What's interesting is that the broken drive works on both Fedora and > macOS, but not Windows. That's why I didn't speculate the drive itself > was broken before. > > I am going to bet that the NTFS code is very similar on Fedora and MacOS. So likely it is a code bug or a usage bug (see comments below). you did make sure to umount it on Linux/BSD before removing it right? And if you hibernate the machine(any os) and remove the usb device while hibernated the filesystem may not be consistent, it has to be explicitly unmounted on both windows and fedora before removal so that all data is fully written. In the past it was suggested to not use NTFS as a transfer drive and to use something simpler like FAT32 as that fs's format is better documented and simpler than NTFS. That may or may not still be the case.

4 3

bluetooth pairing problem
by ToddAndMargo 25 Apr '22

25 Apr '22

Hi All Fedora 35 Xfce Xfce's bluetooth manager find my Jabra 85h but when I try to pair with it, I get "Disconnected" https://imgur.com/VsnXOSK.png # rpm -qa | grep -i blue | grep -v fish | grep -v bird bluez-tools-0.2.0-0.17.git20170912.7cb788c.fc35.x86_64 gnome-bluetooth-libs-3.34.5-2.fc35.x86_64 gnome-bluetooth-3.34.5-2.fc35.x86_64 bluez-5.64-1.fc35.x86_64 bluez-libs-5.64-1.fc35.x86_64 bluez-cups-5.64-1.fc35.x86_64 bluez-obexd-5.64-1.fc35.x86_64 # dnf install pulseaudio-module-bluetooth Error: Problem: problem with installed package pipewire-pulseaudio-0.3.50-1.fc35.x86_64 - package pipewire-pulseaudio-0.3.50-1.fc35.x86_64 conflicts with pulseaudio provided by pulseaudio-15.0-2.fc35.x86_64 When I try to pair, journal give me: bluetoothd[1182]: src/device.c:load_gatt_db() Unable to load key file from /var/lib/bluetooth/00:19:0E:19:3F:C4/cache/7F:A5:9F:E8:AA:26: (No such file) And there really is no file of that name: # ls -al /var/lib/bluetooth/00\:19\:0E\:19\:3F\:C4/cache/ total 16 drwx------. 2 root root 4096 Apr 22 19:15 . drwx------. 4 root root 4096 Apr 22 19:15 .. -rw-------. 1 root root 1078 Apr 22 19:15 30:50:75:48:88:97 -rw-------. 1 root root 29 Mar 21 20:31 CC:82:EB:4C:D5:D5 What is interesting is that 30:50:75:48:88:97 says it is my Jabra 85H [General] Name=Jabra Elite 85h If I erase the cache and start over, the same thing happens. A new file is created but the error log says it can't find a different file. Yours in frustration, -T

5 13

Cinnamon: tranferring ALT to virt-manager
by Alex 25 Apr '22

25 Apr '22

Hi, I have a kvm instance running win10 and need to use the ALT-click key within the instance. However, it seems Cinnamon is intercepting that keypress when accessing the instance using virt-manager. It works fine with virt-manager and GNOME, just not with virt-manager and Cinnamon. virt-manager isn't my favorite, but I've also tried tigervnc some time ago and it also has the same problem. Is there a virt-manager config options I need to select in order to pass the ALT + left mouse key through to the instance? It's currently just set up as a PS2 mouse. Here is my qemu xml config https://pastebin.com/Pnizy4Q7

3 4

Re: Fedora trashes my NTFS drive
by Matt Morgan 25 Apr '22

25 Apr '22

On Sat, Apr 23, 2022 at 11:16 AM Lily White <lilywhite2005(a)outlook.com> wrote: > Hi, > > I have a NTFS flashdrive. When I plug it into Fedora, it reads and > writes normally. However, when plugged into M$ Windows, only an icon and > a not-so-informative ``Removable media'' is shown. > > When I try to reformat it with Windows Disk Management, another > not-so-informative error ``Windows cannot format the given drive'' is > shown. > > I then filled it with zeroes with a Chinese partition management program > (AoMei, if that is useful) and recreated NTFS on it. It worked on > Windows. However, after a plug into Fedora it was ruined again: Fedora > recognized it, but Windows did not. > > Results of `sudo fsck /dev/sdc1': > > ------------------------------------- > fsck from util-linux 2.37.4 > Unsupported: replay_log() > Unsupported: check_volume() > Checking 256 MFT records. > Unsupported cases found. > ntfsck was unable to run properly. > ------------------------------------- > > So I ran `ntfsfix` on it and the following output was produced: > > -------------------------------------------------------- > Mounting volume... OK > Processing of $MFT and $MFTMirr completed successfully. > Checking the alternate boot sector... OK > NTFS volume version is 3.1. > NTFS partition /dev/sdc1 was processed successfully. > -------------------------------------------------------- > > A rerun of fsck produced identical output. > > *Note that the drive was usable on Fedora throughout the process.* > > Any idea what's behind this? > ------ > From LilyWhite with love > I haven't done this for a while, but I used to have a similar problem with Win7 and FAT drives; however, Win7 would always offer to repair the drive and it would be fine again. It happened only on one series of promotional flash drives I had bought in bulk, i.e. they were all the same type and probably from the same production run. So I don't have real suggestions, but a question: does this happen on all NTFS flashdrives, or just this one? Maybe it's the drive itself.

2 1

ssh infested by systemd.resolved
by Sam Varshavchik 25 Apr '22

25 Apr '22

The latest systemd update broke ssh. Specifically, "ssh hostname", where hostname was not a FQDN no longer worked, and I had to use "ssh hostname.domain", for my LAN. Of course, /etc/resolv.conf was pointing to systemd's resolver, and features: search . this was despite my DHCP server offering the LAN's domain name properly. I don't remember if I fixed this laptop previously, or it was using systemd's resolver for a while. I just symlinked /etc/resolv.conf to /run/NetworkManager/no-stub-resolv.conf, which had the correct DNS search string, as always. This seemed to have fixed DNS lookups, per se: $ host jack jack.email-scan.com has address 192.168.0.6 But ssh was still broken, and failing. An strace of ssh revealed that it still insists on talking to systemd. connect(3, {sa_family=AF_UNIX, sun_path="/run/systemd/resolve/io.systemd.Resolve"}, 42) = 0 sendto(3, "{\"method\":\"io.systemd.Resolve.ResolveHostname\",\"parameters\": {\"name\":\"jack\",\"flags\":0}}\0", 87, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 87 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f103ff5c000 I don't see where it's picking this up. The only thing I can think of is nsswitch.conf, but the "hosts" entry there is identical to what's on another, un-upgraded system. I don't see where it's picking this up. The only thing I can think of is nsswitch.conf, but the "hosts" entry there is identical to what's on another, un-upgraded system. Does anyone know how to fumigate systemd out of ssh?

16 36

Re: Unable to boot with LVM.
by Kevin Fenzi 24 Apr '22

24 Apr '22

On Fri, Apr 22, 2022 at 09:30:43AM -0600, Joe Zeff wrote: > On 4/22/22 06:08, Maliga Saman via users wrote: > > Any ideas? > > Yes: keep your porn off of this list. I don't mind, but some folks will. Like the moderators of the list. :) I've removed them from subscribers and banned their email. kevin

5 8

wayland-info to 'invalid format' quest
by Jack Craig 24 Apr '22

24 Apr '22

hi all, i am trying to fathom what hung me out to dry trying to evaluate resolution options for my F34/hdtv. entering display settings, looking at the list of possible resolutions, there are several. *many of those options, if selected yields 'invalid format' !* *what is this telling me?! X by Y values? refresh rate???* while xrandr looks at resolutions and displays options for x11. what is the wayland to evaluate resolution format? wayland-info provides: interface: 'wl_drm', version: 2, name: 1 interface: 'wl_compositor', version: 4, name: 2 interface: 'wl_shm', version: 1, name: 3 formats: 'XB4H'(0x48344258) 'AB4H'(0x48344241) 'XR4H'(0x48345258) 'AR4H'(0x48345241) 'XB30'(0x30334258) 'AB30'(0x30334241) 'XR30'(0x30335258) 'AR30'(0x30335241) RGB565 XRGB8888 ARGB8888 interface: 'wl_output', version: 2, name: 4 *x: 0, y: 0, scale: 1, physical_width: 1600 mm, physical_height: 900 mm, make: 'GSM', model: 'LG TV', subpixel_orientation: unknown, output_transform: normal, mode: width: 3840 px, height: 2160 px, refresh: 30.000 Hz,* flags: current *interface: 'zxdg_output_manager_v1', version: 3, name: 5 xdg_output_v1 output: 4 name: 'HDMI-3' description: 'LG Electronics LG TV' logical_x: 0, logical_y: 0 logical_width: 3840, logical_height: 2160* interface: 'wl_data_device_manager', version: 3, name: 6 interface: 'zwp_primary_selection_device_manager_v1', version: 1, name: 7 interface: 'gtk_primary_selection_device_manager', version: 1, name: 8 interface: 'wl_subcompositor', version: 1, name: 9 interface: 'xdg_wm_base', version: 3, name: 10 interface: 'zxdg_shell_v6', version: 1, name: 11 interface: 'wl_shell', version: 1, name: 12 interface: 'gtk_shell1', version: 4, name: 13 interface: 'wp_viewporter', version: 1, name: 14 interface: 'zwp_pointer_gestures_v1', version: 1, name: 15 interface: 'zwp_tablet_manager_v2', version: 1, name: 16 interface: 'wl_seat', version: 5, name: 17 name: seat0 capabilities: pointer keyboard keyboard repeat rate: 33 keyboard repeat delay: 500 interface: 'zwp_relative_pointer_manager_v1', version: 1, name: 18 interface: 'zwp_pointer_constraints_v1', version: 1, name: 19 interface: 'zxdg_exporter_v1', version: 1, name: 20 interface: 'zxdg_importer_v1', version: 1, name: 21 interface: 'zwp_linux_dmabuf_v1', version: 3, name: 22 formats: 'AR4H'(0x48345241), modifier: 0x00ffffffffffffff 'XR4H'(0x48345258), modifier: 0x00ffffffffffffff 'XB4H'(0x48344258), modifier: 0x00ffffffffffffff 'AB4H'(0x48344241), modifier: 0x00ffffffffffffff 'RG16'(0x36314752), modifier: 0x00ffffffffffffff 'XR30'(0x30335258), modifier: 0x00ffffffffffffff 'AB30'(0x30334241), modifier: 0x00ffffffffffffff 'AR30'(0x30335241), modifier: 0x00ffffffffffffff 'XB24'(0x34324258), modifier: 0x00ffffffffffffff 'XR24'(0x34325258), modifier: 0x00ffffffffffffff 'AB24'(0x34324241), modifier: 0x00ffffffffffffff 'AR24'(0x34325241), modifier: 0x00ffffffffffffff interface: 'zwp_keyboard_shortcuts_inhibit_manager_v1', version: 1, name: 23 interface: 'zwp_text_input_manager_v3', version: 1, name: 24 interface: 'gtk_text_input_manager', version: 1, name: 25 interface: 'wp_presentation', version: 1, name: 26 presentation clock id: 1 (CLOCK_MONOTONIC) jonathan kindly pointed me to ~/.config/monitor.xml hacking this file fixed my error msg, but does not explain what's wrong. any additional insight out there?? tia, jackc...

2 2

Re: ssh infested by systemd.resolved
by Jonathan Billings 24 Apr '22

24 Apr '22

On Apr 23, 2022, at 22:36, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: > As far as I know there isn't really a technical argument for systemd > or any particular systemd.* on Fedora workstations. The various > traditional inits and daemons work fine in that environment.[1] There are several features in systemd that directly benefit the desktop. 1.) systemd service dependencies can ensure that the desktop environment doesn’t launch until all dependencies are met. The side benefit of this is that with parallel startup of services, the desktop launches faster, but it also launches with all the services it needs. If you discover that there’s something needed for your desktop session, adding that dependency is simple, compared to pre-systemd services. 2.) systemd-logind helps contain desktop processes in cgroups, meaning that if you want it to, it will terminate all user processes *for that session* when it logs out. This is a huge thing for the enterprise desktop environments. For example, I managed engineering desktops and there was a particularly finicky circuit designer that loved to leave background processes that would survive logouts, and if another user logged in it would interfere. But this process management also introduced resource management per-user session, so you could ensure a single user couldn’t abuse the system. This was also important to me, since we had multi-user systems running graphical sessions via VNC, and we wanted to make sure one user didn’t overwhelm the system. 3.) systemd now launches your GUI. You have your own private systemd --user running every time you log in. This process launches user services and apps, maintains your environment, and can run other systemd units such as timers. This gives you a similar interface to system services, scoped just to your account. Since there’s only one user systemd per user, you can launch a process that can be used and managed by both the graphical login and a ssh session. (This is actually annoying to me, since it means stuff like Kerberos and AFS works differently than it used to.). Because it is like regular systemd, you can override services in your ~/.config/systemd/user directory, set resource limits, such as only giving gnome-tracker 0.1% of the CPU and lower priority and lower IO bandwidth. 4.) the desktop session output and error are captured in the journal. Previously init systems had user console lost to the user. There was some attempt to capture the X logs and the gnome session, but in systemd each user unit can be individually examined with journalctl. 5.) desktop environments can have a unified interface for autostart of processes in a new session. This is just stuff off the top of my head. While I do agree that there has been a lot of focus on server with systemd, a lot of cool things (like unit templating) were introduced because of the needs in systemd on workstations. Don’t forget that nearly all the common benefits of systemd also help desktops, because at its core, systemd is the core init system to launch the OS. Improvements in the base OS improve all fedora systems. -- Jonathan Billings

2 1

Pro tip: "ddns-updates off" in dhcpd.conf
by Sam Varshavchik 23 Apr '22

23 Apr '22

I noticed that the recent update had dhcpd in it. For no particular reason I decided to do a minor health check and see what it was doing. I was surprised to see that dhcpd was listening on some random high port in addition to its usual dhcp port. [root@shorty ~]# ps -ef | grep dhcp dhcpd 1352 1 0 09:41 ? 00:00:00 /usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid [root@shorty ~]# ls -al /proc/1352/fd lrwx------. 1 root root 64 Apr 23 09:43 20 -> 'socket:[24079]' /proc/net/udp showed the socket bound to port 36755 [root@shorty ~]# netstat -a | grep 36755 udp 0 0 0.0.0.0:36755 0.0.0.0:* The regular dhcp port correctly listens only on the subnet. But this thing is open to the whole wide world. Some searching around found that people noticed this ten years ago, and it's something dynamic dns-related. There was no configuration option to turn it off when people were talking about it. There was only a compile-time option. I combed through the man page. "ddns-updates off" sounded like a promising candidate, I put it into dhcpd.conf, restarted dhcpd, and I don't see dhcpd listening on some high port anymore. This doesn't really matter for Fedora, firewalld will block this. But it's awesome how this is enabled by default, and it's listening on all IP addresses, and not just the DHCP subnet.

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →