Page DNF System Upgrade had incorrect looking headers.
Top level section "Optional post-ugrade tasks" had only one sub-section,
"Update system configuration files".
The next top level section "Upgraded package configurations"
seemingly continue with the exact same topic,
and had multiple sub-sections that seemed to fit better under
"Optional post-upgrade tasks".
Fixed by simply removing the header "Upgraded package configurations",
after that everything seems much better.
* Improve messaging regarding N->N+2 upgrades.
* Move some details regarding Rawhide issues to the specific Rawhide wiki page.
This generic guide doesn't need to go into detail about Rawhide issues,
because that makes it harder to read for general users (not interested in
Rawhide). Power users can follow a link.
* Update gnome-software screenshot (more recent, with graphics).
* Clearly state that upgrading using pure `dnf` or `fedora-upgrade` is
unsupported.
* Other small adjustments and clarifications, link fixes. Make section headlines
look consistent across articles (don't capitalize every word).
The current version of the page includes hardcoded, obsolete references
to e.g. Fedora 28, 30, and 31, which can be confusing.
Replace references with attributes, and add a new one, `{NEXTNEXTVER}`
for the branched example.
Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org>
This is now the second time when rpmconf reverted me
google-chrome-stable.repo file back to version where I have `enabled=0`.
It looks like this package generates the repo file in the post scriplet
and does not mention it in the list of installed files, this probably
tricks rpmconf to do an incorrect action. I would love to investigate
further and maybe file a bug for chrome/chromium, but now that I
finished my upgrade I can't look back why rpmconf thought this file
needs updating - scriplet looks like this:
YUM_REPO_FILE="/etc/yum.repos.d/google-chrome.repo"
install_yum() {
install_rpm_key
if [ ! "$REPOCONFIG" ]; then
return 0
fi
if [ -d "/etc/yum.repos.d" ]; then
cat > "$YUM_REPO_FILE" << REPOCONTENT
[google-chrome]
name=google-chrome
baseurl=$REPOCONFIG/$DEFAULT_ARCH
enabled=1
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub
REPOCONTENT
fi
}
It was likely some older version of the package. Anyway, I thought I'd
drop a warning note for others, because I accidentally disabled this
repo which left my Chrome on an old version for about a year until it
websites started warning me about an unsupported version. This is
dangerous, my main browser is Firefox but this could be a security
problem for others.
Use "reboot" consistently, emphasize the immediate no-prompt reboot, mention it's a console terminal, then a second reboot, and clean up step 6 language. This fixes issue #294 and I think is an improvement.
This is a personal preference, but the `fixfiles` command is a
convenient binary in Fedora that ships with SELinux to handle relabels.
It does the same thing, but note the use of the `-B` flag.
From the man pages:
> -B:
> If specified with onboot, this fixfiles will record the current date
> in the /.autorelabel file, so that it can be used later to speed up
> labeling. If used with restore, the restore will only affect files
> that were modified today.
I thought I would share this improvement upstream since I use this page
often, but I prefer this way of running more lean SELinux checks.
Signed-off-by: Justin W. Flory <git@jwf.io>
Add information on cleaning old symlinks in /usr in dnf-system-upgrade.adoc.
Fedora includes the symlinks utility, so it is easy to clean the old cruft.
Add information on cleaning old symlinks in /usr in dnf-system-upgrade.adoc.
Fedora includes the symlinks utility, so it is easy to clean the old cruft.
* Remove the unreviewed wiki content admonintion
* Remove unnecessary DNF arguments
* Remove references to 'Atomic Host' and replace with Fedora CoreOS and Fedora Silverblue
