Hi Andy, Thanks for clarifying. I find this situation surprising, so it's good to be clear on it. I have physical machines here, running 64bit capable CPUs (i5,i7) that boot a 32bit OS just fine [I've tardily not migrated these yet...] to boot an existing 32bit OS, which is what surprises me. Therefore, if I was to attempt to undertake an in-place migrate an OS running on Xen, I'd need to install a new bootloader in synchronisation with changing the arch via the Xen console. Yes, I have a full backup of my VPS, but there's no way I'd be able to tell you all the files I've changed and tweaked settings in - I'd be surprised if many people keep such a record. Maybe that's considered that bad form, but I'm no professional sysadmin and my VPS setup has developed organically over many years. This gives me pause to consider how I should be managing all my servers. Thanks, Ian -----Original Message----- From: users <users-bounces+ian=jeffray.co.uk(a)lists.bitfolk.com> On Behalf Of Andy Smith Sent: 03 November 2019 20:12 To: users(a)lists.bitfolk.com Subject: Re: [bitfolk] New installs of 32-bit guests are deprecated Hello, On Sun, Nov 03, 2019 at 05:51:31PM -0000, Ian Jeffray wrote: It's 32- or 64-bits depending on what you tell it to be. indicates? Yes, if you select a 64-bit bootloader it will not be able to boot a 32-bit kernel. As the article indicates there are multiple options, of which reinstallation is one. Why is it that you find this your only option? I would have thought that the simplest option for you would be the one where you install a 64-bit kernel, since that would most likely involve no reconfiguration of anything, except for the few steps necessary to install the kernel itself. Also, I must ask, if it would be very difficult to re-do all the configs, does this mean that you do not have backups of the configs? Assuming you do have backups of the configs of everything, application configuration don't tend to change very much between 32- and 64-bit installs. But maybe identifying what to install and going through setting its configuration is what you're talking about there. The "migration VPS" option gives you two weeks to do it. Again as the article out points out, you do have probably a couple of years to keep going with 32-bit guests, and even then we will find a way to keep booting them. It would just be prudent to find a way to switch before then. Note that everyone currently running Ubuntu has a much more pressing deadline: 18.04 LTS was the last Ubuntu release that will support 32-bit. There aren't any more upgrades for Ubuntu on 32-bit. By the time it comes around to 20.04 there will only be a 64-bit option when installing or upgrading to that. CentOS already made that choice, and yet more will follow. Debian will be slower but I'd give it 5 years to abandon i686. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

On Sun, 3 Nov 2019, 21:41 Andy Smith, <andy(a)bitfolk.com> wrote: I crossgraded my VPS last week (Percona XtraDB cluster wouldn't rejoin, version was too old and they've stopped doing 32bit builds). It was...an interesting experience. Not bad, just mildly challenging. Once you've added the amd64 arch and installed the kernel, you can just shutdown the VPS, change arch in Xen console, and start the VPS. You'll then be running a 64bit kernel and a 32bit userland, which is fine. I then went through a process of listing the remaining i386 packages ("dpkg -l | grep ii.*:i386" IIRC) and then "apt install" bunches of packages - they'll pull in the required amd64 libs. Run 'apt autoremove' regularly to clear out the unneccesary i386 packages. Eventually, you'll be totally amd64 and you can remove the i386 arch from APT. Don't try using aptitude, it'll totally freak out. :D You should at the end, just to keep the package lists clean - any "broken" packages just need their dependencies marked for install. You shouldn't need to do this all in one go (my crossgrade was spread over several days) as it *should* be okay to run in a mixed environment (anyone running Steam or the old Skype for Linux? That was a 32bit app running on 64bit systems).

On 2019-11-04 01:13, Andy Smith wrote: want a challenge and don't care if everything asplodes! 😀 I've just done this to my VM "for the lols" and I would tend to agree. The basic cross-grading steps needed me manually install (using dpkg) both Perl and Python which apt couldn't resolve by itself in order to get apt updated to amd64. During the intial "apt upgrade" steps, I had to manually reinstall Perl modules for Spamassassin which had been removed rather than updated and prevented apt restarting services correctly, which causes it to bail out. Later on during one of the "'Yes, do as I say'" operations, apt removed ifupdown which made the VM drop off the network. After all was said and done, some packages which were previously installed as i386 had been removed and were no longer present, presumably because they were removed because the upgrade of a dependency didn't perform cleanly over multiple invocations of "apt upgrade" as errors came up and had to be fixed. irssi went missing and Apache mod_php was no longer installed; these are probably because of the forcible upgrade of Perl or Python as well. I'm still tidying up the mess. Unless you know what was installed and have backups of all your configs, and can tolerate needless downtime, just don't bother.