Upgrading to the newest Fedora release


 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements UNIX and Linux RSS News Upgrading to the newest Fedora release
# 1  
Old 11-25-2008
Upgrading to the newest Fedora release

11-25-2008 02:00 AM
With Fedora 10 scheduled for release today, many users are thinking about how they are going to upgrade. A complete upgrade is something you do no more than twice a year, so the details are easy to forget. Also, the Fedora upgrade process, which centers on pointing to a new repository, is more complex than, say, the equivalent Debian process, in which repositories remain constant and only their contents change with a new release. But an even stronger reason for the uncertainty is that a Fedora system can be upgraded in at least four ways, each of which has its advantages and disadvantages.



Source...
Login or Register to Ask a Question

Previous Thread | Next Thread

3 More Discussions You Might Find Interesting

1. Debian

Upgrading Ubuntu Server (10.04) using do-release-upgrade

I have a small server in work, essentially a desktop with Ubuntu Server 10.04 LTS. For the first time in it's life, I've started to get errors when running scripts involving large files. So before I give up on it, I was thinking of maybe getting the newer version of Ubuntu Server 14.04. I was... (4 Replies)
Discussion started by: Cludgie
4 Replies

2. Linux

Unable to update Fedora after upgrading from Fedora17 to Fedora18

I have just upgraded to fedora 18 from 17 using fedup tool. The upgradation process succeeded and I can feel the new desktop appearance of fedora18. when I tried to update using yum update. I can see that the fedora17 files are not removed completely and they are also listed below the files to... (1 Reply)
Discussion started by: vaibhavvsk
1 Replies

3. Ubuntu

upgrading from ubuntu 710 gusty to the new release from synaptic ?

i notice when i was in the synaptic manage the other day that the new release KDE 4 was there can i upgrade from synaptic or do i need to download the files from a different source? currently running kubuntu 7.10 gusty and haven't seened any kind of updates come through that gave me the option to... (1 Reply)
Discussion started by: ksnovice
1 Replies
Login or Register to Ask a Question
DH_SYSTEMD_START(1)						     Debhelper						       DH_SYSTEMD_START(1)

NAME
dh_systemd_start - start/stop/restart systemd unit files SYNOPSIS
dh_systemd_start [debhelperoptions] [--restart-after-upgrade] [--no-stop-on-upgrade] [unitfile...] DESCRIPTION
dh_systemd_start is a debhelper program that is responsible for starting/stopping or restarting systemd unit files in case no corresponding sysv init script is available. As with dh_installinit, the unit file is stopped before upgrades and started afterwards (unless --restart-after-upgrade is specified, in which case it will only be restarted after the upgrade). This logic is not used when there is a corresponding SysV init script because invoke-rc.d performs the stop/start/restart in that case. OPTIONS
--restart-after-upgrade Do not stop the unit file until after the package upgrade has been completed. This is the default behaviour in compat 10. In earlier compat levels the default was to stop the unit file in the prerm, and start it again in the postinst. This can be useful for daemons that should not have a possibly long downtime during upgrade. But you should make sure that the daemon will not get confused by the package being upgraded while it's running before using this option. --no-restart-after-upgrade Undo a previous --restart-after-upgrade (or the default of compat 10). If no other options are given, this will cause the service to be stopped in the prerm script and started again in the postinst script. -r, --no-stop-on-upgrade, --no-restart-on-upgrade Do not stop service on upgrade. --no-start Do not start the unit file after upgrades and after initial installation (the latter is only relevant for services without a corresponding init script). NOTES
Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command (with the same arguments). Otherwise, it may cause multiple instances of the same text to be added to maintainer scripts. Note that dh_systemd_start should be run after dh_installinit so that it can detect corresponding SysV init scripts. The default sequence in dh does the right thing, this note is only relevant when you are calling dh_systemd_start manually. SEE ALSO
debhelper(7) AUTHORS
pkg-systemd-maintainers@lists.alioth.debian.org 11.1.6ubuntu2 2018-05-10 DH_SYSTEMD_START(1)