1

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.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
Thorbjørn Ravn Andersen
  • 1,354
  • 8
  • 14
  • 1
    If you do not have a documented process on how to set up that server from scratch already in case of a disaster - now would be a very good idea to produce one ^^ – Oskar Duveborn Jan 14 '10 at 14:00
  • Is it the host OS that's 32-bit or the host hardware? Because if it's the former *and* not the latter, it's supported: http://www.vmware.com/products/server/faqs.html – Dennis Williamson Jan 14 '10 at 14:05
  • Oskar, I perfectly well know how to do that. I just rather avoid it if at all possible. You install Windows all the time? – Thorbjørn Ravn Andersen Jan 14 '10 at 14:10

3 Answers3

5

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

sudo dpkg --get-selections | grep '[[:space:]]install$' | \awk '{print $1}' > package_list

on the old VM, transferring the file over and running 

cat package_list | xargs sudo apt-get install

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 a diff 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.

David Spillett
  • 22,754
  • 45
  • 67
0

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.

Joshua Nurczyk
  • 748
  • 6
  • 17
0

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:

smiller@corinne3:~$ dpkg-query -p binutils
Package: binutils
Priority: optional
Section: devel
Installed-Size: 10092
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Version: 2.20-0ubuntu2
Provides: elf-binutils
Depends: libc6 (>= 2.8), zlib1g (>= 1:1.1.4)
Suggests: binutils-doc (>= 2.20-0ubuntu2)
Conflicts: elf-binutils, gas, modutils (<< 2.4.19-1)
Size: 1660892
Description: The GNU assembler, linker and binary utilities
 The programs in this package are used to assemble, link and manipulate
 binary and object files.  They may be used in conjunction with a compiler
 and various libraries to build programs.
Original-Maintainer: Matthias Klose <doko@debian.org>

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.

SteveM
  • 919
  • 4
  • 6