The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Difference between revisions of "Upgrade Instructions/1.2-release"
(add orphaned packages explanation.) |
m (Add instructions for when update doesn't work because of incompatible C++ abi changes) |
||
(18 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
<languages/> | |||
<translate> | |||
<!--T:1--> | |||
{{Important|The goal of these instructions is to provide Funtoo Linux users with a reliable, consistent set of instructions for upgrading Funtoo Linux from 1.0 to 1.2. Please assist in ensuring that these instructions are complete and guide users through any potential complications. Since this is a wiki, make changes to the page that are needed to make these instructions 100% reliable. Thank you!}} | {{Important|The goal of these instructions is to provide Funtoo Linux users with a reliable, consistent set of instructions for upgrading Funtoo Linux from 1.0 to 1.2. Please assist in ensuring that these instructions are complete and guide users through any potential complications. Since this is a wiki, make changes to the page that are needed to make these instructions 100% reliable. Thank you!}} | ||
<!--T:2--> | |||
These instructions will guide you through the process of upgrading your system from Funtoo Linux 1.0 to 1.2. First, please make sure that you have created a backup of your system. If you choose to proceed without | These instructions will guide you through the process of upgrading your system from Funtoo Linux 1.0 to 1.2. First, please make sure that you have created a backup of your system. If you choose to proceed without | ||
a backup, then you are assuming the risk of a broken system and dealing with fixing it or re-installing. While these install steps are fairly robust, we will | a backup, then you are assuming the risk of a broken system and dealing with fixing it or re-installing. While these install steps are fairly robust, we will | ||
Line 6: | Line 10: | ||
this will not happen, but since the possibility exists, it is best to be prepared for this possibility, particularly on critical systems. | this will not happen, but since the possibility exists, it is best to be prepared for this possibility, particularly on critical systems. | ||
First, you will want to run ego sync and upgrade to ego-2.4. | <!--T:3--> | ||
Now, edit your {{f|/var/lib/portage/world}} file. Look for catpkgs (ie. "category/packagename") that you no longer use or need on your system and remove them. Also consider packages you may have installed | |||
with {{c|--oneshot}} that are not in the world file but should be, and add them. Portage will use {{f|/var/lib/portage/world}} as the master list of packages that should be on | |||
your system. We will now look into cleaning up any unnecessary packages that are not in the world set. We want to remove these packages for a couple of reasons. First, | |||
they will not get upgraded with a {{c|@world}} update. Second, because they are not included in {{c|@world}}, they could be outdated and have old and problematic dependencies that could hamper our upgrade, since portage will not want to "break" dependencies for these orphaned packages. Third, when we do an {{c|emerge @preserved-rebuild}}, we may end up rebuilding packages that we don't need. So removing unnecessary packages is a good idea for quite a few reasons. | |||
<!--T:4--> | |||
{{Note|You may be wondering -- what are these packages on my system that are not part of the world set? They could be a number of things. First, they could be build dependencies for certain packages. They could possibly be old slots of packages you already use -- for example, an old version of PHP. The could also be packages that were dependencies of certain packages, but are no longer needed by those packages -- possibly due to changes in {{c|USE}} flags. Often, virtuals are part of this group of packages, and it is generally safe for virtuals to be removed. They will get re-emerged in the future if referenced by an ebuild.}} | |||
<!--T:5--> | |||
Run the following command and carefully review its output. Do not say "y" at this point: | |||
<!--T:6--> | |||
{{console|body= | |||
# ##i##emerge -p --depclean --ignore-soname-deps=n | less | |||
}} | |||
<!--T:7--> | |||
{{Note|The {{c|1=--ignore-soname-deps=n}} option will prevent packages that provide necessary libraries from being removed, even if they appear to be "orphaned." This is an additional safety measure when cleaning dependencies from your system.}} | |||
<!--T:8--> | |||
Now, review the list of packages that are going to be removed. See anything in this list that you know you need? This would indicate that you need to add the cat/pkg | |||
to {{f|/var/lib/portage/world}} before proceeding. Once the list looks OK, type: | |||
<!--T:9--> | |||
{{console|body= | |||
# ##i##emerge -a --depclean --ignore-soname-deps=n | |||
}} | |||
<!--T:10--> | |||
...And type "y" [enter] to remove old packages. | |||
<!--T:11--> | |||
Now, you should have a still-functioning system, but with all "extra" packages removed. Now it is time to upgrade the packages that remain. | |||
<!--T:12--> | |||
Now you will want to run {{c|ego sync}} and upgrade to the latest ego-2.4.x series available. | |||
{{console|body= | |||
# ##i## ego sync | |||
# ##i## emerge -C boot-update | |||
# ##i## emerge -v1 ego | |||
}} | |||
<!--T:13--> | |||
If you have difficulty satisfying deps for it for whatever reason, the following should work: | |||
{{console|body= | |||
# ##i## emerge -C boot-update | |||
# ##i## emerge -v1 --nodeps ego | |||
}} | |||
<!--T:14--> | |||
If you still cannot merge using emerge, the following should work (note that this will fail if you don't have the ebuild in your tree, and ego thinks it is at its highest revision): | |||
{{console|body= | |||
# ##i## cd /var/git/meta-repo/kits/core-kit/app-admin/ego | |||
# ##i## ebuild ego-2.6.3.ebuild merge | |||
}} | |||
If the foregoing fails, this will definitely pull in the latest ego and allow you to sync properly: | |||
{{console|body= | {{console|body= | ||
# ##i## | # ##i## git clone https://github.com/funtoo/ego.git | ||
# ##i## | # ##i## cd ego | ||
# ##i## ./ego sync | |||
}} | }} | ||
Once the new ego is merged, edit your /etc/ego.conf to look like this: | Once the new ego is merged, edit your /etc/ego.conf to look like this: | ||
<!--T:15--> | |||
{{file|name=/etc/ego.conf|body= | {{file|name=/etc/ego.conf|body= | ||
[global] | [global] | ||
<!--T:16--> | |||
release = 1.2 | release = 1.2 | ||
}} | }} | ||
<!--T:17--> | |||
Now, run the following steps as root. | Now, run the following steps as root. | ||
<!--T:18--> | |||
{{console|body= | {{console|body= | ||
# ##i##ego sync | # ##i##ego sync | ||
}} | }} | ||
<!--T:19--> | |||
This will activate the new 1.2 kits. Now, time to start upgrading: | This will activate the new 1.2 kits. Now, time to start upgrading: | ||
<!--T:20--> | |||
{{console|body= | {{console|body= | ||
# ##i##emerge -u1 | # ##i##emerge -u1 gcc | ||
}} | }} | ||
This will upgrade gcc. | <!--T:21--> | ||
This will upgrade gcc. | |||
<!--T:22--> | |||
This is an ideal time to review the subarch setting of your Funtoo Linux installation. Funtoo Linux 1.2 now has optimizations available for 5th and 6th-generation Intel | |||
Core processors, as well as Ryzen processors. View your current subarch, as well as available subarches, by typing the following command: | |||
<!--T:23--> | |||
{{console|body= | {{console|body= | ||
# ##i## | # ##i##ego profile list subarch | ||
=== ##g##subarch##!g##: === <!--T:24--> | |||
<!--T:25--> | |||
amd64-bulldozer, amd64-excavator, amd64-jaguar, amd64-k10 | |||
amd64-k8, amd64-k8+sse3, amd64-piledriver, amd64-steamroller | |||
amd64-zen, atom_64, btver1_64, core-avx-i, core2_64, corei7 | |||
generic_64, intel64-broadwell, intel64-haswell, intel64-ivybridge | |||
intel64-nehalem, intel64-sandybridge, intel64-silvermont, intel64-skylake | |||
##c##intel64-westmere##!c##*, native_64, nocona, opteron_64, xen-pentium4+sse3_64 | |||
<!--T:26--> | |||
# | |||
}} | }} | ||
<!--T:27--> | |||
If desired and supported by your CPU, you can now update your subarch to a more optimized subarch for your hardware. The new subarch profiles available are: | |||
<!--T:28--> | |||
* {{c|intel64-skylake}} - Optimized for Intel Core 6th Generation Processors (see [[intel64-skylake]] for more info.) | |||
* {{c|intel64-broadwell}} - Optimized for Intel Core 5th Generation Processors (see [[intel64-broadwell]] for more info.) | |||
* {{c|amd64-zen}} - Optimized for AMD Ryzen Processors. | |||
<!--T:29--> | |||
Use the {{c|lscpu}} command to view information about your CPU and do a web search for its name to determine what generation CPU it is. Then, the system's subarch | |||
can be changed as follows: | |||
{{console|body= | {{console|body= | ||
# ##i## | # ##i##ego profile subarch intel64-skylake | ||
# ## | === ##g##Enabled Profiles##!g##: === <!--T:30--> | ||
<!--T:31--> | |||
##b##arch##!b##: ##c##x86-64bit | |||
##b##build##!b##: ##c##current | |||
##b##subarch##!b##: ##c##intel64-skylake | |||
##b##flavor##!b##: ##c##core | |||
<!--T:32--> | |||
>>> Set subarch to intel64-skylake. | |||
##b##Updating profiles at /etc/portage/make.profile/parent... | |||
<!--T:33--> | |||
# | |||
}} | |||
<!--T:34--> | |||
Now that we have ensured that we have an optimal subarch set for your system, it's time to begin the process of rebuilding critical packages with the new compiler. We will start with glibc. Enter the following command: | |||
<!--T:35--> | |||
{{console|body= | {{console|body= | ||
# ##i##emerge - | # ##i##emerge -u1 glibc libnsl libtirpc rpcsvc-proto | ||
}} | }} | ||
<!--T:36--> | |||
Glibc and its dependencies/related packages will now be upgraded. | |||
<!--T:37--> | |||
to | Since moving to 1.2 also includes moving to python-3.6, perform the following steps: | ||
<!--T:38--> | |||
{{console|body= | {{console|body= | ||
# ##i##emerge - | # ##i##emerge -u1 =dev-lang/python-3.6* | ||
# ##i##emerge -C =dev-lang/python-3.4* | |||
}} | }} | ||
<!--T:39--> | |||
This will ensure that we have python-3.6 ready and installed, and the older python-3.4 removed. Removing python-3.4 is important to ensure that python modules upgrade properly. | |||
<!--T:40--> | |||
Some packages rely on a current ruby being available on the system, and having stale versions on your system can cause problems. To remove these from your system, run: | |||
<!--T:41--> | |||
{{console|body= | {{console|body= | ||
# ##i## | # ##i##emerge -C \<=dev-lang/ruby-2.3.0 | ||
}} | }} | ||
<!--T:42--> | |||
For upgrading to 1.2, you | |||
have to rebuild all packages, which will ensure that your system is fully optimized with the new gcc. | |||
<!--T:43--> | |||
{{Note|Include the {{c|1=--jobs=3}} (or higher number) option as a parameter to the {{c|emerge}} command if you have sufficient RAM and CPU cores to build several packages in parallel.}} | {{Note|Include the {{c|1=--jobs=3}} (or higher number) option as a parameter to the {{c|emerge}} command if you have sufficient RAM and CPU cores to build several packages in parallel.}} | ||
Here is | <!--T:44--> | ||
Here is what you need to run: | |||
<!--T:45--> | |||
{{console|body= | {{console|body= | ||
# ##i##emerge --emptytree -a @world | # ##i##emerge --emptytree -a @world | ||
}} | }} | ||
This will fully rebuild all packages on your system. It will take a lot | <!--T:46--> | ||
This will fully rebuild all packages on your system. It will take a lot of time, but will ensure everything is freshly rebuilt. Once completed successfully, this will result in an up-to-date system, with potentially better-optimized binaries, benefiting from more recent gcc improvements. | |||
<!--T:47--> | |||
{{Note|If the preceding command fails, you should run 'emerge -uDN1 --keep-going @world' to ensure that all dependencies are fully resolved and rebuilt, then run the 'emerge --emptytree -a @world' command again to ensure that every package is rebuilt with the new gcc compiler. If *that* fails, you might need to run revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc in order to update the C++ abi for the new gcc.}} | |||
<!--T:48--> | |||
Finally, you will want to either run {{c|etc-update}} or {{c|dispatch-conf}}: | Finally, you will want to either run {{c|etc-update}} or {{c|dispatch-conf}}: | ||
<!--T:49--> | |||
{{console|body= | {{console|body= | ||
# ##i##etc-update | # ##i##etc-update | ||
}} | }} | ||
If your kernel has been upgraded, make the necessary changes to {{f|/etc/boot.conf}} to make the new kernel the default, and then re-run {{c|boot | <!--T:50--> | ||
If your kernel has been upgraded, make the necessary changes to {{f|/etc/boot.conf}} to make the new kernel the default, and then re-run {{c|ego boot update}}: | |||
<!--T:51--> | |||
{{console|body= | {{console|body= | ||
# ##i##boot | # ##i##ego boot update | ||
}} | }} | ||
<!--T:52--> | |||
Now is a good time to perform a pre-check of any packages that have been installed that may require configuration file updates. One notable example is php-fpm -- you may need to perform the following steps if your system uses php-fpm: | Now is a good time to perform a pre-check of any packages that have been installed that may require configuration file updates. One notable example is php-fpm -- you may need to perform the following steps if your system uses php-fpm: | ||
<!--T:53--> | |||
{{console|body= | {{console|body= | ||
# ##i##cp /etc/php/fpm-php-7.1/php* /etc/php/fpm-php-7.3/php* | # ##i##cp /etc/php/fpm-php-7.1/php* /etc/php/fpm-php-7.3/php* | ||
}} | }} | ||
<!--T:54--> | |||
This will ensure that the settings you use for the previously-installed version of php-fpm will be applied to the current version. | This will ensure that the settings you use for the previously-installed version of php-fpm will be applied to the current version. | ||
<!--T:55--> | |||
{{Note|If you find any other packages that need similar manual steps post-upgrade, please document them here for the benefit of others! Thanks.}} | {{Note|If you find any other packages that need similar manual steps post-upgrade, please document them here for the benefit of others! Thanks.}} | ||
<!--T:56--> | |||
At this point, the migration to 1.2 should be complete. At a convenient time, reboot your system, and perform a thorough check of all services to ensure they have started | At this point, the migration to 1.2 should be complete. At a convenient time, reboot your system, and perform a thorough check of all services to ensure they have started | ||
correctly: | correctly: | ||
<!--T:57--> | |||
{{console|body= | {{console|body= | ||
# ##i##reboot | # ##i##reboot | ||
}} | }} | ||
<!--T:58--> | |||
After reboot: | After reboot: | ||
<!--T:59--> | |||
{{console|body= | {{console|body= | ||
# ##i##rc-status | # ##i##rc-status | ||
}} | }} | ||
<!--T:60--> | |||
Now, perform a final check of any production services to ensure that they are operating properly, by loading web pages, sending test emails, etc. | Now, perform a final check of any production services to ensure that they are operating properly, by loading web pages, sending test emails, etc. | ||
<!--T:61--> | |||
At this point, you are now upgraded to Funtoo Linux 1.2! Please report any bugs to https://bugs.funtoo.org and let us know of any issues you experience, either as part of the upgrade, related to dependencies, or related to functionality on your upgraded system. | At this point, you are now upgraded to Funtoo Linux 1.2! Please report any bugs to https://bugs.funtoo.org and let us know of any issues you experience, either as part of the upgrade, related to dependencies, or related to functionality on your upgraded system. | ||
<!--T:62--> | |||
[[Category:Official Documentation]] | |||
[[Category:Upgrade Instructions]] | |||
</translate> |
Latest revision as of 18:04, January 28, 2019
The goal of these instructions is to provide Funtoo Linux users with a reliable, consistent set of instructions for upgrading Funtoo Linux from 1.0 to 1.2. Please assist in ensuring that these instructions are complete and guide users through any potential complications. Since this is a wiki, make changes to the page that are needed to make these instructions 100% reliable. Thank you!
These instructions will guide you through the process of upgrading your system from Funtoo Linux 1.0 to 1.2. First, please make sure that you have created a backup of your system. If you choose to proceed without a backup, then you are assuming the risk of a broken system and dealing with fixing it or re-installing. While these install steps are fairly robust, we will be removing what appear to be unused packages on the system, and while every precaution is taken to avoid breaking packages, in odd cases this could result in some packages being removed that you actually need. Typically this will not happen, but since the possibility exists, it is best to be prepared for this possibility, particularly on critical systems.
Now, edit your /var/lib/portage/world
file. Look for catpkgs (ie. "category/packagename") that you no longer use or need on your system and remove them. Also consider packages you may have installed
with --oneshot
that are not in the world file but should be, and add them. Portage will use /var/lib/portage/world
as the master list of packages that should be on
your system. We will now look into cleaning up any unnecessary packages that are not in the world set. We want to remove these packages for a couple of reasons. First,
they will not get upgraded with a @world
update. Second, because they are not included in @world
, they could be outdated and have old and problematic dependencies that could hamper our upgrade, since portage will not want to "break" dependencies for these orphaned packages. Third, when we do an emerge @preserved-rebuild
, we may end up rebuilding packages that we don't need. So removing unnecessary packages is a good idea for quite a few reasons.
You may be wondering -- what are these packages on my system that are not part of the world set? They could be a number of things. First, they could be build dependencies for certain packages. They could possibly be old slots of packages you already use -- for example, an old version of PHP. The could also be packages that were dependencies of certain packages, but are no longer needed by those packages -- possibly due to changes in USE
flags. Often, virtuals are part of this group of packages, and it is generally safe for virtuals to be removed. They will get re-emerged in the future if referenced by an ebuild.
Run the following command and carefully review its output. Do not say "y" at this point:
root # emerge -p --depclean --ignore-soname-deps=n
The --ignore-soname-deps=n
option will prevent packages that provide necessary libraries from being removed, even if they appear to be "orphaned." This is an additional safety measure when cleaning dependencies from your system.
Now, review the list of packages that are going to be removed. See anything in this list that you know you need? This would indicate that you need to add the cat/pkg
to /var/lib/portage/world
before proceeding. Once the list looks OK, type:
root # emerge -a --depclean --ignore-soname-deps=n
...And type "y" [enter] to remove old packages.
Now, you should have a still-functioning system, but with all "extra" packages removed. Now it is time to upgrade the packages that remain.
Now you will want to run ego sync
and upgrade to the latest ego-2.4.x series available.
root # ego sync root # emerge -C boot-update root # emerge -v1 ego
If you have difficulty satisfying deps for it for whatever reason, the following should work:
root # emerge -C boot-update root # emerge -v1 --nodeps ego
If you still cannot merge using emerge, the following should work (note that this will fail if you don't have the ebuild in your tree, and ego thinks it is at its highest revision):
root # cd /var/git/meta-repo/kits/core-kit/app-admin/ego root # ebuild ego-2.6.3.ebuild merge
If the foregoing fails, this will definitely pull in the latest ego and allow you to sync properly:
root # git clone https://github.com/funtoo/ego.git root # cd ego root # ./ego sync
Once the new ego is merged, edit your /etc/ego.conf to look like this:
/etc/ego.conf
[global]
release = 1.2
Now, run the following steps as root.
root # ego sync
This will activate the new 1.2 kits. Now, time to start upgrading:
root # emerge -u1 gcc
This will upgrade gcc.
This is an ideal time to review the subarch setting of your Funtoo Linux installation. Funtoo Linux 1.2 now has optimizations available for 5th and 6th-generation Intel Core processors, as well as Ryzen processors. View your current subarch, as well as available subarches, by typing the following command:
root # ego profile list subarch === subarch: === amd64-bulldozer, amd64-excavator, amd64-jaguar, amd64-k10 amd64-k8, amd64-k8+sse3, amd64-piledriver, amd64-steamroller amd64-zen, atom_64, btver1_64, core-avx-i, core2_64, corei7 generic_64, intel64-broadwell, intel64-haswell, intel64-ivybridge intel64-nehalem, intel64-sandybridge, intel64-silvermont, intel64-skylake intel64-westmere*, native_64, nocona, opteron_64, xen-pentium4+sse3_64 root #
If desired and supported by your CPU, you can now update your subarch to a more optimized subarch for your hardware. The new subarch profiles available are:
intel64-skylake
- Optimized for Intel Core 6th Generation Processors (see intel64-skylake for more info.)intel64-broadwell
- Optimized for Intel Core 5th Generation Processors (see intel64-broadwell for more info.)amd64-zen
- Optimized for AMD Ryzen Processors.
Use the lscpu
command to view information about your CPU and do a web search for its name to determine what generation CPU it is. Then, the system's subarch
can be changed as follows:
root # ego profile subarch intel64-skylake === Enabled Profiles: === arch: x86-64bit build: current subarch: intel64-skylake flavor: core >>> Set subarch to intel64-skylake. root ##b##Updating profiles at /etc/portage/make.profile/parent... root #
Now that we have ensured that we have an optimal subarch set for your system, it's time to begin the process of rebuilding critical packages with the new compiler. We will start with glibc. Enter the following command:
root # emerge -u1 glibc libnsl libtirpc rpcsvc-proto
Glibc and its dependencies/related packages will now be upgraded.
Since moving to 1.2 also includes moving to python-3.6, perform the following steps:
root # emerge -u1 =dev-lang/python-3.6* root # emerge -C =dev-lang/python-3.4*
This will ensure that we have python-3.6 ready and installed, and the older python-3.4 removed. Removing python-3.4 is important to ensure that python modules upgrade properly.
Some packages rely on a current ruby being available on the system, and having stale versions on your system can cause problems. To remove these from your system, run:
root # emerge -C \<=dev-lang/ruby-2.3.0
For upgrading to 1.2, you have to rebuild all packages, which will ensure that your system is fully optimized with the new gcc.
Include the --jobs=3
(or higher number) option as a parameter to the emerge
command if you have sufficient RAM and CPU cores to build several packages in parallel.
Here is what you need to run:
root # emerge --emptytree -a @world
This will fully rebuild all packages on your system. It will take a lot of time, but will ensure everything is freshly rebuilt. Once completed successfully, this will result in an up-to-date system, with potentially better-optimized binaries, benefiting from more recent gcc improvements.
If the preceding command fails, you should run 'emerge -uDN1 --keep-going @world' to ensure that all dependencies are fully resolved and rebuilt, then run the 'emerge --emptytree -a @world' command again to ensure that every package is rebuilt with the new gcc compiler. If *that* fails, you might need to run revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc in order to update the C++ abi for the new gcc.
Finally, you will want to either run etc-update
or dispatch-conf
:
root # etc-update
If your kernel has been upgraded, make the necessary changes to /etc/boot.conf
to make the new kernel the default, and then re-run ego boot update
:
root # ego boot update
Now is a good time to perform a pre-check of any packages that have been installed that may require configuration file updates. One notable example is php-fpm -- you may need to perform the following steps if your system uses php-fpm:
root # cp /etc/php/fpm-php-7.1/php* /etc/php/fpm-php-7.3/php*
This will ensure that the settings you use for the previously-installed version of php-fpm will be applied to the current version.
If you find any other packages that need similar manual steps post-upgrade, please document them here for the benefit of others! Thanks.
At this point, the migration to 1.2 should be complete. At a convenient time, reboot your system, and perform a thorough check of all services to ensure they have started correctly:
root # reboot
After reboot:
root # rc-status
Now, perform a final check of any production services to ensure that they are operating properly, by loading web pages, sending test emails, etc.
At this point, you are now upgraded to Funtoo Linux 1.2! Please report any bugs to https://bugs.funtoo.org and let us know of any issues you experience, either as part of the upgrade, related to dependencies, or related to functionality on your upgraded system.