|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| {{autolang|base=yes}} | | {{autolang|base=yes}} |
|
| |
|
| PreUpgrade is an application to be run on an existing release which resolves and downloads packages required to upgrade to a newer release of Fedora. During the PreUpgrade process, users are free to continue using their systems. This gives an experience similar to a live upgrade. For additional information, please refer to the [[Features/PreUpgrade|PreUpgrade feature page]].
| | {{admon/warning|Preupgrade is obsolete |Preupgrade does not at present and will not ever work for upgrading to {{FedoraVersion|long|18}}, or any version after that. It was replaced by [[FedUp]], which was itself replaced by the [[DNF_system_upgrade]] plugin.}} |
| | |
| {{admon/tip|Upgrade to current release directly|Preupgrade provides an upgrade directly to the latest version of Fedora from the previous two versions. It is not necessary to upgrade to intermediate versions. For example, it is possible to upgrade from 15 to 17 directly, but not directly from earlier versions and not to 18 from any version.}} | |
| | |
| {{admon/warning|Preupgrade deprecated for Fedora 18|Preupgrade does not at present and will not ever work for upgrading to {{FedoraVersion|long|18}}, or any version after that. It was replaced by [[FedUp]].}}
| |
| | |
| = Prerequisites =
| |
| | |
| Your system cannot be upgraded with preupgrade if any of the following apply:
| |
| | |
| # If your /boot partition is on RAID. See [https://bugzilla.redhat.com/show_bug.cgi?id=500004 bug 500004].
| |
| # Your system is connected to a [https://fedorahosted.org/spacewalk/ Spacewalk] server and has rhnplugin enabled.
| |
| #* Disable the rhnplugin in '''/etc/yum/pluginconf.d/rhnplugin.conf'''
| |
| | |
| = Prepare the system =
| |
| | |
| While preupgrade can provide a generally smooth upgrade experience, the following steps are recommended before proceeding.
| |
| | |
| # ''Backup'' - Before performing any system maintenance, it is recommended that you back up all important data before proceeding.
| |
| # ''Update'' - Apply available updates Fedora updates before proceeding. As the root user, issue the following command: <pre>yum update</pre>
| |
| # ''Install'' - As of {{FedoraVersion|long|10}}, the preupgrade utility is included in a default Fedora install. The package can also be installed manually using the {{command|yum}} command: <pre>yum install preupgrade</pre>
| |
| | |
| = Perform the upgrade =
| |
| | |
| Typically, you will be prompted by {{package|PackageKit}} when upgrades are available for your system. However, if you choose to manually upgrade using {{command|preupgrade}}, the steps are listed below.
| |
| | |
| # Start the Preupgrade utility as root by opening a terminal and issuing the following command: <pre>preupgrade</pre> If you prefer an interactive command line application, the command {{command|preupgrade-cli}} is also available.
| |
| # On the ''Choose desired release'' screen, select the Fedora release you want to upgrade to , and click the ''Apply'' button.
| |
| # When all of the packages have downloaded, reboot your system to start the Fedora installer and upgrade to the next release.
| |
| | |
| == Remote upgrade ==
| |
| {{command|preupgrade}} has a switch that allows a remote upgrade via VNC. If you're using preupgrade for a remote upgrade, you'll more than likely be dealing with a machine that has a static IP. This is handled via the {{command|preupgrade}} command:
| |
| | |
| <pre>preupgrade-cli --vnc[=password] --ip=[IPADDR] --netmask=[NETMASK] --gateway=[IPADDR] --dns=[DNSSERVER] "Fedora 15 (Lovelock)"</pre>
| |
| | |
| = Common post-upgrade tasks =
| |
| | |
| After the upgrade is complete, additional steps are recommended to complete the process.
| |
| | |
| A complete guide is [http://fedorasolved.org/Members/fenris02/post_upgrade_cleanup here].
| |
| | |
| == Removing unsupported packages ==
| |
| | |
| Some packages may no longer be supported by the new release. You may wish to remove these packages because they will no longer get security updates, and they may cause later conflicts with supported packages. These can be identified with the following command: <pre>package-cleanup --orphans</pre>
| |
| | |
| == Examine {{filename|.rpmsave}} and {{filename|.rpmnew}} files ==
| |
| | |
| After completing the upgrade process, you may notice file names ending with {{filename|.rpmsave}} and {{filename|.rpmnew}}. Don't be alarmed. The upgrade process will always preserve any locally modified configuration files. The file names ending with {{filename|.rpmsave}} contain your local configuration changes. While the file names ending with {{filename|.rpmnew}} represent the configuration file originally packaged with the software.
| |
| | |
| You should examine all {{filename|.rpmsave}} and {{filename|.rpmnew}} files created by the upgrade. Depending on the differences, you may need to manually merge configuration files. You can locate all matching files using the {{command|find}} command.
| |
| | |
| <pre>find / -print | egrep "rpm(new|save)$"</pre>
| |
| | |
| You may wish to speed up repeat searches as you edit, by running the {{command|updatedb}} command first, and then using {{command|locate}} for subsequent searches.
| |
| | |
| <pre>updatedb
| |
| locate --regex "rpm(new|save)$"</pre>
| |
| | |
| Or you may use rpmconf package, which can help you with merge:
| |
| | |
| <pre>yum install rpmconf
| |
| rpmconf -a</pre>
| |
| | |
| == Verify the upgrade ==
| |
| | |
| Run
| |
| | |
| yum repolist
| |
| | |
| to confirm repository settings are correct. Then run
| |
| | |
| yum distro-sync
| |
| | |
| to sync the packages with the versions in the repository.
| |
| | |
| = Troubleshooting =
| |
| | |
| == Not enough space in /boot ==
| |
| | |
| Fedora 13 and above has a 500 MB default boot partition. The default {{filename|/boot}} filesystem size of 200MB for previous releases can be a problem for users upgrading from that release. In many cases, the diskspace that is likely free is just enough for preupgrade to find enough space to download the installer to but not quite enough for it to run the installer and install the new kernel after reboot. This section outlines several tips that have been known to work. As always when performing administrative tasks, be sure to back-up any data before proceeding.
| |
| | |
| There are two basic methods to make preupgrade work in this situation. In the first method, you need to free up sufficient space for the installer to install the new kernel packages. In the second method, you need to temporarily fill up enough of the space on {{filename|/boot}} to force preupgrade to download the installer after rebooting.
| |
| | |
| === Method 1: Free up space ===
| |
| | |
| '''First''', try to remove any kernel packages not currently in use on your system. The [http://skvidal.fedorapeople.org/misc/kernel-prune.py kernel-prune.py] script can be used to identify kernels that may be safely removed. If you choose to remove additional kernels, be prepared with [http://fedoraproject.org/en/get-fedora installation media] should you be unable to return to your previously installed system.
| |
| | |
| The installer will need approximately 26M of free space in /boot. Use the following command to determine the amount of free space in the /boot partition:
| |
| | |
| <pre>
| |
| df -h /boot
| |
| </pre>
| |
| | |
| To identify kernels that may be safely removed, run the following from a command line:
| |
| <pre>
| |
| curl -O 'http://skvidal.fedorapeople.org/misc/kernel-prune.py'
| |
| chmod a+x kernel-prune.py
| |
| ./kernel-prune.py
| |
| </pre>
| |
| | |
| Now, to actually remove the kernel versions listed by the above command, run the following as root:
| |
| <pre>
| |
| # PKGS=`./kernel-prune.py`
| |
| # echo $PKGS
| |
| # yum remove $PKGS
| |
| </pre>
| |
| | |
| | |
| '''Next''', adjust the number of reserved filesystem blocks using the command {{command|tune2fs}}. You'll first need to identify the block device for your {{filename|/boot}} file system. In the example below, {{filename|/dev/sda1}} is the block device for the {{filename|/boot}} filesystem.
| |
| <pre># mount | grep "/boot"
| |
| /dev/sda1 on /boot type ext4 (rw)</pre>
| |
| Now, adjust the number of reserved blocks for the {{filename|/boot}} filesystem using the command {{command|tune2fs}}. Normally, a small amount of space on ext filesystem formatted partitions is 'reserved' and can only be used by the system administrator; this is to prevent an entirely full partition from rendering a system unbootable, and allow the administrator some space in which to work in order to clean up 'full' partitions. However, neither of this cases really applies to the {{filename|/boot}} filesystem, so removing this reserved space is safe.
| |
| <pre># tune2fs -r 0 /dev/sda1</pre>
| |
| | |
| '''Last''', try removing unnecessary files from the {{filename|/boot}} filesystem. This will largely depend on how your system is set up. Removing the incorrect files may result in a unbootable system. Some candidates for removal include {{filename|/boot/efi}} and {{filename|/boot/grub/splash.xpm.gz}}.
| |
| | |
| === Method 2: Trick preupgrade into downloading the installer ===
| |
| | |
| This method requires you to have a wired connection to the internet during the install. If you are on wireless and cannot connect via an ethernet cable you will have to use Method 1 instead.
| |
| | |
| '''First''', find out how much space is available on the {{filename|/boot}} filesystem. {{command|df}} is the command you want for this:
| |
| <pre>
| |
| $ df /boot
| |
| Filesystem 1K-blocks Used Available Use% Mounted on
| |
| /dev/sda1 198337 30543 157554 17% /boot
| |
| </pre>
| |
| | |
| '''Second''', create a file that takes up enough space that preupgrade decides it cannot install stage2 now. Preupgrade needs approximately 120MB for the installer image so we'll make sure we have a bit less than 100MB. For the example filesystem, that means we need to fill up 60MB. Here's how to do that as root:
| |
| <pre>
| |
| # dd if=/dev/zero of=/boot/preupgrade_filler bs=1024 count=61440
| |
| # df /boot
| |
| Filesystem 1K-blocks Used Available Use% Mounted on
| |
| /dev/sda1 198337 92224 95873 50% /boot
| |
| </pre>
| |
| | |
| '''Third''', run preupgrade as normal. In the early stages, before downloading packages, preupgrade should tell you that there wasn't enough room to download part of the installer but it can download it after reboot if you have a wired connection to the network. You can click continue for that. When preupgrade is done don't reboot immediately. Instead, remove the {{filename|/boot/preupgrade_filler}} file and make sure your computer is connected to the network via an ethernet cable. Then you can reboot.
| |
| <pre>
| |
| # rm /boot/preupgrade_filler
| |
| </pre>
| |
| | |
| '''Fourth''', the computer should boot into the installer, connect to the internet via the ethernet cable and start downloading the stage2 installer image. Then it should continue upgrading as normal.
| |
| | |
| === Method 3 (for virtual machines): Use virt-resize ===
| |
| | |
| Use [http://libguestfs.org/virt-resize.1.html virt-resize] to increase the space in the boot partition.
| |
| | |
| You should read the [http://libguestfs.org/virt-resize.1.html manual page] carefully first, the following instructions are just an outline. The virtual machine <b>must be shut down</b> before you resize it.
| |
| | |
| <pre>
| |
| # yum install /usr/bin/virt-resize
| |
| # lvrename /dev/vg_host/guest /dev/vg_host/guest.old
| |
| # virt-filesystems -a /dev/vg_host/guest.old --all --long -h
| |
| </pre>
| |
| | |
| In the lvcreate command, choose a size about 1GB larger than the current size:
| |
| | |
| <pre>
| |
| # lvcreate -L 10G -n guest /dev/vg_host
| |
| </pre>
| |
| | |
| For a Fedora ≤ 15 guest that has partition 1 = boot and partition 2 = physical volume, you could use a command like this, but please read the manual:
| |
| | |
| <pre>
| |
| # virt-resize /dev/vg_host/guest.old /dev/vg_host/guest \
| |
| --resize /dev/sda1=+300M --expand /dev/sda2
| |
| </pre>
| |
| | |
| <b>Check that resizing was successful and that the guest boots</b> before deleting the old guest.
| |
| | |
| <pre>
| |
| # lvremove /dev/vg_host/guest.old
| |
| </pre>
| |
| | |
| ==Upgrade does not install upon reboot==
| |
| | |
| | |
| ===Explanation===
| |
| | |
| | |
| If you have a multiboot configuration, the <code>/boot</code> menu that grub uses might be different from the <code>/boot</code> menu that preupgrade modifies. In this case, you will need to point grub to the appropriate file to complete upgrade upon reboot. If this is not done, once preupgrade has completed downloading and installing files, upon reboot no change will be visible. The system will simply reboot as to the older version.
| |
| | |
| Preupgrade boots into an upgrade kernel as an intermediate step. Once the system has been upgraded, preupgrade replaces the temporary upgrade kernel option with an option for the upgraded kernel. In other words, there are two modifications made to the bootloader: a temporary upgrade option, followed by an option that is permanent until the next upgrade.
| |
| | |
| The grub bootloader can be used to boot from its command line, or <code>/boot/grub/menu.lst</code> can be modified to create a boot menu option. ([http://en.wikipedia.org/wiki/File:GRUB_screenshot.png Example screenshot of grub boot menu.]) ([http://www.gnu.org/software/grub/manual/grub.html For further detail on grub, refer to the grub manual.])
| |
| | |
| Either grub option can be used for either preupgrade step. To be comprehensive, the following describes both the command line option and doing so by editing the <code>menu.lst</code> file.
| |
| | |
| However, since the upgrade should only be run once, and the upgraded system will probably require repeated booting, the most expedient approach is probably to manually boot the upgrade via the grub command line, then once the upgrade has completed, to add an option to <code>menu.lst</code> add the upgraded Fedora installation to the grub boot menu. This would correspond to using Method 1, Steps 1 - 3, followed by Method 2, Step 4.
| |
| | |
| If you don't have multiboot configuration and/or you are using Grub2, see Method 3, STEP 3.
| |
| | |
| ===Method 1: Boot Manually from Grub Command Line===
| |
| | |
| | |
| '''STEP 1: Identify Partition Location'''
| |
| | |
| Identify the drive and partition of your Fedora <code>/boot</code> folder. (See [http://www.gnu.org/software/grub/manual/html_node/Naming-convention.html Grub Naming Convention] for details.) For example, if you installed Fedora entirely on the fourteenth partition of a second hard drive, <code>/boot</code> would be located on <code>root (hd1,13)</code>
| |
| | |
| | |
| '''STEP 2: Boot from Partition Location'''
| |
| | |
| Upon reboot, enter 'c' to enter the grub command line. Using the appropriate drive and partition numbers, enter the following commands:
| |
| <pre>root (hd1,13)
| |
| kernel /boot/upgrade/vmlinuz
| |
| initrd /boot/upgrade/initrd.img
| |
| boot</pre>
| |
| | |
| This will boot the upgrade installation.
| |
| | |
| | |
| '''STEP 3: Select Installation Image'''
| |
| | |
| The upgrade installation will then run an ncurses dialog. After selecting language and keyboard types, select <code>hard drive</code> for <code>installation method</code>. The next dialog box will require partition and directory information of the installation image. Select the partition from the drop-down menu. (Note that the numbering will be one off from the grub partition. In other words <code>root (hd1,13)</code> will appear as <code>/dev/sdf14</code>.) Finally, enter the location of the install image file: <code>/boot/upgrade/install.img</code>.
| |
| | |
| The installation will run normally at this point. After completing the upgrade, you will need to either boot the upgraded system manually by entering the newly installed <code>kernel</code> and <code>initrd.img</code> files at the grub command line, or add an entry to the <code>menu.lst</code> file. This step is detailed in the next section.
| |
| | |
| | |
| ===Method 2: Edit the Grub <code>menu.lst</code> File===
| |
| | |
| | |
| As an alternative to entering the commands at the grub command prompt upon reboot, you can also edit grub's <code>menu.lst</code> file to add an option that will allow you to select booting to the upgrade process from grub's boot menu. Since the upgrade should only be run once, after you've upgraded you will then need to re-edit <code>menu.lst</code>, remove the upgrade boot menu option, and add a boot entry for the new kernel.
| |
| | |
| | |
| '''STEP 1: Identify Partition Location'''
| |
| | |
| Identify the drive and partition of your Fedora <code>/boot</code> folder. [http://www.gnu.org/software/grub/manual/html_node/Naming-convention.html Grub Naming Convention]. For example, if you installed Fedora entirely on the fourteenth partition of a second hard drive, <code>/boot</code> would be located on <code>root (hd1,13)</code>
| |
| | |
| | |
| '''STEP 2: Edit <code>menu.lst</code>'''
| |
| | |
| Locate and open the <code>/boot/grub/menu.lst</code> file that grub actually uses. If this file is on another partition, check the <code>/media</code> files.
| |
| | |
| Using the appropriate drive and partition information in the <code>root</code> line format, add the following entry to the <code>menu.lst</code> file:
| |
| | |
| <pre>title Fedora Upgrade
| |
| root (hd*,*)
| |
| kernel /boot/upgrade/vmlinuz
| |
| initrd /boot/upgrade/initrd.img
| |
| savedefault
| |
| boot</pre>
| |
| | |
| Save the file, and reboot. Select the <code>Fedora Upgrade</code> from the grub boot menu.
| |
| | |
| | |
| '''STEP 3: Select Installation Image'''
| |
| | |
| The upgrade installation will then run an ncurses dialog. After selecting language and keyboard types, select <code>hard drive</code> for <code>installation method</code>. The next dialog box will require partition and directory information of the installation image. Select the partition from the drop-down menu. (Note that the numbering will be one off from the grub partition. In other words <code>root (hd1,13)</code> will appear as <code>/dev/sdf14</code>.)
| |
| | |
| Finally, enter the location of the install image file: <code>/boot/upgrade/install.img</code>. The installation will run normally at this point.
| |
| | |
| | |
| '''STEP 4: Cleanup <code>menu.lst</code>'''
| |
| | |
| After completing the upgrade, you will need to either boot the upgraded system manually by entering the newly installed <code>kernel</code> and <code>initrd.img</code> files at the grub command line, or by adding an entry to the <code>menu.lst</code> file.
| |
| | |
| The following is an example of a grub entry for a Fedora Core 10 installation, located on the fourteenth partition of the second hard drive.
| |
| | |
| <pre>title Fedora Core 10 (on /dev/sdb14)
| |
| root (hd1,13)
| |
| kernel /boot/vmlinuz-2.6.27.5-117.fc10.x86_64 ro quiet splash
| |
| initrd /boot/initrd-2.6.27.5-117.fc10.x86_64
| |
| savedefault
| |
| boot</pre>
| |
| | |
| Locate the updated <code>kernel </code> and <code>initrd</code> files located in the <code>/boot</code> folder of the Fedora partition, and create an entry with modified <code>title, kernel,</code> and <code>initrd</code> lines that will match those of the upgrade.
| |
| | |
| Finally, remove the upgrade boot entry from <code>menu.lst</code>.
| |
| | |
| ===Method 3: Edit Grub2 configuration===
| |
| | |
| In case you have Grub2, previous methods won't work.
| |
| | |
| '''STEP 1: Determinate your /boot partition UUID'''
| |
| | |
| To find out your /boot partition UUID, use this command:
| |
| | |
| <pre>grep /boot /etc/fstab</pre>
| |
| | |
| You will get something like this:
| |
| | |
| <pre>UUID=a52c2516-0db2-4899-b36e-970f8d105d25 /boot ext4 defaults 1 2</pre>
| |
| | |
| Now you know the UUID is a52c2516-0db2-4899-b36e-970f8d105d25.
| |
| | |
| In case you've got something like this:
| |
| | |
| <pre>/dev/sda1 /boot ext4 defaults 1 2</pre>
| |
| | |
| You'll have to use the following command to get the UUID.
| |
| | |
| <pre>ls -l /dev/disk/by-uuid/</pre>
| |
| | |
| You should have something like this:
| |
| | |
| <pre>lrwxrwxrwx. 1 root root 10 2. zář 12.17 a52c2516-0db2-4899-b36e-970f8d105d25 -> ../../sda1
| |
| lrwxrwxrwx. 1 root root 10 2. sep 12.17 cdab214e-9644-4dfe-a168-dbb06859a87d -> ../../dm-0
| |
| lrwxrwxrwx. 1 root root 10 2. sep 12.17 69ddda79-4c07-4a2b-a66a-54090298707a -> ../../dm-2
| |
| lrwxrwxrwx. 1 root root 10 2. sep 12.17 7b10a710-c53d-4c8b-bf5f-eed39793df38 -> ../../dm-1</pre>
| |
| | |
| Now you can see /boot is on /dev/sda1 with UUID a52c2516-0db2-4899-b36e-970f8d105d25.
| |
| | |
| '''STEP 2: Add the record to /etc/grub2.conf'''
| |
| | |
| Open the file and find the block with menuentries.
| |
| | |
| <pre>menuentry 'Fedora...</pre>
| |
| | |
| Abov that add the new menuentry:
| |
| | |
| <pre>menuentry 'Upgarde Fedora' --class gnu-linux --class gnu --class os {
| |
| linux /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=a52c2516-0db2-4899-b36e-970f8d105d25:/upgrade/ks.cfg stage2=hd:UUID=a52c2516-0db2-4899-b36e-970f8d105d25:/upgrade/squashfs.img
| |
| initrd /upgrade/initrd.img
| |
| }</pre> | |
| | |
| Replace a52c2516-0db2-4899-b36e-970f8d105d25 with your UUID. You might got this menuentry already there, see STEP 3.
| |
| | |
| | |
| '''STEP 3: Set the timeout'''
| |
| | |
| You might have Grub timeout set to 0. In this case, you'll have to set it to something more (e.g. 5).
| |
| | |
| In the configuration file from STEP 2, find this:
| |
| | |
| <pre>set timeout=0</pre>
| |
| | |
| And change it:
| |
| | |
| <pre>set timeout=5</pre>
| |
|
| |
|
| [[Category:Documentation]] | | [[Category:Documentation]] |
| [[Category:How to]] | | [[Category:How to]] |
| [[Category:PreUpgrade]] | | [[Category:PreUpgrade]] |
