gpg: Signature made Fri Mar 31 02:49:40 2017 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,
On Wed, Mar 29, 2017 at 03:34:43PM +0000, Andy Smith wrote:
> Reminder that the below work will be happening tonight, starting in
> around 8h24m at 2017-03-30 00:00Z, with the rest of the work taking
> place the following two nights.
The second set of maintenance work has now been completed with one
slight problem.
One of the hosts that was being rebooted is also one of a pair of
routers for our IPv6 traffic, and it happened to be the one that was
active at the time. If/when it goes down it should automatically
fail over to the other one, but I decided to manually fail it over
to make the work simpler.
Unfortunately it seems that when that happens, it also disables IPv6
for all of the VPSes on the host itself (hen). This was unexpected
and took me a few minutes to work out what had happened. After
approximately 9 minutes I realised the problems were restricted to
v6 for VPSes on that single host, and I was able to restore their v6
connectivity. Of course, by that point it was time to reboot the
host anyway.
So, customers on host hen unexpectedly experienced approximately 9
minutes of no IPv6 just before they expectedly experienced it all
being rebooted anyway. Sorry about that! It is likely I never
noticed that issue before because it would have only happened when
the host was down.
Other than that I noticed no suspend-and-restore failures, and there
were only two pvgrub booting problem that I noticed.
The first one was similar to the others seen, which involved Gentoo
and pvgrub complaining that it can't load the kernel. That customer,
like the others, was reverted back to pygrub and I will need to do
further testing.
The other one appeared to be down to the customer having a 64-bit
kernel without telling us, so it wouldn't boot with 32-bit pvgrub.
Switching them to 64-bit pvgrub allowed it to boot.
I will discuss that with the individual customer, but as a reminder:
if you have a 64-bit kernel, we need to know. For a couple of years
now all new installs have been 64-bit, but if you have been a
customer for longer than that you probably started out as 32-bit. If
you've changed it to be 64-bit we need to know otherwise your VPS
won't boot.
You can tell what we think it is by looking at the summary page of
the Panel:
https://panel.bitfolk.com/account/
If it says "/ i686" then we think it's 32-bit.
You can also tell by logging in to your Xen Shell and typing the
"arch" command.
You can tell us it is something different by typing either "arch
x86_64" or "arch i686" in the Xen Shell.
More info here:
https://tools.bitfolk.com/wiki/Booting#Setting_your_architecture
The last remaining work for XSA-212 will take place tomorrow at
00:00Z and 01:00Z.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
