Migrating between architectures: Difference between revisions

From ArchWiki
(Undo revision 743342 by Lahwaacz.bot (talk) — Link back to Chinese page)
Tag: Undo
 
(64 intermediate revisions by 31 users not shown)
Line 1: Line 1:
[[Category:Arch64]]
[[Category:System administration]]
[[Category:Getting and installing Arch]]
[[ja:再インストールせずにアーキテクチャを移行]]
[[fr:Migration 64 bits]]
[[ru:Migrating between architectures]]
[[zh-CN:Migrating Between Architectures Without Reinstalling]]
[[zh-hans:Migrating between architectures]]
This page documents two potential methods of migrating installed systems between i686 (32-bit) and x86_64 (64-bit) architectures, in either direction. The methods avoid reinstalling the entire system. One method uses a liveCD, the other modifies the system from within.
This page documents two potential methods of migrating installed systems from i686 (32-bit) to x86_64 (64-bit) architectures. The methods avoid a ''complete'' reinstall (i.e. wiping the hard drive). One method uses a liveCD, the other modifies the system from within.


{{Warning|Unless explicitly stated, all these methods are UNTESTED and may irreparably damage your system. Continue at your own risk.}}
{{Note|Technically this process still involves "reinstalling" since every package on the system must be replaced. These methods simply attempt to preserve as much as they can from your existing system.}}
{{Warning|Unless explicitly stated, all these methods are '''untested''' and may irreparably damage your system. Continue at your own risk.}}


== General preparation ==
== General preparation ==


=== Confirm 64-bit architecture ===
=== Confirm 64-bit architecture ===
If you are already running x86_64 but want to install i686 this is not relevant and you can skip this step.


In order to run 64-bit software, you must have a 64-bit capable CPU.  Most modern CPUs are capable of running 64-bit software. You may check your CPU with the following command:
In order to run 64-bit software, you must have a 64-bit capable CPU.  Most modern CPUs are capable of running 64-bit software. You may check your CPU with the following command:


  grep --color '\<lm\>' /proc/cpuinfo
  grep --color -w lm /proc/cpuinfo


For CPUs that support x86_64, this will return the {{ic|lm}} flag (“long mode”) highlighted. Beware that ''lahf_lm'' is a different flag and does not indicate 64-bit capability itself.
For CPUs that support x86_64, this will return the {{ic|lm}} flag (“long mode”) highlighted. Beware that ''lahf_lm'' is a different flag and does not indicate 64-bit capability itself.
Line 23: Line 22:
You should be prepared for {{ic|/var/cache/pacman/pkg}} to grow approximately twice its current size during the migration. This is assumes only packages that are currently installed are in the cache, as if “pacman -Sc” (clean) was recently run. The disk space increase is due to duplication between the i686 and x86_64 versions of each package.
You should be prepared for {{ic|/var/cache/pacman/pkg}} to grow approximately twice its current size during the migration. This is assumes only packages that are currently installed are in the cache, as if “pacman -Sc” (clean) was recently run. The disk space increase is due to duplication between the i686 and x86_64 versions of each package.


If you have not enough disk, please use ''[[gparted]]'' to resize the relevant partition, or mount another partition to ''/var/cache/pacman''.
If you have not enough disk, please use [[GParted]] to resize the relevant partition, or mount another partition to {{ic|/var/cache/pacman}}.


Please do not remove packages of the old architecture from the cache until the system is fully operating in the new architecture. Removing the packages too early may leave you unable to fall back and revert changes.
Please do not remove packages of the old architecture from the cache until the system is fully operating in the new architecture. Removing the packages too early may leave you unable to fall back and revert changes.


=== Power supply ===
=== Power supply ===
The migration may take a substantial amount of time, and it would be inconvenient to interrupt the process. You should plan on at least an hour, depending on the number and size of your installed packages and internet connection speed (although you can download everything before starting the critical part). Please make sure you are connected to a stable power source, preferably with some sort of failover or battery backup.
The migration may take a substantial amount of time, and it would be inconvenient to interrupt the process. You should plan on at least an hour, depending on the number and size of your installed packages and internet connection speed (although you can download everything before starting the critical part). Please make sure you are connected to a stable power source, preferably with some sort of failover or battery backup.


Line 34: Line 34:
If the migration fails halfway through, there are packages that can help sort out the situation, but they should be installed before the main packages are migrated. More details about using them under [[#Troubleshooting]] below.
If the migration fails halfway through, there are packages that can help sort out the situation, but they should be installed before the main packages are migrated. More details about using them under [[#Troubleshooting]] below.


One package is {{Pkg|busybox}}, which can be used to revert changes. It is statically linked and does not depend on any libraries. The 32-bit (i686) version should be installed, using
One package is {{Pkg|busybox}}, which can be used to revert changes. It is statically linked and does not depend on any libraries. The 32-bit (i686) version should be installed.
 
Another package is {{Pkg|lib32-glibc}}, from the [[multilib]] x86_64 repository.  It is probably only useful when migrating ''away'' from 32 bits; in any case you may safely skip this package.  You can use the package to run 32 bit programs by explicitly calling {{ic|/lib/ld-linux.so.2}}.
 
== Method 1: using the Arch LiveCD ==


# pacman -S busybox
# [https://archlinux.org/download/ Download] and burn the latest Arch Linux ISO.
# Boot the Arch LiveCD in x86_64 mode.
# Configure your network on the LiveCD.
# Mount your existing installation. For example: {{ic|mount /dev/sda1 /mnt}}.
# Edit the LiveCD {{ic|/etc/pacman.conf}} repositories to match the existing {{ic|/mnt/etc/pacman.conf}} repositories.
# Use the following commands to update the local pacman database and clear the cache directory.
  # pacman --root /mnt -Syy
  # pacman --root /mnt -Scc


Another package is {{Pkg|lib32-glibc}}, from the [[Multilib Project|Multilib]] x86_64 repository.  It is probably only useful when migrating ''away'' from 32 bits; in any case you may safely skip this package.  You can use the package to run 32 bit programs by explicitly calling {{ic|/lib/ld-linux.so.2}}. Install with:
:6. You might first re-install the {{Pkg|base}} group alone, then install any package that triggered an install error, identified using {{ic|pacman --root /mnt -Qo <error file>}}. Then repeat the {{Pkg|base}} group install, until it installs cleanly without errors.
  # pacman --root /mnt -S base


# pacman -S lib32-glibc
:7. Use the following command to get a list of all your installed packages and then reinstall them.
  # pacman --root /mnt -Qnq | pacman --root /mnt -S -


== Method 1: Utilising the Arch LiveCD ==
:8. You could run the command twice, because many packages fail to run their post-install scripts first time. This is due to sed, grep, perl, etc. being of the wrong architecture.  Or you can make note of any individual package-re-install that throws an error and then go back after the upgrade completes to re-install just those packages.


# Download, burn and boot the 64-bit Arch ISO LiveCD
:Also, if you see an error about not enough disk space, you can filter the package list alphabetically and upgrade in stages, with for instance {{ic|<nowiki>...| grep '^[a-k]' |...</nowiki>}}, then perhaps {{ic|'^l'}} and {{ic|'^[m-z]'}}. In this case you would also have to run {{ic|pacman --root /mnt -Scc}} after each install stage to free disk space. Or since all packages are downloaded in the Live CD ramfs, you can also mount a partition or make a symlink pointing to {{ic|/var/cache/pacman/pkg}} (e.g. {{ic|ln -s /mnt/var/cache/pacman/pkg /var/cache/pacman/pkg}}).
# Configure your network on the LiveCD, then pacman to use your new architecture repos
# Mount your existing installation to {{ic|/mnt}} directory. For example: {{ic|mount /dev/sda1 /mnt}}
# Use the following script to update the local pacman database, get a list of all your installed packages and then reinstall them.
# You should probably run the script twice, because many packages fail to run their post-install scripts first time. This is due to sed, grep, perl, etc. being of the wrong architecture.
# You might also need to update the initrd, chroot into /mnt and run mkinitcpio -p linux.


#!/bin/bash
:9. Finally, run
MOUNTED_INSTALL='/mnt'
TEMP_FILE='/tmp/packages.list'
pacman --root $MOUNTED_INSTALL -Sy
pacman --root $MOUNTED_INSTALL --cachedir $MOUNTED_INSTALL/var/cache/pacman/pkg --noconfirm -Sg base base-devel
pacman --root $MOUNTED_INSTALL -Qq > $TEMP_FILE
for PKG in $(cat $TEMP_FILE) ; do
    pacman --root $MOUNTED_INSTALL --cachedir $MOUNTED_INSTALL/var/cache/pacman/pkg --noconfirm -S $PKG
done
exit 0


After rebooting to your new 64-bit system, run this command to find out what 32-bit binaries you still have and reinstall them:
  # arch-chroot /mnt
  # mkinitcpio -p linux


  find /usr/bin -type f -exec bash -c 'file {} | grep 32-bit' \;
:10. Also, see if your boot loader needs to be migrated. For instance:
  # grub-install --recheck /dev/sda


== Method 2: From a running system ==
:11. After rebooting to your new 64-bit system, edit and then move {{ic|/etc/makepkg.conf.pacnew}} to {{ic|/etc/makepkg.conf}}, to migrate the CPU architecture. Then rebuild the "foreign" packages, which will include packages from the [[AUR]].
 
: You might first want to remove certain orphaned foreign packages before trying to rebuild them.  Run this command to find out what 32-bit binaries you still have and reinstall them:
  $ LC_ALL=C pacman -Qo `find /usr/bin -type f -exec bash -c 'file "{}" | grep 32-bit' \; | cut -d':' -f1` | cut -d' ' -f5 | sort | uniq | tee list
 
== Method 2: from a running system ==


Ensure that your system is fully updated and functioning before proceeding.
Ensure that your system is fully updated and functioning before proceeding.
  # pacman -Syu
  # pacman -Syu


Line 84: Line 88:
  # pacman -Qqn | pacman -Sw -
  # pacman -Qqn | pacman -Sw -


or use bacman from {{Pkg|pacman}} package to generate them.
or use {{AUR|fakepkg}} package to generate them.


If you are migrating away from 32 bits, now is the time to install 32-bit Busybox:
==== Install busybox ====


# pacman -S busybox
If you are migrating from 32 bits to 64 bits, now is the time to install 32-bit {{Pkg|busybox}}. Install {{Pkg|busybox}} package.


==== Change Pacman architecture ====
==== Change Pacman architecture ====


Edit the ''/etc/pacman.conf'' file and change ''Architecture'' from {{ic|auto}} to the new value. These ''sed'' commands may be used:
Edit the {{ic|/etc/pacman.conf}} file and change ''Architecture'' from {{ic|auto}} to {{ic|x86_64}}.
 
For x86_64:
 
# sed -i  '/^Architecture =/s/auto/x86_64/' /etc/pacman.conf
 
and for i686:
 
# sed -i  '/^Architecture =/s/auto/i686/' /etc/pacman.conf


Make sure the server lists in ''/etc/pacman.conf'' and ''/etc/pacman.d/mirrorlist'' use ''$arch'' instead of explicitly specifying ''i686'' or ''x86_64''. Now force Pacman to synchronize with the new repositories:
Make sure the server lists in {{ic|/etc/pacman.conf}} and {{ic|/etc/pacman.d/mirrorlist}} use {{ic|$arch}} instead of explicitly specifying {{ic|i686}} or {{ic|x86_64}}. Now force Pacman to synchronize with the new repositories:


  # pacman -Syy                    # force sync new architecture repositories
  # pacman -Syy                    # force sync new architecture repositories
Line 112: Line 108:
  # pacman -Sw $(pacman -Qqn|sed '/^lib32-/ d')  # download new package versions
  # pacman -Sw $(pacman -Qqn|sed '/^lib32-/ d')  # download new package versions


If migrating to 32 bits, install the 32-bit {{Pkg|busybox}} fallback now that Pacman has been configured with the 32-bit architecture.


If migrating to 32 bits, install the 32-bit Busybox fallback now that Pacman has been configured with the 32-bit architecture:
{{Warning|Do not install the ''lib32-glibc'' package now. After a ''ldconfig'', when you install ''linux'', the generated image will have libraries like ''librt.so'' in '{{ic|/usr/lib32}}, where binaries during boot will not search, resulting in a boot failure.}}
 
# pacman -S busybox
 
{{Warning|Don't install the ''lib32-glibc'' package now. After a ''ldconfig'', when you install ''linux'', the generated image will have libraries like ''librt.so'' in ''/usr/lib32'', where binaries during boot won't search, resulting in a boot failure.}}


=== Package installation ===
=== Package installation ===
Line 123: Line 116:
==== Install kernel (64-bit) ====
==== Install kernel (64-bit) ====


Upgrading the kernel to 64 bits (x86_64) is safe and straightforward: 32 bit and 64 bit applications run equally well under a 64-bit kernel. For migration ''away'' from 64 bits, leave the 64-bit kernel installed and running for now and skip this step.
Upgrading the kernel to 64 bits (x86_64) is safe and straightforward: 32 bit and 64 bit applications run equally well under a 64-bit kernel.


To install the standard Arch Linux kernel, use the following command:
Install the {{Pkg|linux}} package.


# pacman -S linux
==== Install lib32-glibc ====


Now is the time to install the ''lib32-glibc'' fallback (you will need to add the ''[multilib]'' repository in pacman.conf if you have not already):
Install the {{Pkg|lib32-glibc}} fallback together with the 64-bit version of {{Pkg|glibc}}. You will need to add the [[multilib]] repository in {{ic|/etc/pacman.conf}} if you have not done so already.


# pacman -S lib32-glibc
{{Warning|If you do not install the 64-bit version of glibc at the same time as lib32-glibc, the lib32-glibc install will not be able to function. However, pacman will not warn you about this, as the 32-bit glibc package also satisfies the dependency.}}


{{Note|If this fails due to an existing file of a differently named package, use pacman's {{ic|-f}} flag.}}
==== Reboot ====


Reboot and verify it is running the x86_64 architecture:
Verify that you are running the x86_64 architecture:


{{hc|$ uname -m|x86_64}}
{{hc|$ uname -m|
x86_64
}}


==== Console terminal ====
==== Switch to Console Terminal ====


This is the time to switch to a text-mode virtual console (e.g. Ctrl+Alt+F1) for the rest of the process, if possible.  Pseudo-terminals like SSH should work, but direct access is recommended as a precaution.  There will be several packages removed and replaced during the update process that may cause X11 desktops to become unstable and leave your system in an unbootable state.
Switch to a text-mode virtual console (e.g. Ctrl+Alt+F1) for the rest of the process, if possible.  If you receive an error trying to use the 1st console, use the 2nd one (Ctrl-Alt+F2) instead. Pseudo-terminals like SSH should work, but direct access is recommended as a precaution.  There will be several packages removed and replaced during the update process that may cause X11 desktops to become unstable and leave your system in an unbootable state.


==== Install Pacman ====
==== Install Pacman ====


{{Warning|Once you start updating pacman and its dependencies it can not be interruptedPacman and all of its dependencies must be installed at the same time in a single command line.}}
{{Warning|
* Once you start updating pacman and its dependencies it must not be interrupted! Pacman and all of its dependencies must be installed at the same time in a single command line.
* Immediately following this command only Busybox, Bash and pacman will be executable until the other packages are migrated below. If you are using sudo, you should obtain root previlige prior to next command}}


Use pactree to install Pacman and all its dependencies:
Install the pactree command from {{Pkg|pacman-contrib}}, then use pactree to install Pacman and all its dependencies:


  # pactree -l pacman | pacman -S -
  # pactree -l pacman | pacman -S -


Errors may be printed but they will not cause a problem as long as Pacman works. Immediately following this command only Busybox, Bash and Pacman will be executable until the other packages are migrated below.  You must not reboot your system until the following commands have been completed. You have been warned.
Errors may be printed but they will not cause a problem as long as pacman works.
 
{{Warning|You must not reboot your system until the following commands have been completed. If you failed to do so, you should continue installing by [[chroot|chrooting]] from another linux environment (e.g. from live install medium)}}


==== Install remaining packages ====
==== Install remaining packages ====
Line 159: Line 158:
  # pacman -Qqn | pacman -S -
  # pacman -Qqn | pacman -S -


If some packages didn't install correctly, you should now be able to reinstall them successfully; if you're lazy, you can just re-run the last command to reinstall everything.
If some packages did not install correctly, you should now be able to reinstall them successfully; if you are lazy, you can just re-run the last command to reinstall everything.
 
After this step the migration in either direction should be complete and it should be safe to reboot the computer.


For migration away from 64 bits, you may want to skip installing a 32-bit kernel in the commands above, since the old 64-bit kernel will still run 32-bit programs.
However, if you have any AUR packages on your system, you must reinstall all of them. A list of those can be obtained by executing:


After this step the migration in either direction should be complete and it should be safe to reboot the computer.
$ pacman -Qqm


== Cleanup ==
== Cleanup ==


You are now free to remove Busybox and ''lib32-glibc''.
You are now free to remove '''busybox''' and ''lib32-glibc''.


# pacman -Rcn busybox lib32-glibc
=== Makepkg compiler flags ===


==== Makepkg compiler flags ====
During the upgrade the new version of {{ic|/etc/makepkg.conf}} may be stored as {{ic|/etc/makepkg.conf.pacnew}}. If so, you will have to replace the old version or modify it in order to compile anything with [[makepkg]] in the future.
 
During the upgrade the new version of {{ic|/etc/makepkg.conf}} may be stored as {{ic|/etc/makepkg.conf.pacnew}}. You will have to replace the old version or modify it, if you want to compile anything with [[makepkg]] in the future.


  # mv /etc/makepkg.conf /etc/makepkg.conf.backup && mv /etc/makepkg.conf.pacnew /etc/makepkg.conf
  # mv /etc/makepkg.conf /etc/makepkg.conf.backup && mv /etc/makepkg.conf.pacnew /etc/makepkg.conf
Line 197: Line 196:
  # /lib/ld-linux.so.2 /bin/ls
  # /lib/ld-linux.so.2 /bin/ls


=== KDE doesn't start after switching from 32bit to 64bit ===
=== Migrating from old system 2017 and before ===


KDE will crash when starting after switching from 32bit to 64bit. The cause are some leftover cached files from the 32 bit KDE packages in /var/tmp To fix this remove all kdecache folders in with
You might face issue with updating old 32-bit system since in 2017 Arch Linux dropped support for i686. To make that update safe you may want use [[Arch Linux Archive]]. I.e. fix repository snapshot, then update current system and then switch to 64-bit flavor of packages corresponding to '''same version'''.
 
Note that you may need to downgrade required trust level in {{ic|pacman.conf}} (like {{ic|PackageTrustAll}} to include marginal trust) since not all GPG keys which were used to sign package are still valid. Though you may want to ensure that you use HTTPS to at least ensure that packages comes from {{ic|archlinux.org}} domain.
 
=== KDE does not start after switching from 32-bit to 64-bit ===
 
KDE will crash when starting after switching from 32-bit to 64-bit. The cause are some leftover cached files from the 32 bit KDE packages in /var/tmp To fix this remove all kdecache folders in with


  # rm -rf /var/tmp/kdecache-*
  # rm -rf /var/tmp/kdecache-*
Line 207: Line 212:
If, after completion, you find that mutt hangs on opening mail folders, try renaming the cache directory. If this works, the renamed one can be deleted as mutt will have recreated a new one.
If, after completion, you find that mutt hangs on opening mail folders, try renaming the cache directory. If this works, the renamed one can be deleted as mutt will have recreated a new one.


==See also==
== See also ==
 
*[[Migrate installation to new hardware]]
*[[Migrate installation to new hardware]]

Latest revision as of 19:57, 27 January 2023

This page documents two potential methods of migrating installed systems from i686 (32-bit) to x86_64 (64-bit) architectures. The methods avoid a complete reinstall (i.e. wiping the hard drive). One method uses a liveCD, the other modifies the system from within.

Note: Technically this process still involves "reinstalling" since every package on the system must be replaced. These methods simply attempt to preserve as much as they can from your existing system.
Warning: Unless explicitly stated, all these methods are untested and may irreparably damage your system. Continue at your own risk.

General preparation

Confirm 64-bit architecture

In order to run 64-bit software, you must have a 64-bit capable CPU. Most modern CPUs are capable of running 64-bit software. You may check your CPU with the following command:

grep --color -w lm /proc/cpuinfo

For CPUs that support x86_64, this will return the lm flag (“long mode”) highlighted. Beware that lahf_lm is a different flag and does not indicate 64-bit capability itself.

Disk space

You should be prepared for /var/cache/pacman/pkg to grow approximately twice its current size during the migration. This is assumes only packages that are currently installed are in the cache, as if “pacman -Sc” (clean) was recently run. The disk space increase is due to duplication between the i686 and x86_64 versions of each package.

If you have not enough disk, please use GParted to resize the relevant partition, or mount another partition to /var/cache/pacman.

Please do not remove packages of the old architecture from the cache until the system is fully operating in the new architecture. Removing the packages too early may leave you unable to fall back and revert changes.

Power supply

The migration may take a substantial amount of time, and it would be inconvenient to interrupt the process. You should plan on at least an hour, depending on the number and size of your installed packages and internet connection speed (although you can download everything before starting the critical part). Please make sure you are connected to a stable power source, preferably with some sort of failover or battery backup.

Fallback packages

If the migration fails halfway through, there are packages that can help sort out the situation, but they should be installed before the main packages are migrated. More details about using them under #Troubleshooting below.

One package is busybox, which can be used to revert changes. It is statically linked and does not depend on any libraries. The 32-bit (i686) version should be installed.

Another package is lib32-glibc, from the multilib x86_64 repository. It is probably only useful when migrating away from 32 bits; in any case you may safely skip this package. You can use the package to run 32 bit programs by explicitly calling /lib/ld-linux.so.2.

Method 1: using the Arch LiveCD

  1. Download and burn the latest Arch Linux ISO.
  2. Boot the Arch LiveCD in x86_64 mode.
  3. Configure your network on the LiveCD.
  4. Mount your existing installation. For example: mount /dev/sda1 /mnt.
  5. Edit the LiveCD /etc/pacman.conf repositories to match the existing /mnt/etc/pacman.conf repositories.
  6. Use the following commands to update the local pacman database and clear the cache directory.
 # pacman --root /mnt -Syy
 # pacman --root /mnt -Scc
6. You might first re-install the base group alone, then install any package that triggered an install error, identified using pacman --root /mnt -Qo <error file>. Then repeat the base group install, until it installs cleanly without errors.
 # pacman --root /mnt -S base
7. Use the following command to get a list of all your installed packages and then reinstall them.
 # pacman --root /mnt -Qnq | pacman --root /mnt -S -
8. You could run the command twice, because many packages fail to run their post-install scripts first time. This is due to sed, grep, perl, etc. being of the wrong architecture. Or you can make note of any individual package-re-install that throws an error and then go back after the upgrade completes to re-install just those packages.
Also, if you see an error about not enough disk space, you can filter the package list alphabetically and upgrade in stages, with for instance ...| grep '^[a-k]' |..., then perhaps '^l' and '^[m-z]'. In this case you would also have to run pacman --root /mnt -Scc after each install stage to free disk space. Or since all packages are downloaded in the Live CD ramfs, you can also mount a partition or make a symlink pointing to /var/cache/pacman/pkg (e.g. ln -s /mnt/var/cache/pacman/pkg /var/cache/pacman/pkg).
9. Finally, run
 # arch-chroot /mnt 
 # mkinitcpio -p linux
10. Also, see if your boot loader needs to be migrated. For instance:
 # grub-install --recheck /dev/sda
11. After rebooting to your new 64-bit system, edit and then move /etc/makepkg.conf.pacnew to /etc/makepkg.conf, to migrate the CPU architecture. Then rebuild the "foreign" packages, which will include packages from the AUR.
You might first want to remove certain orphaned foreign packages before trying to rebuild them. Run this command to find out what 32-bit binaries you still have and reinstall them:
 $ LC_ALL=C pacman -Qo `find /usr/bin -type f -exec bash -c 'file "{}" | grep 32-bit' \; | cut -d':' -f1` | cut -d' ' -f5 | sort | uniq | tee list

Method 2: from a running system

Ensure that your system is fully updated and functioning before proceeding.

# pacman -Syu

Package preparation

Cache old packages

Note: If you have any packages installed from the AUR or third-party repositories without new architecture availability, pacman will let you know it cannot find a suitable replacement. Make a list of these packages so you may re-install them after the update process and then remove them using pacman -Rsn package_name.

If you do not have all your installed packages in your cache, download them (for the old architecture) for fallback purposes.

# pacman -Qqn | pacman -Sw -

or use fakepkgAUR package to generate them.

Install busybox

If you are migrating from 32 bits to 64 bits, now is the time to install 32-bit busybox. Install busybox package.

Change Pacman architecture

Edit the /etc/pacman.conf file and change Architecture from auto to x86_64.

Make sure the server lists in /etc/pacman.conf and /etc/pacman.d/mirrorlist use $arch instead of explicitly specifying i686 or x86_64. Now force Pacman to synchronize with the new repositories:

# pacman -Syy                     # force sync new architecture repositories

Download new packages

Download the new architecture versions of all our currently installed packages:

# pacman -Sw $(pacman -Qqn|sed '/^lib32-/ d')  # download new package versions

If migrating to 32 bits, install the 32-bit busybox fallback now that Pacman has been configured with the 32-bit architecture.

Warning: Do not install the lib32-glibc package now. After a ldconfig, when you install linux, the generated image will have libraries like librt.so in '/usr/lib32, where binaries during boot will not search, resulting in a boot failure.

Package installation

Install kernel (64-bit)

Upgrading the kernel to 64 bits (x86_64) is safe and straightforward: 32 bit and 64 bit applications run equally well under a 64-bit kernel.

Install the linux package.

Install lib32-glibc

Install the lib32-glibc fallback together with the 64-bit version of glibc. You will need to add the multilib repository in /etc/pacman.conf if you have not done so already.

Warning: If you do not install the 64-bit version of glibc at the same time as lib32-glibc, the lib32-glibc install will not be able to function. However, pacman will not warn you about this, as the 32-bit glibc package also satisfies the dependency.

Reboot

Verify that you are running the x86_64 architecture:

$ uname -m
x86_64

Switch to Console Terminal

Switch to a text-mode virtual console (e.g. Ctrl+Alt+F1) for the rest of the process, if possible. If you receive an error trying to use the 1st console, use the 2nd one (Ctrl-Alt+F2) instead. Pseudo-terminals like SSH should work, but direct access is recommended as a precaution. There will be several packages removed and replaced during the update process that may cause X11 desktops to become unstable and leave your system in an unbootable state.

Install Pacman

Warning:
  • Once you start updating pacman and its dependencies it must not be interrupted! Pacman and all of its dependencies must be installed at the same time in a single command line.
  • Immediately following this command only Busybox, Bash and pacman will be executable until the other packages are migrated below. If you are using sudo, you should obtain root previlige prior to next command

Install the pactree command from pacman-contrib, then use pactree to install Pacman and all its dependencies:

# pactree -l pacman | pacman -S -

Errors may be printed but they will not cause a problem as long as pacman works.

Warning: You must not reboot your system until the following commands have been completed. If you failed to do so, you should continue installing by chrooting from another linux environment (e.g. from live install medium)

Install remaining packages

Install all of the previously downloaded replacements for the new architecture. (Go get a drink and make a sandwich; this could take a while.)

# pacman -Qqn | pacman -S -

If some packages did not install correctly, you should now be able to reinstall them successfully; if you are lazy, you can just re-run the last command to reinstall everything.

After this step the migration in either direction should be complete and it should be safe to reboot the computer.

However, if you have any AUR packages on your system, you must reinstall all of them. A list of those can be obtained by executing:

$ pacman -Qqm

Cleanup

You are now free to remove busybox and lib32-glibc.

Makepkg compiler flags

During the upgrade the new version of /etc/makepkg.conf may be stored as /etc/makepkg.conf.pacnew. If so, you will have to replace the old version or modify it in order to compile anything with makepkg in the future.

# mv /etc/makepkg.conf /etc/makepkg.conf.backup && mv /etc/makepkg.conf.pacnew /etc/makepkg.conf

It might also be a good idea to just get a list of "new" additions to /etc. You can get a list with the following command:

# find /etc/ -type f -name \*.pac\*

Troubleshooting

During the upgrade, when glibc is replaced by the new architecture version, old architecture versions of many programs will not run. If problems occur, you can solve them with busybox and lib32-glibc.

Busybox

In Arch, Busybox is statically linked; it can run without any libraries. There are many commands available to you. For example, to extract an i686 version of Pacman from a cached package:

# busybox tar xf /var/cache/pacman/pkg/pacman-3.3.2-1-i686.pkg.tar.gz -C <some folder>

Lib32-glibc

Example run 32 bit /bin/ls:

# /lib/ld-linux.so.2 /bin/ls

Migrating from old system 2017 and before

You might face issue with updating old 32-bit system since in 2017 Arch Linux dropped support for i686. To make that update safe you may want use Arch Linux Archive. I.e. fix repository snapshot, then update current system and then switch to 64-bit flavor of packages corresponding to same version.

Note that you may need to downgrade required trust level in pacman.conf (like PackageTrustAll to include marginal trust) since not all GPG keys which were used to sign package are still valid. Though you may want to ensure that you use HTTPS to at least ensure that packages comes from archlinux.org domain.

KDE does not start after switching from 32-bit to 64-bit

KDE will crash when starting after switching from 32-bit to 64-bit. The cause are some leftover cached files from the 32 bit KDE packages in /var/tmp To fix this remove all kdecache folders in with

# rm -rf /var/tmp/kdecache-*

Mutt issues with cache enabled

If, after completion, you find that mutt hangs on opening mail folders, try renaming the cache directory. If this works, the renamed one can be deleted as mutt will have recreated a new one.

See also