Hi All,
Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them.
Hope it helps someone else:
-T
FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
# 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=31 --allowerasing --best
If there are any failures or "system-upgrade reboot" starts and reboots back into the old operating system, remove or clean up the offenders until the above completes correctly.
IMPORTANT, then you must clean out the upgrade cache and start over without the "--allowerasing" and "--best"
# dnf system-upgrade clean
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-primary # dnf clean packages <-- optional # dnf system-upgrade -v reboot --debugsolver
If a problem still exists, look through the new logs for and "CRIT" or "CRITICAL" notations /var/log/dnf.log and dnf.rpm.log for messages which may offer clues.
Post upgrade: Note: the upgrade buggers up bind-chroot and perl 6
Firewall (iptables): # systemctl enable custom-firewall.service # systemctl stop custom-firewall.service # systemctl start custom-firewall.service
eth.ext.rules: modify:
lease_file=$(ls -t ${lease_dir}/internal*lease | sed -n 1,1p) mask=$(cat $lease_file | grep NETMASK | awk -F "=" '{print $2}') eth1_addr=$(cat $lease_file | grep -v _ADDRESS | grep ADDRESS | awk -F "=" '{print $2}') eth1_net=$(echo $eth1_addr | sed -e "s/./ /g" | awk '{print $1"." $2"." $3".0/"}')$ETH1_MASK DHCPD=$(cat $lease_file | grep SERVER_ADDRESS | awk -F "=" '{print $2}') gateway_addr=$(cat $lease_file | grep SERVER_ADDRESS | awk -F "=" '{print $2}')
# Set up (local) DNS (bind, named) outgoing querry rules $tbls -A dsl-out -o $eth1 -p tcp --dport domain -m state --state NEW,ESTABLISHED -j ACCEPT $tbls -A dsl-out -o $eth1 -p udp --dport domain -m state --state NEW,ESTABLISHED -j ACCEPT $tbls -A dsl-in -i $eth1 -p udp --sport domain -d $eth1_addr -m state --state RELATED,ESTABLISHED -j ACCEPT $tbls -A dsl-in -i $eth1 -p tcp ! --syn --sport domain -d $eth1_addr -m state --state RELATED,ESTABLISHED -j ACCEPT
/etc/resolv.conf Comment out "search" and "nameserver" entries Temporarily add "nameserver 8.8.8.8"
disable the firewall (eth.ext.reset)
Reinstall bind and bind-chroot # dnf reinstall bind bind-chroot # systemctl enable named-chroot.service # systemctl start named-chroot.service
Reenable bind's (dns) SELinux rules: # setsebool -P nis_enabled 1 # ausearch -c 'named' --raw | audit2allow -M my-named # semodule -X 300 -i my-named.pp
Test with $ host google.com 127.0.0.1
/etc/resolv.conf restore commented out "search" and "nameserver" entries comment out "nameserver 8.8.8.8"
Test with $ host google.com
Perl 6: remove and reinstall Perl 6 (Rakudo) # dnf remove rakudo-zef rakudo # dnf install rakudo-zef rakudo
Download and install the latest or desired release from: https://github.com/nxadm/rakudo-pkg/releases for example: # dnf install /home/CDs/Linux/Perl/6/rakudo-pkg-Fedora31-2019.07.1-03.x86_64.rpm
Make sure all you module begin with "unit module <modlue name>;". Fedora 31 will not tolerate modules without it any more.
On 11/9/19 9:24 AM, ToddAndMargo via users wrote:
Hi All,
Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them.
Hope it helps someone else:
-T
FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
# rpm --rebuilddb # rpm -Va --nofiles --nodigest if anything is too new, do a # dnf downgrade offender(s)
# dnf --enablerepo=* update --refresh
The above is, IMO, bad advice. --enablerepo=* will enable "testing" repos. This may easily result in updates to packages to versions not yet in the upgrade version. The result can be needless downgrading of packages during the upgrade process.
# dnf install python3-dnf-plugin-system-upgrade # dnf system-upgrade download --refresh --releasever=31 --allowerasing --best
The above is also, IMO, bad advice. It should not be necessary to use --allowerasing or --best. These should be used only when problems have been found to exist and determined to be necessary.
As shown by the thread "F31 upgrade non-starter" these and other options applied without the need can lead to false failures.
In other words, using options in the attempt to fix problems which don't exist may lead to phantom problems.
On 11/8/19 8:42 PM, Ed Greshko wrote:
On 11/9/19 9:24 AM, ToddAndMargo via users wrote:
Hi All,
Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them.
Hope it helps someone else:
-T
FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
# rpm --rebuilddb # rpm -Va --nofiles --nodigest if anything is too new, do a # dnf downgrade offender(s)
# dnf --enablerepo=* update --refresh
The above is, IMO, bad advice. --enablerepo=* will enable "testing" repos. This may easily result in updates to packages to versions not yet in the upgrade version. The result can be needless downgrading of packages during the upgrade process.
Only you never updated all your repos before. I do all the time. Everything has to be updated. And yes, I have seen that debated too.
# dnf install python3-dnf-plugin-system-upgrade # dnf system-upgrade download --refresh --releasever=31 --allowerasing --best
The above is also, IMO, bad advice. It should not be necessary to use --allowerasing or --best. These should be used only when problems have been found to exist and determined to be necessary.
I found that --allowerasing will error out on dumb things I have done, which allows me to fix them. Did you notice later on, I stated to not use the --allowerasing?
As shown by the thread "F31 upgrade non-starter" these and other options applied without the need can lead to false failures.
In other words, using options in the attempt to fix problems which don't exist may lead to phantom problems.
I have not found that to be the case
On 11/9/19 1:22 PM, ToddAndMargo via users wrote:
On 11/8/19 8:42 PM, Ed Greshko wrote:
On 11/9/19 9:24 AM, ToddAndMargo via users wrote:
Hi All,
Here are my upgrade notes on Fedora 30 to 31. not that they are specific to me. Let me know if you want me to expound on any of them.
Hope it helps someone else:
-T
FC 30 -->> FC 31: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
# rpm --rebuilddb # rpm -Va --nofiles --nodigest if anything is too new, do a # dnf downgrade offender(s)
# dnf --enablerepo=* update --refresh
The above is, IMO, bad advice. --enablerepo=* will enable "testing" repos. This may easily result in updates to packages to versions not yet in the upgrade version. The result can be needless downgrading of packages during the upgrade process.
Only you never updated all your repos before. I do all the time. Everything has to be updated. And yes, I have seen that debated too.
The Official Upgrade Instructions are to be found at....
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
They make no mention of updating from "testing" prior to upgrading.
You happen to do things which are pretty much not what most others would do.
My suggestion is that people use the official upgrade instructions.
# dnf install python3-dnf-plugin-system-upgrade # dnf system-upgrade download --refresh --releasever=31 --allowerasing --best
The above is also, IMO, bad advice. It should not be necessary to use --allowerasing or --best. These should be used only when problems have been found to exist and determined to be necessary.
I found that --allowerasing will error out on dumb things I have done, which allows me to fix them. Did you notice later on, I stated to not use the --allowerasing?
Your text appears to be saying, use --allowerasing --best and then if you have issues do a clean and then proceed without using them.
Counteractive, IMO.
Don't use them first. And, only use them if found to be necessary after, should problems exist, one has diagnosed them to be helpful.
As shown by the thread "F31 upgrade non-starter" these and other options applied without the need can lead to false failures.
In other words, using options in the attempt to fix problems which don't exist may lead to phantom problems.
I have not found that to be the case
You may have not. But others have. Note the cited thread.
On 11/8/19 10:03 PM, Ed Greshko wrote:
You happen to do things which are pretty much not what most others would do.
What?? Me??? Okay, guilty as charged.
My suggestion is that people use the official upgrade instructions.
A good place to start, but I have found it does not cover things that go wrong. To me they are rather incomplete but a good starting point. I reference them in my full upgrade write up.
Your text appears to be saying, use --allowerasing --best and then if you have issues do a clean
and then proceed without using them.
I have had the experience where I had something from a testing repo that was a higher revision that in the next release, and the upgrade pooped on me because of it.
On Sat, 2019-11-09 at 00:35 -0800, ToddAndMargo via users wrote:
On 11/8/19 10:03 PM, Ed Greshko wrote:
You happen to do things which are pretty much not what most others would do.
What?? Me??? Okay, guilty as charged.
My suggestion is that people use the official upgrade instructions.
A good place to start, but I have found it does not cover things that go wrong. To me they are rather incomplete but a good starting point. I reference them in my full upgrade write up.
I'm with Ed on this. Use the official instructions. Only *after* the upgrade has succeeded, enable the testing repos if you wish.
poc
On 11/9/19 2:44 AM, Patrick O'Callaghan wrote:
A good place to start, but I have found it does not cover things that go wrong. To me they are rather incomplete but a good starting point. I reference them in my full upgrade write up.
I'm with Ed on this. Use the official instructions. Only*after* the upgrade has succeeded, enable the testing repos if you wish.
poc
They are indeed a good place to start, but they only work under ideal conditions.
On 11/9/19 7:16 PM, ToddAndMargo via users wrote:
On 11/9/19 2:44 AM, Patrick O'Callaghan wrote:
A good place to start, but I have found it does not cover things that go wrong. To me they are rather incomplete but a good starting point. I reference them in my full upgrade write up.
I'm with Ed on this. Use the official instructions. Only*after* the upgrade has succeeded, enable the testing repos if you wish.
poc
They are indeed a good place to start, but they only work under ideal conditions.
No, the upgrade plugin and the procedures are designed to work under "normal" or "ordinary" conditions.
So far I've upgraded 9 systems. Aside from 2 issues, one BZ that was fixed during the beta phase the another an issue with an malformed rpmfusion package, they all upgraded without issue and without having to use any additional parameters.
When you start always updating from "testing" repos you are doing things which aren't "normally" done. You should expect to have issues which others won't have.
The set of instructions you've given are unique to your way of doing things. In particular, enabling *all* repos. The majority of people won't do that. Some less informed folks may just blindly do it without regards to what may happen.
Frankly, if you're always updating from testing you should enable those repos in their respective repo files. That way they will be used on updates as well as upgrades.
On 11/9/19 4:24 AM, Ed Greshko wrote:
They are indeed a good place to start, but they only work under ideal conditions.
No, the upgrade plugin and the procedures are designed to work under "normal" or "ordinary" conditions.
Hi Ed,
To me that sounds like a distinction without a difference. But don't get too frustrated with me. I can also see it from your point of view.
So far I've upgraded 9 systems.
I have done four so far myself.
Two went perfectly. Two did not.
Most of the issue were of my own doing. named-chroot was not. Perl's modules, qemu-kvm, and buggered up EUFI was mine. Named changing the way it used its source ports could not be helped
Two server to go. But I will wait a month to make sure my server mock up has no issues or I have documented them before pulling the trigger.
Most of the issue were of my own doing. named-chroot was not. Perl's modules, qemu-kvm, and buggered up EUFI was mine.
Frankly, if you're always updating from testing you should enable those repos in their respective repo files. That way they will be used on updates as well as upgrades.
Sometimes I do and sometimes I don't. On my customers, never.
Did you miss the "note that they are specific to me" part in my original post?
Also keep in mind that what is "normal" to some people may not be "normal" to others. Fedora is an awesome piece of code with many, many different ways of using it.
Thank you for all the help and tips.
-T
p.s. both of the units I had issues with were operating, not down. This is in stark contrast with the issues I have with Windows, where the OS is bricked. Fedora is awesome code. My favorite OS ever!
-
Ed Greshko -
Patrick O'Callaghan -
ToddAndMargo