4877 packages to update... Time to clean house?
by Richard Shaw
Working on downloading all the packages to update to Fedora 31 and noticed
that I have 4877 packages (and 6GB) to update (excluding a handful of new
weak dependencies).
Anyone have a good workflow they use to remove unneeded packages?
Thanks,
Richard
4 years, 4 months
Silly Web UI on Server?
by John M. Harris Jr
Does anyone know if it's possible to install the Server spin without getting
Cockpit? I like the hardware support group, but I have no idea why I don't get
an option to turn off that useless web UI.
--
John M. Harris, Jr.
Splentity
4 years, 4 months
The system printing service doesn't seem to be available
by Simon Colston
Fedora 31 Workstation
I installed Xfce to give it a try, didn't like it so I removed it. Unfortunately, since then, when I go to Settings ->
Devices -> Printers I get the message "Sorry! The system printing service doesn't seem to be available"
I did some googling and found out that CUPS is responsible for printing. The timestamp on the file
/etc/cups/subscriptions.conf.O is the time I installed Xfce and the timestamp on /etc/cups/subscriptions.conf.rpmsave is
the time I removed Xfce. So that's how I broke it, I guess.
I now only have 2 CUPS packages installed:
cups-libs.x86_64
cups-pk-helper.x86_64
Can I just install cups.x86_64 package or is there anything else I need to do to get printing working again?
--
Simon
4 years, 4 months
Bridged connection MAC address change after F31 update
by Sam Varshavchik
I have a fixed IP address assigned via DHCP to a machine that I just
updated to F31.
After the update, I was slightly surprised when it didn't come up on its
fixed IP address. After looking through the logs, the DHCP server is now
apparently getting a DHCP request from a different MAC address, apparently
the bridge's MAC address. I updated the DHCP config, and brought the network
connection down/up, and it came up on its fixed IP address, normally.
In F30, the kernel was kernel-5.3.11-200.fc30.x86_64, and it's now
kernel-5.3.11-300.fc31.x86_64, of course; so this doesn't look like a kernel
change.
The relevant data is:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master
vnet0 state UP group default qlen 1000
link/ether 00:30:48:fc:83:fa brd ff:ff:ff:ff:ff:ff
inet6 fe80::230:48ff:fefc:83fa/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 00:30:48:fc:83:fb brd ff:ff:ff:ff:ff:ff
4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 96:03:13:50:00:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global dynamic vnet0
valid_lft 603710sec preferred_lft 603710sec
inet6 fe80::9403:13ff:fe50:eb/64 scope link
valid_lft forever preferred_lft forever
Up until F30, the DHCP server was seeing requests from 00:30:48:fc:83:fa,
and now the DHCP server is seeing requests from 96:03:13:50:00:eb.
I'm hoping that, at least, the bridge won't be getting random MAC addresses
with every boot?
4 years, 4 months
What to do with a non-NM managed bridge, now
by Sam Varshavchik
A very long time ago I stumbled my way into setting up a virtual bridge so
that a qemu-hosted Windows 10 VM could have a static IP address assigned
from my LAN's DHCP server, and be reachable from my LAN, directly.
This was a while ago; to the best of my recollection at that time
NetworkManager did not support bridges; or the there was some other reason
the bridge had to be set up that way.
Well, for a reason that I'll describe separately, after updating to F31 it
was necessary to manually ifdown/ifup the bridge in order to fix something.
And I'm told that ifdown/ifup is being retired and I should use nmcli. But
nmcli doesn't see it, of course.
So, what are my options? Reconfigure my monkey-patched configuration to a NM-
managed one?
What I currently have is:
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Intel Corporation 82573E Gigabit Ethernet Controller (Copper)
DEVICE=eth0
BRIDGE=vnet0
HWADDR=00:30:48:FC:83:FA
ONBOOT=yes
OPTIONS=layer2=1
TYPE=Ethernet
NM_CONTROLLED=no
USERCTL=no
IPV6INIT=yes
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME="System eth0"
#UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
BOOTPROTO=dhcp
ETHTOOL_OPTS="advertise 030"
and
# cat ifcfg-vnet0
DEVICE=vnet0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
IPV6INIT=no
USERCTL=no
ZONE=FedoraWorkstation
NM_CONTROLLED=no
Currently, NetworkManager sees /something/:
# nmcli c show
NAME UUID TYPE DEVICE
virbr0 65a32109-d944-40b1-abf8-15458f81585c bridge virbr0
And when everything's up, "ip addr" shows:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master
vnet0 state UP group default qlen 1000
link/ether 00:30:48:fc:83:fa brd ff:ff:ff:ff:ff:ff
inet6 fe80::230:48ff:fefc:83fa/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 00:30:48:fc:83:fb brd ff:ff:ff:ff:ff:ff
4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 96:03:13:50:00:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global dynamic vnet0
valid_lft 604185sec preferred_lft 604185sec
inet6 fe80::9403:13ff:fe50:eb/64 scope link
valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state
DOWN group default qlen 1000
link/ether 02:23:42:87:19:5d brd ff:ff:ff:ff:ff:ff
Is this as simple as manually changing NM_CONTROLLED=yes in both
initscripts? That's easy enough to do, test, and roll it back, if it blows
up, but can anyone think of anything else that needs to be tweaked.
4 years, 4 months
akmod nvidia
by Amadeus WM
I have an older nvidia card and I'm using the proprietary drivers with akmod from
rpmfusion.
akmod-nvidia-340xx-340.107-8.fc30.x86_64
xorg-x11-drv-nvidia-340xx-kmodsrc-340.107-4.fc30.x86_64
xorg-x11-drv-nvidia-340xx-libs-340.107-4.fc30.x86_64
xorg-x11-drv-nvidia-340xx-340.107-4.fc30.x86_64
kmod-nvidia-340xx-5.2.18-200.fc30.x86_64-340.107-8.fc30.x86_64
Every time the kernel gets updated, akmod does its thing, builds the kmod-nvidia rpm
and all is well.
Except for 5.3 kernels, akmod fails to build. For instance, in
/var/cache/akmods/nvidia-340xx/340.107-8-for-5.3.11-200.fc30.x86_64.failed.log
I see
2019/11/15 21:07:34 akmodsbuild: /tmp/akmodsbuild.LuUtkSzx/BUILD/nvidia-340xx-kmod-340.107/_kmod_build_5.3.11-200.fc30.x86_64/nv-linux.h: In function 'nv_execute_on_all_cpus':
2019/11/15 21:07:34 akmodsbuild: /tmp/akmodsbuild.LuUtkSzx/BUILD/nvidia-340xx-kmod-340.107/_kmod_build_5.3.11-200.fc30.x86_64/nv-linux.h:903:21: error: void value not ignored as it ought to be
2019/11/15 21:07:34 akmodsbuild: 903 | int __ret = on_each_cpu(func, info, wait); | ^~~~~~~~~~~
So I guess in kernel 5.3 on_each_cpu() no longer returns int, but void.
The nvidia driver has not been updated to reflect that.
Do I need to wait for nvidia to fix that (if they ever do, given that this is the
legacy driver) or does anyone on the fedora side do any kind of back porting that can
fix it? Do I file a bug with bugzilla?
4 years, 4 months
Tip: WoeUSB and FC31
by ToddAndMargo
Hi All,
If you go to cut a Windows installer flash drive from iso
with WoeUSB under Fedora 31, you are in for some surprises.
It crashes on exit. But the good new is that the drive
comes out perfectly. And it boots both Legacy and EUFI.
Very sweet!
After WoeUSB crashed, you need to do a DF and a umount
on the open loop drive and anything else it left mounted
after it crashes.
I opened the following bug report on it:
https://bugzilla.redhat.com/show_bug.cgi?id=1773142
-T
4 years, 4 months
Gmail in Fedora-31 -
by Bob Goodwin
I have been unable to create a gmail account in Thunderbird 68 or 70 in
this computer although I was able to do that when booted to Fedora-29 on
a separate drive. I suspect there may be a problem of which I am not
aware between google and Mozilla security? ...
Or am I doing something wrong, has any one else had this problem?
Bob
--
Bob Goodwin - Zuni, Virginia, USA
4 years, 4 months
sound bug on update with HDMI
by Cătălin George Feștilă
the sound device was gone ...
the pavucontrol tool shows an input sound play but on virtual output, Dummy Output ...
I don't see anything with the hardware with this tool.
The arecord don't see anything:
$ arecord -l
arecord: device_list:272: no soundcards found...
The output of lspci
[mythcat@desk my_bash_scripts]$ lspci -v | grep Audio
lspci: Unable to load libkmod resources: error -12
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
05:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
alsactl --force restore
alsactl: load_state:1735: No soundcards found...
dmesg | grep Audio
[ 0.462513] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
I think is the same bug as this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804577
any idea?
4 years, 4 months