users March 2022

users@lists.fedoraproject.org

78 participants
83 discussions

Re: pipewire and wireplumber
by R. G. Newbury 25 Mar '22

25 Mar '22

DJ Delorie <dj(a)delorie.com> wrote > Geoffrey Leach <geoffleach.gl(a)gmail.com> writes: >> Is there a 'Getting Started With pipewire' and/or wireplumber >> somewhere? Or should they 'just work' and I need to check my >> connections? > > As a non-gnome (and non-display-manager) user, I share these .xsession > snippets: > > # Required by pipewire, at least > export XDG_RUNTIME_DIR=$(mktemp -d /tmp/$(id -u)-runtime-dir.XXX) > > # Required by most things > eval `dbus-launch --sh-syntax --exit-with-session` > > pipewire & > pipewire-pulse & > (sleep 2 ; wireplumber & ) & > > > There wasn't a pipewire-specific config; it uses the same ALSA backend > as pulseaudio used. If you don't mind answering, was it a Rhode Island Red cockerel or a hen which you sacrificed to learn these arcane secrets? And, full-moon at midnight, or dark of the moon? Or did this take moving up to a goat? Or are you a graduate of Hogwarts? Because I am quite sure that none of these snippets show up anywhere in the so-called documentation. Pure magic, just like any sufficiently advanced technology. Geoff

4 4

pipewire and wireplumber
by Geoffrey Leach 25 Mar '22

25 Mar '22

I've just installed Fedora 35 and have discovered to my dismay that previously-working (not at all sophisticated) audio no longer works. Is there a 'Getting Started With pipewire' and/or wireplumber somewhere? Or should they 'just work' and I need to check my connections? Thanks.

5 7

Re: pipewire and wireplumber
by R. G. Newbury 25 Mar '22

25 Mar '22

Geoffrey Leach <geoffleach.gl(a)gmail.com> wrote: > I'm happy for you. For me, not so much :-( > >>> I've just installed Fedora 35 and have discovered to my dismay that >>> previously-working (not at all sophisticated) audio no longer works. >>> >>> Is there a 'Getting Started With pipewire' and/or wireplumber somewhere? >> Or >>> should they 'just work' and I need to check my connections? >> Bob Marcan wrote: >> systemctl --user --now disable wireplumber >> works for me. >> Obviously we are guinea pigs for this premature piece of software. Could not agree more with the last sentence. To get audio recognized in order I did this: systemctl stop wireplumber.service dnf erase wireplumber systemctl stop pipewire-pulse.service pipewire-pulse.socket systemctl stop pipewire.service pipewire.socket systemctl daemon-reload dnf --skip-broken erase pipewire pipewire-* libpipewire* pipewire-media-session pipewire-pulseaudio* dnf -y install plasma-desktop # An error message said that plasma-desktop was deleted although that does not appear to be true systemctl stop elogd.service dnf erase elog* # I tried installing elog to get the global XDG_RUNTIME_DIR set: no joy doing that. dnf --allowerasing --skip-broken --best install alsa* kde-settings-pulseaudio dnf --allowerasing --skip-broken --best install pulseaudio* alsa-plugins-pulseaudio dnf --allowerasing install pavucontrol pulseaudio-module-zeroconf The TL:DR is, that I re-installed alsa and pulseaudio after a couple of hours spent trying to get *anything* to connect to the hardware. Geoff

3 2

Problem with kernel 5.16.16 not auto booting on 1 machine??
by Michael D. Setzer II 24 Mar '22

24 Mar '22

Have 5 linux machines at home. 3 with Fedora 34 and 2 with Fedora 35. 4 did the dnf update that included 5.16.16 and rebooted fine. The one system didn't?? Have 3 machine I vnc into, and have one monitor that I connect when I need to look at them. When I couldn't get to the machine after there was enough time to reboot, and pings failed. I connected monitor. When screen came up, it was sitting at grub menu. Pressing enter had it load the 5.16.16 kernel with what seemed no issue. Then did a restart and again, it just got to the boot menu with no timeout? So had to press enter again. Did that 2 more times, same results. Reinstalled the kernel but again. Same result. Looked at grub.cfg and didn't see anything, and /default/grub was same as other machines? Looked at grubenv and that was showing boot_success=0 while all other machines had boot_success=1. On my notebook it shows as beginning. # GRUB Environment Block # WARNING: Do not edit this file by tools other than grub-editenv!!! saved_entry=189711f94e78436d9618b891a8fce70e-5.16. 16-100.fc34.x86_64 boot_success=1 boot_indeterminate=0 Tried the grub-editenv that it mentioned, but program not found. There is a grub2-editenv, so perhaps a missed update for the grubenv?? Help didn't show much, so was going to change the 0 to 1 with hexedit, but I looked at grubenv and it had changed from 0 to 1 on its own in the time I took looking at things. The other 4 machines did update with no problem, and reboot started with no intervention. Not sure why this one had it go to grub menu, and just sit there. Haven't tried another reboot to see it the timeout will work next time, or if will have to continue hitting enter after any reboot?? Haven't had this issue with any other updates?? Thanks. Have a nice day.

1 0

Re: Message during dnf update
by Robert McBroom 24 Mar '22

24 Mar '22

On 3/23/22 11:46, Roger Heflin wrote: > if the groups aren't being created and dnf did not show an error, then > at the very least the script in the rpm doing the install is not > checking return codes and reporting an error. > > The scripts reporting the above, may or may not even have code that > works (especially given they aren't checking error codes). > > here are my permissions they appear to be default (rpm -V setup) will > point out any permissions issues around those files. > > -rw-r--r--. 1 root root 1891 Feb 5 11:39 /etc/group > ----------. 1 root root 1464 Feb 5 11:39 /etc/gshadow > -rw-r--r--. 1 root root 4837 Feb 5 11:57 /etc/passwd > > likely the above scripts are using the groupadd and useradd commands > so you might try adding a group and/or a user with those commands and > see if it works or gives an error. > > If it gives no error and you confirm it did add the user/group then > one has to conclude that the script in the rpm is not doing the > user/group creation properly. > > > > On Wed, Mar 23, 2022 at 8:00 AM Robert McBroom > <robert.mcbroom(a)yahoo.com> wrote: > > On 3/22/22 13:27, Roger Heflin wrote: >> The last Failed to write message is the only real error. The >> other messages are informational. The /etc/gshadow is >> basically trying to add the group users and it already being in >> the file, which is informational. >> >> The real error will be coming from one of the install scripts in >> one of the rpms and that is what needs to be changed (bug report >> on the rpm giving that error to correct the error). And you >> don't know exactly what rpm is doing it nor what file it is >> trying to write to. >> >> On Tue, Mar 22, 2022 at 11:55 AM Robert McBroom via users >> <users(a)lists.fedoraproject.org> wrote: >> >> The following message was sent to the terminal just before >> the verifying step on a dnf update. >> >> Creating group sgx with gid 106. >> Creating group users with gid 100. >> Creating group systemd-oom with gid 951. >> Creating user systemd-oom (systemd Userspace OOM Killer) with >> uid 951 and gid 951. >> /etc/gshadow: Group "users" already exists. >> Failed to write files: File exists >> >> No such entries are in /etc/group. /etc/gshadow has >> permissions of 000, with last update of may 20,2021. Do these >> setting need to be changed? >> > The groups sgx and systemd-oom did not get created either. The > group users is in gshadow but not in group. > Apparently a little more complicated. ~]# groupadd sgx [sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.22], expected [0.23] fo r domain implicit_files! Higher version of database is expected! In order to upgrade the database, you must run SSSD. Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials. Could not open available domains However, sgx was added to /etc/group. Other group additions went through with no messages.

1 0

LibreOffice7.3 crashing?
by Michael D. Setzer II 24 Mar '22

24 Mar '22

Have the Fedora version of LibreOffice working just fine. Also, have the LibreOffice 7.2.5 working just fine. Downloaded the 7.3 and and it seemed to install fine, but attempts to use it result in crash?? Restart has it upload, and it successfully submits the crash report, but goes in safe mode, but still crashes? Doesn't seem to show me any info on what the crash is? I've been trying to bring up calc, so perhaps other parts work? This is on fully updated Fedora 34. Uninstalled the 7.3, and have Fedora version and 7.2.5 working again. Did try uninstalling 7.2.5 and installing 7.3, but it did same thing. Perhaps the report will tell them something. Just wondering if others might either have same issue, or others have it work? Thanks.

2 2

WiFi flakiness after recent upgrades
by Max Pyziur 23 Mar '22

23 Mar '22

Greetings, I have an elderly Dell XPS 13 laptop (L321x); it seems that after a recent software upgrade, the Wifi has become intermittant. As a fallback, I have a USB ethernet connection to cabled switch that is delivering steadily. All other wifi devices (samsung phones, etc) are connected and operating correctly. Is anyone else having difficulties? Thanks, Max Pyziur pyz(a)brama.com

6 7

Re: Configuring IP
by Geoffrey Leach 23 Mar '22

23 Mar '22

Thanks for the reply. It seems that the root of my problem was that the connection defaulted to Automatic. Changing that to Manual seems to have resolved the issue. On Wed, 23 Mar 2022 14:47:47 -0500 Roger Heflin <rogerheflin(a)gmail.com> wrote: > if network manager is running and has not been told to not "manage" > the connection it will manage the connection. > > You need to probably configure it via network manager or via the > ifcfg-* files (making sure to find and set the correct variables to > tell network manager to keep its hands off ,or disable > network-manager in systemd). > > I am still using the ifcfg files and disabling network manager and > will be on non-laptops while some variant of those ifcfg-* files > still work. > > I generally never use ifconfig/ip addr except for a quick test/one > time emergency use since those settings do not survive reboot. > > > On Wed, Mar 23, 2022 at 2:28 PM Geoffrey LeachThanks for the reply. It seems that the root of my problem was that the connection defaulted to Automatic. Changing that to Manual seems to have resolved the issue. On Wed, 23 Mar 2022 14:47:47 -0500 Roger Heflin <rogerheflin(a)gmail.com> wrote: > if network manager is running and has not been told to not "manage" > the connection it will manage the connection. > > You need to probably configure it via network manager or via the > ifcfg-* files (making sure to find and set the correct variables to > tell network manager to keep its hands off ,or disable > network-manager in systemd). > > I am still using the ifcfg files and disabling network manager and > will be on non-laptops while some variant of those ifcfg-* files > still work. > > I generally never use ifconfig/ip addr except for a quick test/one > time emergency use since those settings do not survive reboot. > > > On Wed, Mar 23, 2022 at 2:28 PM Geoffrey Leach > <geoffleach.gl(a)gmail.com> wrote: > > > I have an ethernet connection (to a SiliconDust box) that requires a > > netmask 255.255.0.0. So, no problem > > > > % ifconfig eno1 192.168.10.6 netmask 255.255.0.0 > > % ifconfig eno1 > > eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > inet 192.168.10.6 netmask 255.255.0.0 broadcast > > 192.168.255.255 > > > > some time later ... > > > > % ifconfig eno1 > > eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > inet 192.168.10.6 netmask 255.255.255.0 broadcast > > 192.168.10.255 > > > > Any ideas on why the change does not stick? > > > > Thanks > <geoffleach.gl(a)gmail.com> wrote: > > > I have an ethernet connection (to a SiliconDust box) that requires a > > netmask 255.255.0.0. So, no problem > > > > % ifconfig eno1 192.168.10.6 netmask 255.255.0.0 > > % ifconfig eno1 > > eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > inet 192.168.10.6 netmask 255.255.0.0 broadcast > > 192.168.255.255 > > > > some time later ... > > > > % ifconfig eno1 > > eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > inet 192.168.10.6 netmask 255.255.255.0 broadcast > > 192.168.10.255 > > > > Any ideas on why the change does not stick? > > > > Thanks

1 0

Configuring IP
by Geoffrey Leach 23 Mar '22

23 Mar '22

I have an ethernet connection (to a SiliconDust box) that requires a netmask 255.255.0.0. So, no problem % ifconfig eno1 192.168.10.6 netmask 255.255.0.0 % ifconfig eno1 eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.6 netmask 255.255.0.0 broadcast 192.168.255.255 some time later ... % ifconfig eno1 eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.6 netmask 255.255.255.0 broadcast 192.168.10.255 Any ideas on why the change does not stick? Thanks

2 1

[IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
by Zdenek Dohnal 23 Mar '22

23 Mar '22

Hi all, driverless+printer applications world of printing and scanning is coming in the future: - printer driver, raw queues and other removals are planned with CUPS 3.0, roughly in the next year, - printer applications RPMs are waiting for cups-filters 2.0, but the apps are in SNAP already for people to try them, - driverless scanning is already possible with sane-airscan, which supports WSD and eSCL protocols. and since ipp-usb is in Fedora for a while (since Fedora 32), CUPS and sane-airscan packages started to recommend ipp-usb package, which unfortunately leads to expected breakage (see known issues[1] - either under HPLIP or golang-github-openprinting-ipp-usb) due a conflict on USB port. _This breakage happens if both conditions below are met:_ - the device supports IPP-over-USB - how to find out here[2] - the device is currently installed with a classic driver, (f.e. HPLIP - has its device uri starting with 'hp:/usb/'), _The __behavior__of breakage_ is: - for printing - the old queue is available, but when a job is sent it prints nothing, with errors in the logs as: hp[3559]: io/hpmud/musb.c 515: invalid claim_interface 7/1/4: Device or resource busy - for scanning - the scanner is not recognized by the classic driver, but sane-airscan should kick in and provide functional device, so a new device should appear in scanning dialog _The breakage is __expected__for IPP-over-USB devices_, because ipp-usb is running on the USB port, prepared for incoming IPP requests. This behavior blocks the port for other binaries, which can try to access it, such as printing and scanning backends (pixma, hp, hpaio...). Unfortunately there is no clean upgrade path to solve the migration automatically because of unrealistic requirements such as: - the USB device would have needed to be plugged in and turned on during the update - %post scriptlets don't work the same way on immutable Fedoras as on Fedora Linux, and other upgrade possibilities such as Leapp don't support Fedora upgrades AFAIK, the fix has to be done manually. _How to fix the breakage:_ - printing - remove the old print queue and start using CUPS temporary queue[3], which is supported by modern print dialogs, or install the new queue permanently by: $ lpadmin -p <queue_name> -v ipp://localhost:60000/ipp/print -m everywhere -E ipp-usb advertises the printer only to localhost at port 60000 by default, any other USB printer capable of IPP-over-USB will be available at port 60001 etc... - scanning - sane-airscan should automatically pick the device up, if the device supports eSCL or WSD protocols - here [4] is the growing list of devices, which were identified by users as they are working with sane-airscan. In case you have only one device supported by the driver package and the driver is a list package, you can safely remove the driver package _If the driverless setup with ipp-usb doesn't work for you:_ It would be great if you filed a bug at https://bugzilla.redhat.com for golang-github-openprinting-ipp-usb component after you've gone through the useful tricks for printing[8], 'How to fix the breakage' from this email and known issues of CUPS[9]. If the device is unusable for ipp-usb due a serious firmware bug, we can add a quirk upstream rejecting this device in ipp-usb, so the daemon will ignore the device and the quirk will be shared with all users - so the device can be again used with classic driver or with, in the future, with a printer application. If user wants to go with classic drivers again, golang-github-openprinting-ipp-usb-0.9.20 (currently in rawhide and for other releases in testing repo - F36[5], F35[6], F34[7]) supports device quirks in /etc/ipp-usb/quirks directory. See 'man ipp-usb' for more info. __ _Affected OS versions:_ Fedora 36+ and users who installed cups-2.3.3op2-15.fc35/fc34 updates - the change was reverted in cups-2.3.3op2-16.fc35/fc34, but ipp-usb is not removed with the new CUPS update, so it has to be removed manually or the setup has to be migrated ('How to fix the breakage') to ipp-usb. _SUMMARY:_ I'm deeply sorry for the inconvenience during the breakage and for not announcing the change in advance via proper channels - hopefully driverless setup with ipp-usb can help you with using the device without additional drivers, proprietary binary blobs and its 'installation' (in case of CUPS temporary queues you don't need to install the printer at all, that's why installation with quotes) will be more smoother. Thank you for your time and effort! Zdenek [1] https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_golang_… [2] https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to… [3] https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_temporar… [4] https://github.com/alexpevzner/sane-airscan#compatibility [5] https://bodhi.fedoraproject.org/updates/FEDORA-2022-037458e247 [6] https://bodhi.fedoraproject.org/updates/FEDORA-2022-140993eb13 [7] https://bodhi.fedoraproject.org/updates/FEDORA-2022-f151accd9b [8] https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks [9] https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_cups -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC

1 0

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