Is there a way to upgrade my 32-bit version of Ubuntu to 64-bit version? I use Ubuntu 9.10.
If there is no simple way, what if I simply copy my home and
/etc directories to new installation, will it work?
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
Unfortunately, like other OS's, there is no 'upgrade path' to do this. You'll almost certainly need to do a reinstall.
As for preserving your data, backing up your home directory would be a good idea along with any other data and should be easily imported into your new installation.
Always backup your data before attempting anything!
I wouldn't just copy
/etc over in case of slight differences between the configuration requirements for 64-bit compiles of packages, but taking a copy and then
diffing the copy against the newly installed 64-but system would work. Chances are the number of changes isn't massive so doing this and making the required changes manually will hopefully be no great hardship.
/etc over as you suggest should work OK though - I would just do it the longer way around for the sake of paranoia. Copying
/home, the main area of concern when migrating from one install to another, is more likely to be completely safe.
If you are just looking to move to 64-bit to make use of more RAM rather than because you specifically need to use 64-bit applications then you can just use a 64-bit kernel with a 32-bit userspace. Debian actually provide a64 kernel packages in their i386 repositories, so it can be done as simply as
aptitude install linux-image-2.6-amd64, but Ubuntu unfortunately don't so you'd have to compile up your own kernel which might not be worth the time+hassle if you are no that technically experienced (i.e. this is simple, but only if you have compiled your own kernel before so are comfortable with the process). If you do run a 64-bit kernel with a 32-bit userland an individual app can still only access ~3Gb at most (in some cases just ~2Gb), but the system as a whole (all processes together plus the kernel's stuff like IO cache and buffers) can use as much as you have. Each VMWare VM counts as a single app for these purposes - I run one of my older VM hosts this way (the VMs use ~7Gb in total with 64-bit kernel, 32-bit userland and 32-bit VMWare) as it was quicker than a full 64-bit host OS upgrade when I upgraded the machines CPU to a 64-bit capable one and added the extra RAM - I would guess that similar VM solutions would act the same way too.
Running a 32-bit userland on a 64-bit kernel is likely to cause problems as soon as system facilities get involved. For example, using the 32bit libalsa on a 64bit kernel will almost work but be quite unreliable and unstable because the ioctl data structures defined in asound.h have different sizes and arrangements when compiled with 64bit and 32bit architectures.
So using jackd -d alsa -X alsaraw (or its jackd2 equivalent) will abort with a failed assertion when calling a 32bit utility on a 64bit kernel. Standard audio operation will be a lot less reliable since buffer counts get interpreted wrong.
In general, any kernel data structures have to be declared in a way where their sizes don't differ between 32- and 64bit kernels, or the 32bit code has to be smart about using different structure definitions in correspondence with the kernel architecture.
So all in all, you are likely better off reinstalling from scratch and transferring your home partition/directory.