[Redirected back to the list with permission.]
Hi David,
I should stress again that crossgrading between 32- and 64-bit is
not officially support by Debian/Ubuntu nor BitFolk. It does however
work, multiarch is supported by these distros, I've done it a bunch
of times and so have other customers.
The worst thing that happened to me was that one time I accidentally
let it remove /bin/rm, and I had to scp in a /bin/rm from another
host before dpkg would work again (it requires a working rm
command!). Removing coreutils is not a good plan, for future
reference. :-)
The basic procedure is described here:
https://wiki.debian.org/CrossGrading
The only BitFolk-specific issue is the architecture of the
bootloader that we use to boot your VM. You have to tell us whether
it should be 32-bit or 64-bit. You do that by using the "arch"
command in the Xen Shell.
Going by that page, you would use the Xen Shell "arch" command
after you install the 64-bit (amd64) kernel but before you reboot.
This is step 2 ("Install a kernel that supports both architectures
in userland") in that article.
Assuming your VM then boots 64-bit into the amd64 kernel, you could
stop there. You would be running a 64-bit operating system and
kernel but all your apps would still be 32-bit and anything new you
install would be 32-bit as well.
I think it's unlikely that anything too weird would happen if you
carried on like this.
You could take it a step further, which is step 4 ("Crossgrade
`dpkg` `tar` and `apt`"). That involves downloading the .deb files
for the 64-bit versions of those packages and installing them
forcibly with dpkg. After you've done that your default architecture
would be amd64 so everything new you install would be amd64, while
all your existing stuff that is i386 still works.
Leaving things in this state I've seen some confusion happen at
later package upgrades. Things being upgraded or installed in future
sometimes need to pull in amd64 versions of things already
installed, and apt wants to ask you if you are really sure about
that. So expect some ongoing work.
If you are brave you could go the whole way of listing everything
installed and replacing it with its amd64 counterpart. This is the
really tricky thing to do, as apt won't like you trying to remove
essential things (even though you are only doing it to immediately
replace them) and it will come up with some very odd suggestions
that also involve removing most of your system.
Most times I have tried this involved repeatedly issuing commands
like:
# apt remove blah:i386 blah:amd64+ coreutils:amd64+
and seeing what it suggests, before letting it or hitting 'n' and
trying again.
Note the '+' on the end of some of the package names. This is apt
syntax for "Please remove package blah but also install amd64
architecture of package blah and also keep coreutils installed too".
You do this when apt wants to remove something that you really don't
want it to remove, to tell it to try again with a different plan.
If this sounded scary, or you aren't familiar with doing this sort
of thing, you probably should not try this. Just reinstall. Or keep
going with a 64-bit kernel and 32-bit userland.
The other thing I would say is, make sure you are familiar with how
to use the Xen Shell to start, stop, destroy (power yank) your VPS
and access its console. It is totally mad^W^Wextremely unwise to
consider trying to change the architecture of your running VPS
without having offline access to its console, yet I have had to
rescue a few people who gave it a go and then were flummoxed when
their only problem was that grub was waiting for them to choose
which kernel to boot.
Of course, if you don't fancy doing any of that, the offer of a free
VPS for 2 weeks to migrate into is always there.
https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users@lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users