gpg: Signature made Mon Feb 19 16:01:15 2018 UTC
gpg: using DSA key 2099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hi Ross,
On Mon, Feb 19, 2018 at 09:10:54AM +1300, Ross Younger wrote:
> On 18/02/18 22:34, Andy Smith wrote:
> >- If you're 32-bit you need to make a decision about Meltdown,
> > whether you will wait for a 32-bit kernel fix or look at going to
> > 64-bit by some means.
>
> Are 64-bit guests an option these days? I don't see the lm flag in
> /proc/cpuinfo on my VPS.
Yes, 64-bit has been the default at BitFolk since about 2015, though
I don't think there was an announcement made.
Although in some cases 32-bit might be faster, even the smallest
BitFolk VPS is 2GiB and is starting to push up against the 4GiB
limit, numerous server-focused apps are only interested in 64-bit,
and it seems that the upstream kernel developers are much more
interested in 64- than 32-bit. So I would have to say that the case
for installing a *new* 32-bit of anything is weak.
> Am I right in thinking that a 64-bit kernel with a 32-bit userland would
> achieve Meltdown protection without the hassle of converting userland?
Yes, although how easy that is to achieve with regard to your Linux
distribution differs somewhat. It is pretty easy with Debian/Ubuntu.
> (Having recently crossgraded my home server from 32-bit to 64-bit Debian I
> am a bit reticent to do so on my VPS. I got there but it turned into a bit
> of a marathon.)
Here are the instructions for Debian:
<https://wiki.debian.org/CrossGrading>
This is not a supported (by Debian, nor by BitFolk) thing to do but
it generally works. I have done it myself many times.
The biggest issues tend to be when you come to installing 64-bit
versions of already-installed packages, but if you are intending to
only switch the kernel then there shouldn't be any of that.
While you can do this from Debian wheezy onwards, I would recommend
upgrading to the latest stable release of Debian before trying this,
as the multi-arch support is better in later releases.
Basically if you only want to change the kernel then it's the most
minimal form of cross-grade, though you can go further and replace
every package with its 64-bit equivalent if you want.
The only necessary BitFolk addition to this procedure is that you
need to tell us that you have switched to a 64-bit kernel before you
boot it, otherwise grub won't boot it. To do this you need to be
logged in to the Xen Shell and type "arch x86_64".
You would do this in step 2 "Install a kernel that supports both
architectures in userland" so instead of "reboot" you should do
"halt", and then do the command in the Xen Shell, and then "boot" in
the Xen Shell.
If you decided to back out of this later you could still go back and
type "arch i686" and boot your old kernel (as long as you didn't
delete it).
I imagine the procedure for Ubuntu is very similar.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
