freebsd stable - Dec 2018 - Upgrading 11.2 -> 12.0 on EC2

> On Dec 19, 2018, at 1:50 AM, Brian Neal <brian at aceshardware.com>
wrote:
> 
> I?m looking for advice on doing a release upgrade of a running instance. 
It looks like the normal procedure using freebsd-update requires a reboot
between invocations of the install command, but after the first reboot, most of
the userland is non-functional, including most importantly sshd. Is it safe to
run the install commands back to back without rebooting?  Or is the only safe
procedure to build a new instance from scratch for each release?
Brian,

It?s not true that after the first reboot the userland is non-functional; sshd
and friends should still be working fine. The first reboot switches you to the
12.0 kernel, which is necessary as the first step before upgrading the userland
to 12.0 ? and of course potentially using `pkg-static` or ports to
rebuild/reinstall your packages/ports against the new ABI.

If you?re running any kind of public-facing service, the safest method in my
opinion *with as little downtime as possible* is to deploy a new instance and
then point to it once everything is successfully reinstalled (e.g., DNS change,
elastic IP change, elastic load balancer, etc.). Otherwise, the ?safe? method to
upgrade in place is to follow what the handbook says, including when to reboot
between invocations of `freebsd-update`. As long as you follow exactly when it
instructs a reboot, and when to upgrade/reinstall userland and packages/ports,
you should be fine. If you?re still nervous, just snapshot your boot EBS volume
first as an extra precautionary measure, and destroy it once you verify
everything post-upgrade.


--
Matt Garber

Thanks, Matt. I did try the update procedure from the handbook and found the
instance hanging on boot with a repeated socket error. If I have to rebuild from
scratch, I?d prefer to find some jail/deployment-automation so I don?t have to
manually rebuild everything on each release. FWIW, I did have to recreate the
instance when moving from 10 to 11.

Cheers,

-Brian
> On Dec 19, 2018, at 7:33 AM, Matt Garber <matt.garber at gmail.com>
wrote:
> 
> 
>> On Dec 19, 2018, at 1:50 AM, Brian Neal <brian at
aceshardware.com> wrote:
>> 
>> I?m looking for advice on doing a release upgrade of a running
instance.  It looks like the normal procedure using freebsd-update requires a
reboot between invocations of the install command, but after the first reboot,
most of the userland is non-functional, including most importantly sshd. Is it
safe to run the install commands back to back without rebooting?  Or is the only
safe procedure to build a new instance from scratch for each release?
> 
> Brian,
> 
> It?s not true that after the first reboot the userland is non-functional;
sshd and friends should still be working fine. The first reboot switches you to
the 12.0 kernel, which is necessary as the first step before upgrading the
userland to 12.0 ? and of course potentially using `pkg-static` or ports to
rebuild/reinstall your packages/ports against the new ABI.
> 
> If you?re running any kind of public-facing service, the safest method in
my opinion *with as little downtime as possible* is to deploy a new instance and
then point to it once everything is successfully reinstalled (e.g., DNS change,
elastic IP change, elastic load balancer, etc.). Otherwise, the ?safe? method to
upgrade in place is to follow what the handbook says, including when to reboot
between invocations of `freebsd-update`. As long as you follow exactly when it
instructs a reboot, and when to upgrade/reinstall userland and packages/ports,
you should be fine. If you?re still nervous, just snapshot your boot EBS volume
first as an extra precautionary measure, and destroy it once you verify
everything post-upgrade.
> 
> 
> --
> Matt Garber
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2267 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20181219/3f70db53/attachment.bin>