Re: [bitfolk] Another prod regarding 32-bit guests

[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(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/users