If you are upgrade from 29 to 30, make sure you
update dnf and libdnf first do to a bug that has
been fixed (my procedure below takes care of this).
So far I have one virtual machine running FC30. Haven't
got a chance to torture it yet though.
This is my update procedure:
FC 29 -->> FC 30:
# rpm --rebuilddb
# rpm -Va --nofiles --nodigest
if anything is too new, do a
# dnf downgrade offender(s)
# dnf --enablerepo=* update --refresh
# dnf install python3-dnf-plugin-system-upgrade
# dnf system-upgrade download --refresh --releasever=30 --allowerasing
# dnf clean packages <-- optional
# dnf system-upgrade reboot
I just upgraded from F29 to F30. All looks fine except printing from the
system. The printer is configured in /etc/cups/printers.conf (see details
below). I noticed that in a previous file the "Shared" was set to Yes, but
all the other lines are exactly the same.
if I try to pront from the system the job is held in the queue telling me
that there is a problem with authentication (but the authentication is
included in the prints.conf file). If I look in the printer set=up menu
which can be started from the "gnome-to-panel" it tells me that the job
needs autentication and it asks met to enter credentials, but I cannot input
them from this menu: Where should I enter them?
If I try to reconfigure the printer via cups and indicate that the printer
is to be shared, I get the message that sharing is not possible for a
Kerberos-printer. On this system I never configured Kerberos. So what is
Please help me getting printing working on this machine as it worked before
the upgrade to F30.
excerpt form /etc/cups/printers.conf:
MakeModel Xerox AltaLink C8035
JobSheets none none
Option sides two-sided-long-edge
Pax, vel iniusta, utilior est quam iustissimum bellum.
(free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.)
Epistularum ad Atticum 220.127.116.11)
Touch not the cat bot a glove
Technische Universiteit Delft tttttttttt uu uu ddddddd
Kavli Institute of Nanoscience tttttttttt uu uu dd dd
Nationaal centrum voor HREM tt uu uu dd dd
Lorentzweg 1 tt uu uu dd dd
2628 CJ Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2782272 tt uuuuuuu ddddddd
Wait a day or ???
Problem 1: package python2-hawkey-0.31.0-2.fc29.x86_64 requires
libdnf(x86-64) = 0.31.0-2.fc29, but none of the providers can be installed
- libdnf-0.31.0-2.fc29.x86_64 does not belong to a distupgrade repository
- problem with installed package python2-hawkey-0.31.0-2.fc29.x86_64
Problem 2: package system-config-services-0.111.4-2.fc24.noarch
requires python-slip >= 0.1.11, but none of the providers can be installed
- python2-slip-0.6.4-12.fc29.noarch does not belong to a distupgrade
- problem with installed package
Problem 3: problem with installed package
- package system-config-firewall-1.2.29-21.fc29.noarch requires
python2-slip-dbus >= 0.2.7, but none of the providers can be installed
- python2-slip-dbus-0.6.4-12.fc29.noarch does not belong to a
Problem 4: package python3-hawkey-0.28.1-1.fc30.x86_64 requires
libdnf(x86-64) = 0.28.1-1.fc30, but none of the providers can be installed
- cannot install both libdnf-0.28.1-1.fc30.x86_64 and
- problem with installed package python3-hawkey-0.31.0-2.fc29.x86_64
- package python2-libdnf-0.31.0-2.fc29.x86_64 requires libdnf(x86-64)
= 0.31.0-2.fc29, but none of the providers can be installed
- python3-hawkey-0.31.0-2.fc29.x86_64 does not belong to a distupgrade
- problem with installed package python2-libdnf-0.31.0-2.fc29.x86_64
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages)
I spotted an article on another site indicating release of F30. I wasn't expecting it for a week! Thus caught unprepared, for the first time ever, I did a dnf system-upgrade on my UEFI system. I had to remove cclive and, for some odd reason, there was a problem with getting the updates repo, so I blocked metalink= and unblocked baseurl= in fedora-updates.repo and everything worked smoothly. After a preliminary 2 hours, everything appears to be working as in F29.
I recently upgraded to Freeradius 3.0.19-1 and I noticed after I
restarted the service I was getting the following errors:
Apr 29 22:01:29 freeradius systemd: Starting FreeRADIUS high performance
Apr 29 22:01:30 freeradius sh: make: *** No rule to make target
'server.cnf', needed by 'passwords.mk'. Stop.
Apr 29 22:01:30 freeradius systemd: radiusd.service: Control process
exited, code=exited status=2
Apr 29 22:01:30 freeradius systemd: radiusd.service: Failed with result
Apr 29 22:01:30 freeradius systemd: Failed to start FreeRADIUS high
performance RADIUS server..
Apr 29 22:01:30 freeradius audit: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
I got it from Fedora 28 Repo: freeradius-3.0.19-1.fc28.armv7hl. After a lot
of digging, I found that a "bootstrap" script on the /etc/raddb/certs/
directory was being called on the /usr/lib/systemd/system/radiusd.service.
This script overwrote my current certificate files. I had to comment out
the ExecStartPre=/bin/sh /etc/raddb/certs/bootstrap to fix the problem. I
am not sure if anyone else encountered this problem before.
Here is what I have on my /usr/lib/systemd/system/radiusd.service script
Description=FreeRADIUS high performance RADIUS server.
After=syslog.target network-online.target ipa.service dirsrv.target
ExecStartPre=-/bin/chown -R radiusd.radiusd /var/run/radiusd
ExecStartPre=/bin/chgrp -R radiusd /etc/raddb/certs/
ExecStart=/usr/sbin/radiusd -d /etc/raddb
ExecReload=/bin/kill -HUP $MAINPID
Is this being addressed on future releases?
Per the subject line, I see that there is this announcement
(https://fedoramagazine.org/announcing-fedora-30/), but after
starting the upgrade and downloading the packages, the upgrade made no
Usually, the announcement of a new release is made with an email blast,
which as yet, I haven't received.
Is the F30 release official?
Make sure you turn off any Gnome extensions that you have downloaded
from gnome.org. There is an issue where some gnome extensions that are
loaded from the user account will cause gnome-shell to crash. What you
will see is you try to log in and after a few seconds it returns back
to the login screen. (And yes, it is a reported bug. And yes, it still
happens, because it just happened on the upgrade I am doing now.)
The way I have fixed the problem is to delete anything in
~/.local/share/gnome-shell/extensions/ and then redownload the ones you
Hope that helps.