i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

TheGrudge · 2009-02-21 22:16:30

Unrelated...? Why? Anyway I compiled my kernel now and it is faster, I can see it with Firefox. But I only changed the processor type, it is still 32bit...

fukawi2 · 2009-02-22 21:58:17

Back on track..

Changaco wrote:

What about getting the list of files that don't belong to a package in order to backup ?
Or do the opposite, delete all those files and then install x86_64 packages ?

Anyone got any suggestions or thoughts about this idea...?

Changaco · 2009-02-28 12:53:52

fukawi2 wrote:

Back on track..
Changaco wrote:
What about getting the list of files that don't belong to a package in order to backup ?
Or do the opposite, delete all those files and then install x86_64 packages ?
Anyone got any suggestions or thoughts about this idea...?

So I began testing this first idea, I successfully got the list of files not owned by a package in bash using pacman, find, diff and some others. I realized that most configuration files are in the list of files owned by a package so packages which do have configuration files in /usr won't be detected.
On the other hand it is a good way to find files that you lost on your system or programs that you didn't install through libalpm.

brisbin33 · 2009-04-01 19:52:16

Just an update as i've learned a few things since that first post.

1) backup /usr because some config files are there
2) [edit] nothing to see here... [/edit]
3) restore /home *before* doing step 4
4) use this script to split out the pacman vs AUR packages before restoring them:

#!/bin/bash
#
# Parse our paclist for pacman vs aur packages; this should
# split the list into packages that pacman can install and
# packages that are from the AUR.  those from the AUR /should/
# be saved and can be -U'd from there

dir=/path/to/backup/files

mkdir $dir/.safe
touch $dir/.safe/pacman
touch $dir/.safe/aurlist

cat $dir/paclog* | while read pack; do
  pacman -Ss $pack >/dev/null
  case $? in
    0)
    echo $pack >> $dir/.safe/pacman
    ;;
    *)
    echo $pack >> $dir/.safe/aurlist
    ;;
  esac
done

# Install the pacman packages first
cat $dir/.safe/pacman | xargs pacman -S --noconfirm --needed || exit 1

# Install the aur packages
cat $dir/.safe/aurlist | while read aur; do
  pacman -U /path/to/aur/packages/$aur*
done

5) restore /etc and /usr *after* doing step 3

taking your time and follow the OP + the above, there's no reason you shouldn't be able to upgrade w/o any loss in data / setup

EDIT, sorry. i backup /var now because i've scripted out this process to use as a nightly backup with a restore script waiting. totally forgot you'd be installing 32 bit executables in this case... that could be a problem. thanks for the corrections below

Last edited by brisbin33 (2009-04-02 13:39:13)

fukawi2 · 2009-04-01 22:27:17

brisbin33 wrote:

2) backup /var because it'll make your pacman restore go ALOT quicker if you've saved the packages

Uhhhhh..............

ngoonee · 2009-04-02 00:11:30

fukawi2 wrote:

brisbin33 wrote:
2) backup /var because it'll make your pacman restore go ALOT quicker if you've saved the packages
Uhhhhh..............

I don't think backing /var up is gonna work. Those are all 32-bit binaries anyway....

Unless this is just a *GOOD IDEA*

moljac024 · 2009-04-02 00:24:54

fukawi2 wrote:

brisbin33 wrote:
2) backup /var because it'll make your pacman restore go ALOT quicker if you've saved the packages
Uhhhhh..............

lol

brisbin33 · 2009-04-02 13:35:47

ngoonee wrote:

fukawi2 wrote:
brisbin33 wrote:
2) backup /var because it'll make your pacman restore go ALOT quicker if you've saved the packages
Uhhhhh..............
I don't think backing /var up is gonna work. Those are all 32-bit binaries anyway....
Unless this is just a *GOOD IDEA*

haha oh shit. i realized i made my 32>64 conversion script into a backup>restore script in which backing up /var would be a good idae. oh well... editing post...

Last edited by brisbin33 (2009-04-02 13:36:05)

ava1ar · 2010-03-16 16:15:39

Guys,

looks like I found a smooth way to perform conversion i686 to x86_64 system. I successfully tested it on virtual machine on my laptop (with more than 700 packages installed). Please find steps I did below:

1. Steps on i686 system before upgrade:
a) Update you system to up-to-date state;
b) If you are using custom kernel (not kernel26 from Arch repo) it is recommended to switch to kernel26 for migration process (you may revert back to your custom kernel after migration done);
c) Remove i686 only packages (like skype, virtualbox-ose, etc) and custom packages (like ones from AUR). You may skip this, but later you will need extra effors than;
d) Remove i686 only repositories from pacman.conf of any;
e) Clear package cache and unused repositories data using

pacman -Scc

command;
f) Switch you repositories from i686 to x86_64 packages (/etc/pacman.d/mirrorlist, custom repositories from pacman.conf, etc). For modifying mirrorlist yo may use following commands:

# mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.i686
# sed -e 's/i686/x86_64/' /etc/pacman.d/mirrorlist.i686 > /etc/pacman.d/mirrorlist

I also had to update kdemodmirrorlist as well (this is repositories from kdemod project).
g) Perform full resync of package databeses using

# pacman -Syy

command.

2. OK, now you system is ready. Next steps will be executed using Arch live cd (or live usb) system:
a) Boot from cd or usb with live Arch Linux system (I used usb stick with release 2009.08) and login as root
b) Create folder in /media and mount root (/) of you system there:

# mkdir /media/i686
# mount /dev/sdaX /media/i686

(!) c) Perform upgrade of all installed packages on you main with --noscriptlet option (please be very accurate with pacman options here):

 # pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet -S `pacman --root /media/i686 -Qq`

Wait till installation finished.

If you receive messages like

<package_name> package not found, searching for group...
error: '<package_name>': not found in sync db

you should either remove <package_name> using command

# pacman --root /media/i686 -Rd <package_name>

either ignore this package during upgrade. To do this just modify

`pacman --root /media/i686 -Qq`

part of the above command as

 `pacman --root /media/i686 -Qq | grep -v <package_name>`

You can have any number of ignored packages by adding new grep -v statements to the command end;

3. Now you binaries are updated and we need to do configuration of installed packages.
a) Mount virtual filesystems

# mount --bind /proc /media/i686/proc
# mount --bind /sys /media/i686/sys
# mount --bind /dev /media/i686/dev
# mount --bind /dev/pts /media/i686/dev/pts
# mount --bind /dev/shm /media/i686/dev/shm

b) Perfrom chroot to host root:

# chroot /media/i686

(!) c) Mount /boot partition (if it is on separate partition on you system - look at /etc/fstab):

# mount /boot

d) Perform upgrade of all packages (yeah, again ):

# pacman -S `pacman -Qq`

You will also need to ignore custom packages like in step 2c

4. OK, our system is ready now, rebooting to the main system:
a) Unmount /boot partition

# umount /boot

b) Exit from chroot:

# exit

c) Unmount virtual filesystems:

# umount /media/i686/proc
# umount /media/i686/sys
# umount /media/i686/dev
# umount /media/i686/dev/pts
# umount /media/i686/dev/shm

d) Unmount main system root partition:

# umount /media/i686

e) Reboot

5. Profit!

This perfectly works for my test and live systems, but if you have some issues/comments, please let me know - I will try to help. In any case, I think this will be usefull as a proof of high flexibility of Arch Linux and pacman.

Last edited by ava1ar (2010-03-16 21:20:22)

lecyborg · 2010-03-21 02:36:52

ava1ar wrote:

5. Profit!
This perfectly works for my test and live systems, but if you have some issues/comments, please let me know - I will try to help. In any case, I think this will be usefull as a proof of high flexibility of Arch Linux and pacman.

Same for me thank you ! It worked flawlessly.

brisbin33 · 2010-03-21 03:07:04

Nicely done.

I have just one suggestion: when doing the grep -v <packagename> part, it's probably best to use grep -Fvx (if you /want/ regexs, remove the -F).

-x makes it match wholeline so grep -v xorg doesn't block xorg-server too (as a completely unrealistic but illustrative example)

Gen2ly · 2010-03-21 03:47:06

Here's how I do it (which is quite a bit like yours) a bit more basic though:

[wiki]System_Restore_from_Configurations[/wiki]

Basically what it does it that it has a couple tar helpers that write to add files, directories... to a tar include file and a tar exclude file. After configuration backup, the next section details how to create package lists: Official and Local (by of which you helped me out with, TY for that ).

Restoring involves doing a regular Arch ISO-FTP install, chrooting, adding all the previous packages from the package lists (AUR packages can take some time ), extracting configurations. Bam!

Maybe I should have told people I put this up , but clever way you did it too.

BTW, cron files exist in /var/spool/cron/.

Last edited by Gen2ly (2010-03-21 03:49:35)

ava1ar · 2010-03-21 12:25:25

brisbin33 wrote:

I have just one suggestion: when doing the grep -v <packagename> part, it's probably best to use grep -Fvx (if you /want/ regexs, remove the -F).
-x makes it match wholeline so grep -v xorg doesn't block xorg-server too (as a completely unrealistic but illustrative example)

Yes, this defenitely makes sence. Thanks for update!

ava1ar · 2010-03-21 12:27:39

Gen2ly,
do you think information I posted worth to be published to Arch Wiki? If yes, I will update it to the required form and will post it. Thanks!

Gen2ly · 2010-03-28 03:30:50

ava1ar wrote:

Gen2ly,
do you think information I posted worth to be published to Arch Wiki? If yes, I will update it to the required form and will post it. Thanks!

Sorry for the long reply ava1ar, computer crashed . Got one now, but something's funky, I'll get back tomorrow and look.

Last edited by Gen2ly (2010-03-28 03:31:53)

ava1ar · 2010-03-28 07:17:41

Gen2ly wrote:

Sorry for the long reply ava1ar, computer crashed . Got one now, but something's funky, I'll get back tomorrow and look.

Its OK, thank you, Gen2ly!

Gen2ly · 2010-03-28 18:53:09

Looks good ava1ar. Nice work. However, I believe the methods to be of completely different. Before I've noticed this article:

[wiki]Migrating_Between_Architectures_Without_Reinstalling[/wiki]

That may be an article that your method can be integrated with. If not, if you think your method is:

1) More straight forward
2) Provides better details

Write a new article. This gets done from time to time on the wiki where details from several differing methods get merged. Possibly it's time for an update.

ava1ar · 2010-03-28 19:13:53

Thanks, Gently for information. I will review article about migrating in details and I think if it possible i will propose merging my actions to this one.
BTW, while looking for something like this article (before I did migration) i haven't found this article. May be it is a good idea to make a link to it in Arch64 FAQ page, to the section "12 Can I upgrade/switch my system from i686 to x86_64 without reinstalling?"

Gen2ly · 2010-03-29 03:59:04

ava1ar wrote:

Thanks, Gently for information. I will review article about migrating in details and I think if it possible i will propose merging my actions to this one.
BTW, while looking for something like this article (before I did migration) i haven't found this article. May be it is a good idea to make a link to it in Arch64 FAQ page, to the section "12 Can I upgrade/switch my system from i686 to x86_64 without reinstalling?"

Yeah absolutely. Definitely a good idea.

stefano.facchini · 2010-12-05 09:19:53

Hi,
I tried to upgrade my arch system to 64bit with the method described in post #34. Apparently it worked quite well (I only got some complaining about conflicting libusb packages).

The next step was building the xf68-video-ati driver (which worked flawlessly). Then, I would like to build the mesa driver, and here I get stuck. I give the usual commands:

$ ./autogen.sh --prefix=/opt/xorg --with-dri-drivers="r600,swrast" --enable-gallium-r600
$ make

but after a while I obtain:

mklib: Making Linux shared library: r300_dri.so.tmp
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_code.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_compiler.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_compiler_util.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_program.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_program_print.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_opcodes.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_dataflow.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r3xx_vertprog_dump.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(memory_pool.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_emulate_branches.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_emulate_loops.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_program_alu.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_program_pair.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_dataflow_deadcode.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_optimize.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_remove_constants.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r3xx_fragprog.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r300_fragprog.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r300_fragprog_swizzle.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r300_fragprog_emit.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r500_fragprog.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(r500_fragprog_emit.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_program_tex.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_pair_translate.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_pair_schedule.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_pair_regalloc.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_dataflow_swizzles.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `../../../../src/gallium/drivers/r300/libr300.a(radeon_rename_regs.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
/usr/bin/ld: BFD (GNU Binutils) 2.20.1.20100521 assertion fail ../../bfd/elf64-x86-64.c:3908
collect2: ld returned 1 exit status
g++ -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m64 -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -o r300_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r300_dri.so.tmp -ldrm -lexpat -lm -lpthread -ldl -ltalloc -ldrm_radeon -lstdc++;
g++: r300_dri.so.tmp: No such file or directory
make[3]: *** [r300_dri.so] Error 1
make[3]: Leaving directory `/home/stefano/xorg-src/mesa/src/gallium/targets/dri-r300'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/stefano/xorg-src/mesa/src/gallium/targets'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/stefano/xorg-src/mesa/src'
make: *** [default] Error 1

Have I forgot some configuration step for the compiler or the linker? I also tried

$ ./autogen.sh --prefix=/opt/xorg --with-dri-drivers="r600,swrast" --enable-gallium-r600 --enable-64-bit

with the same result!

Any idea? thank you!

Ramses de Norre · 2010-12-05 11:31:14

ava1ar wrote:

(!) c) Perform upgrade of all installed packages on you main with --noscriptlet option (please be very accurate with pacman options here):
 # pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet -S `pacman --root /media/i686 -Qq`
Wait till installation finished.

Aren't you installing every package explicitly now? Thereby losing the ability to have dependencies removed when removing a package? Or am I missing something?

Last edited by Ramses de Norre (2010-12-05 11:31:39)

brisbin33 · 2010-12-05 15:51:11

Ramses de Norre wrote:

ava1ar wrote:
(!) c) Perform upgrade of all installed packages on you main with --noscriptlet option (please be very accurate with pacman options here):
 # pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet -S `pacman --root /media/i686 -Qq`
Wait till installation finished.
Aren't you installing every package explicitly now? Thereby losing the ability to have dependencies removed when removing a package? Or am I missing something?

I'd say yes (I didn't write those steps). Maybe if you used instead -Qqe and let pacman bring in his own deps, it would be better.

ava1ar · 2010-12-05 15:55:26

Ramses de Norre wrote:

Aren't you installing every package explicitly now? Thereby losing the ability to have dependencies removed when removing a package? Or am I missing something?

Good point actually. Currently when you are reinstalling already installed packages "Install Reason" parameter for this package remains the same. If you want to be sure you can install this two categories separately, using following commands:

pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet --asexplicit -S `pacman --root /media/i686 -Qeq`

and

pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet --asdeps -S `pacman --root /media/i686 -Qdq`

brisbin33 · 2010-12-05 16:00:35

ava1ar wrote:

Ramses de Norre wrote:
Aren't you installing every package explicitly now? Thereby losing the ability to have dependencies removed when removing a package? Or am I missing something?
Good point actually. Currently when you are reinstalling already installed packages "Install Reason" parameter for this package remains the same. If you want to be sure you can install this two categories separately, using following commands:
pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet --asexplicit -S `pacman --root /media/i686 -Qeq`
and
pacman --root /media/i686 --cache /media/i686/var/cache/pacman/pkg --noscriptlet --asdeps -S `pacman --root /media/i686 -Qdq`

(See post above)

When you run that first line (--asexplicit not required) pacman will bring in all the deps correctly. No second line needed.

ava1ar · 2010-12-05 16:02:48

stefano.facchini wrote:

Any idea? thank you!

Have you updated /etc/makepkg.conf after migration to 64-bit? CARCH and CHOST should have following values:

CARCH="x86_64"
CHOST="x86_64-unknown-linux-gnu"

You can fix this manually or just remove this file and reinstall pacman package.

Hope this helps.

Arch Linux

#26 2009-02-21 22:16:30

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#27 2009-02-22 21:58:17

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#28 2009-02-28 12:53:52

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#29 2009-04-01 19:52:16

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#30 2009-04-01 22:27:17

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#31 2009-04-02 00:11:30

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#32 2009-04-02 00:24:54

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#33 2009-04-02 13:35:47

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#34 2010-03-16 16:15:39

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#35 2010-03-21 02:36:52

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#36 2010-03-21 03:07:04

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#37 2010-03-21 03:47:06

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#38 2010-03-21 12:25:25

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#39 2010-03-21 12:27:39

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#40 2010-03-28 03:30:50

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#41 2010-03-28 07:17:41

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#42 2010-03-28 18:53:09

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#43 2010-03-28 19:13:53

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#44 2010-03-29 03:59:04

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#45 2010-12-05 09:19:53

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#46 2010-12-05 11:31:14

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#47 2010-12-05 15:51:11

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#48 2010-12-05 15:55:26

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#49 2010-12-05 16:00:35

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

#50 2010-12-05 16:02:48

Re: i686 --> x86_64 upgrade - steps i took to keep packages/settings/data

Board footer