Hi Andy,
Thank you for the clarification and guide. I'll be organizing with my users
then making the switch in a week or two.
cheers,
David
If man has no tea in him, he is incapable of understanding truth and
beauty. ~Japanese Proverb
Find yourself a cup of tea; the teapot is behind you. Now tell me about
hundreds of things. ~Saki
On Fri, 19 Jul 2019 at 14:25, Andy Smith <andy@???> wrote:
> [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@???
> https://lists.bitfolk.com/mailman/listinfo/users
>
