We have an Ubuntu server vmware-instance which appears to be installed with the 64-bit version.
Unfortunately we now want to move it to a 32-bit only host, so the current installation will not run. The installation is rather tweaked, so I'd really, really prefer to have the current installation converted instead of doing a fresh installation.
Is there a reliable way to get 32-bit versions of everything and convert the kernel, or should I completely drop the idea?
Thanks for all help.
EDIT: The primary purpose of this Linux instance was to provide a CVS repository. After careful consideration we decided to migrate from CVS to git instead of doing the 64->32 bit exercise.
I suspect that there is no easy, stable, reliable, automated way, as it isn't something that is going to be needed often enough for it to be worth spending a lot of time developing and testing, and doing it manually would probably take longer than simply rebuilding the VM's install from scratch.
You can speed up the rebuild to a certain extent though, you can make sure you have all the same packages installed by running
on the old VM, transferring the file over and running
on the new VM.
Then copy the old VM's
/etc/
tree over to the new machine (not as/etc
- drop it somewhere temporary) and use adiff
tool to locate differences you need to transfer over. The reason not to just bulk copy/etc
into place is that there may be slight differences in the default config for some 64bit/32bit packages that you might want to at least look into rather than blitzing without knowing. For a start/etc/apt/sources.lst
will need to differ. (Even if doing this to duplicate a 32 bit install to another 32 bit install I'd still not just copy/etc
wholesale - doing a diff like this gives you the change of finding things that are no longer relevant and should have been purged for clarity)Once that is done copy over /home to regain any user specific config & data, and anything like
/var/www
if you have files served by HTTP from there, and so on, and you are pretty much done.I used the above to replicate one 32bit install as another 32bit install, but it should work just as well between architectures. You might find some packages cause the
apt-get
command to warn you about not finding the package. Some of these will be 32-bit compat packages that won't be present in the 32-bit repo obviously (just remove them from the package list and rerun) and some might be packages that have explicitly named 32 bit and 64 bit packages (in which case find the right name using the search on packages.ubuntu.com, edit the package list, and rerun apt-get).Of course this will not replicate anything you did not install from the Ubuntu repositories, so you'll have to redo anything like that manually, but otherwise this process may save you a little time. Also, before running apt-get, make sure the new VMs sources.list has the same repositories enabled as the old one, or you'll get a lot more package-not-found issues from
apt-get
.I know that it is not only the kernel that is 64-bit in Ubuntu.
Not having done this migration before, I can't say for certain, but I feel this plan might be best. Try changing the kernel to 32-bit on a copy of the instance, and see if that works. Then try to copy it over to the other machine. If that does not work, reinstall Ubuntu and copy the config files over in small batches to see if anything breaks.
If the first way doesn't work, the second is horribly convoluted and time consuming, but may be able to save your tweaks.
The best option is to perform a reinstall. As an example, take a look at the details of the binutils package on my Ubuntu 64-bit server:
The "Architecture: amd64" line indicates the package was compiled as a 64-bit binary, and that it would need to be replaced with the 32-bit version before booting to a 32-bit kernel. There will be large issues when you replace the core libc6 libraries, as so many packages depend on those libraries being in place.