Talk:Migrating between architectures
LiveCD method doesn't work
The LiveCD migration method from i686 -> x86_64 doesn't work, the instructions are incomplete. It took me half a day to get my system working again.
Here are the issues I ran into:
- There's not enough space on the livecd ramdisk to do a full system update if there are large installed packages (e.g. eclipse, ghc etc). I had to delete the pacman cache from time to time to prevent the disk from filling up.
- After system update, the init ramdisk has to be regenerated with mkinitcpio otherwise the updated system won't boot with the new kernel. To run mkinitcpio, you have to first chroot (look up chroot on arch wiki).
- The script from the article uses pacman -Qqet to discover the installed packages, however this won't list libraries. To do a full update I had to change that to pacman -Qq.
- The update script doesn't update dependencies in the correct order, so it has to be run twice. This seems to be the same issue as Dooglus describes below.
- /etc/makepkg.conf has to be updated to match the new architecture.
- It would be a good idea to save the output of the script into a log file, that was helpful for me to find packages that were not upgraded (some from AUR and others with lib32 dependency problems). Make sure to pipe stderr also, for example:
migrate 2>&1 | tee migrate.log
I'm not sure what the policies are for updating the wiki page and I probably wouldn't be able to describe all the steps that were necessary to get my system up and running again, but I hope the points above will help others who run into the same issues.
Couldn't install lib32-glibc
The article says "Alternatively, if migrating to 64 bits, now is the time to install the lib32-glibc fallback". But when I tried to install lib32-glibc I got errors about conflicting files. I didn't keep a record of the exact error message, but glibc and lib32-glibc both have these 2 files in them, so I guess that was the cause of the error:
See https://www.archlinux.org/packages/core/i686/glibc/files/ and https://www.archlinux.org/packages/multilib/x86_64/lib32-glibc/files/ for the file lists - the article suggests installing lib32-glibc before upgrading glibc. --Dooglus 20:40, 9 November 2011 (EST)
- if the following lines are in your
/etc/pacman.confyou can install lib32-glibc:
[multilib] Include = /etc/pacman.d/mirrorlist
- if you have problems with existing file use the -f (force) flag
- after the migration every thing has changed, (deps, files..) - so it doesn't matter any way
Errors Upgrading pacman, etc.
I followed the instructions for method two (installing from a running system) to upgrade from 32 bit to 64 bit. It went well until it came to reinstalling pacman and friends, then I saw a bunch of errors:
[root@chris chris]# pacman -S pacman glibc libfetch libarchive openssl acl attr \ xz-utils bzip2 zlib readline bash ncurses expat warning: pacman-3.5.4-4 is up to date -- reinstalling warning: glibc-2.14.1-1 is up to date -- reinstalling warning: libfetch-2.33-3 is up to date -- reinstalling warning: libarchive-2.8.5-2 is up to date -- reinstalling warning: openssl-1.0.0.e-1 is up to date -- reinstalling warning: acl-2.2.51-1 is up to date -- reinstalling warning: attr-2.4.46-1 is up to date -- reinstalling warning: xz-5.0.3-1 is up to date -- reinstalling warning: bzip2-1.0.6-3 is up to date -- reinstalling warning: zlib-1.2.5-4 is up to date -- reinstalling warning: readline-6.2.001-3 is up to date -- reinstalling warning: bash-4.2.010-2 is up to date -- reinstalling warning: ncurses-5.9-2 is up to date -- reinstalling warning: expat-2.0.1-7 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... Targets (14): glibc-2.14.1-1 ncurses-5.9-2 readline-6.2.001-3 bash-4.2.010-2 \ zlib-1.2.5-4 bzip2-1.0.6-3 xz-5.0.3-1 attr-2.4.46-1 acl-2.2.51-1 \ openssl-1.0.0.e-1 expat-2.0.1-7 libarchive-2.8.5-2 libfetch-2.33-3 \ pacman-3.5.4-4 Total Download Size: 0.00 MB Total Installed Size: 67.17 MB Proceed with installation? [Y/n] y call to execv failed (No such file or directory) error: command failed to execute correctly call to execv failed (No such file or directory) error: command failed to execute correctly error: command failed to execute correctly warning: /etc/pacman.conf installed as /etc/pacman.conf.pacnew [root@chris chris]#
I don't know if they are 'expected' errors, or if they're a problem. I carried on with the
# pacman -S $(pacman -Qq)
command, which also produced some errors. I won't paste the whole output, since it is rather large, but some of the more serious looking errors were:
Proceed with installation? [Y/n] y /tmp/alpm_nhTnAm/.INSTALL: line 6: sbin/init: No such file or directory usr/sbin/locale-gen: line 16: /bin/rm: No such file or directory Generating locales... usr/sbin/locale-gen: line 33: /bin/sed: No such file or directory .UTF-8usr/sbin/locale-gen: line 35: /bin/sed: No such file or directory ...usr/sbin/locale-gen: line 38: /bin/sed: No such file or directory error: command failed to execute correctly error: command failed to execute correctly error: command failed to execute correctly error: command failed to execute correctly error: command failed to execute correctly error: command failed to execute correctly error: command failed to execute correctly error: command failed to execute correctly /tmp/alpm_pnGmoW/.INSTALL: line 16: bin/grep: No such file or directory groupadd: group 'optical' already exists
After that I ran both commands again, in the same order, and this time they both completed without errors, and my system appears to be fine as far as I can tell.
I don't know if the errors produced the first time through needed fixing, or if my solution (re-running both commands) is a good solution, but maybe someone who knows could update the article accordingly, either saying not to worry about the errors, or saying what how to fix them. --Dooglus 20:18, 9 November 2011 (EST)
pactree -l pacman | pacman -S -
had some errors for glibc and other packages like
error: command failed to execute correctly
After installing the new pacman, I installed the packages:
gettext texinfo gzip - used but glibc to generate locales
And reinstalled pacman, this time it worked fine. (I also installed some packages like grep, sudo, and such)
"Install Remaining Packages"
Just went through this installation, thought I'd note that I had to the alternative step in "Download new packages" (using comm to remove AUR packages). When I did the install remaining package step, you need to include that to edit the pacman -Qq output as well or it won't run. I'm new to wiki editing so don't know if I should just go and do that myself, but I thought I'd point that out for anybody freakin out. —This unsigned comment is by Jemofthewest (talk) 19:28, 1 August 2012. Please sign your posts with ~~~~!
- Hi Jemofthewest, if you have just gone through this process then I’d encourage you to update the page as best you can. You’re probably a lot more familiar with the process than me (and probably most other people reading this). Vadmium (talk) 12:38, 19 August 2012 (UTC).
I've had some troubles with this step. To install the lib32-glibc fallback, I had to add the multilib repo. With this I've had new packages that were not downloaded and after rebooting, I no longer had network. I could solve by re-installing some packages that allowed me to use dhclient, wget and such, but I think it's a good idea to put a note to re-run the download command after adding the multilib repo. And make sure you have connection before commencing the update. Renatolond (talk) 15:54, 21 January 2015 (UTC)
Install from running system works
Just wanted to say that as of July, 21th, 2014, following the guide works ok for i686 -> x86_64. Thanks. —This unsigned comment is by Cgo (talk) 14:32, 21 July 2014. Please sign your posts with ~~~~!
- worked here also perfectly at my ThinkPad x200 with 4gb ram :3 --Therojam (talk) 15:23, 24 May 2015 (UTC)
Worked for me too! Had to generate locale manually afterwords (sudo locale-gen). At one point X (nvidia) didn't start but after the last full reinstall command it did. Going to console mode was key here. (ctrl+alt+F2) -- swanson, 8 march 2016
Install from running system doesn't work
Af of September, 6th, 2017 the method No 2 doesn't work for me. On reinstalling pacman stem I stumbled upon dependency break (not remember what package exactly) so I was forced to pactree -l|pacman -Sdd and after reinstalling all packages I'm not able to boot due to udisks-part-id process being terminated by signal SYS [EDIT:] Either reinstalling systemd or generating locale helped. --Speranskiy (talk) 06:56, 6 September 2017 (UTC)