Re: pipewire and wireplumber
by R. G. Newbury
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
2 years, 1 month
Problem with kernel 5.16.16 not auto booting on 1 machine??
by Michael D. Setzer II
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.
2 years, 1 month
Re: Message during dnf update
by Robert McBroom
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.
2 years, 1 month
LibreOffice7.3 crashing?
by Michael D. Setzer II
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 years, 1 month
WiFi flakiness after recent upgrades
by Max Pyziur
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
2 years, 1 month
Re: Configuring IP
by Geoffrey Leach
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
2 years, 1 month
Configuring IP
by Geoffrey Leach
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 years, 1 month
[IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a
driver are installed
by Zdenek Dohnal
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/#_golan...
[2]
https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_...
[3]
https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_tempor...
[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
2 years, 1 month
Linux video camera UVC driver with multiple cameras
by Steve Underwood
Hi,
The Linux UVC driver for USB video cameras names devices according to
the product name it gets from the USB device itself. This is fine if you
have different models of camera, as each gets a different name. However,
if you have, say, 3 Logitech C920 cameras, the device list in video
applications shows you have many devices called "HD Pro Webcam C920",
and you can't tell which is which. I looked in the driver source code to
see if there is a way to tag the cameras with unique names, but there
doesn't seem to be. Does anyone know if I missed something?
Regards,
Steve
2 years, 1 month
Re: Help configuring internal network
by R. G. Newbury
On 2022-03-20 8:00 a.m.,
Tim <ignored_mailbox(a)yahoo.com.au> wrote
>> R. G. Newbury wrote:
>> Controlling an hdhr with a dhcp served IP address is basically
>> impossible as it is hard to find that address and remember it for use
>> in your program. Control of the unit with most digital tv programs
>> requires a static IP address. Mythtv for instance will not work if
>> the IP address is changed, external to the mythtv program.
> DHCP does not equal random new addresses each time. On a home network,
> you're extremely likely to get assigned the same address each time.
> But you can ensure that by configuring the DHCP server to work that way.
'Configuring the DHCP server to work that way', is to set it to deliver
a static address. With a dhcp server, the problem is that any change in
the network, or the items connecting to it, can cause the dhcp server to
deliver a different address to a unit, while a static address, once set
as a static address, will not change. Moreover, a static address setting
is tied to the MAC of the unit, not its FQDN.
> For many things on a home LAN, configuring a DHCP server is going to be
> the easiest way to set fixed IPs for every device (unless you like
> manually configuring your TV, your printer, your PC, your laptop, your
> smart gadgets, your internet fridge, and partridge in a pear tree.
No wonder I can never get the partridges to connect properly!
2 years, 1 month