best overall upgrade from 8.x?

[Kevin Oberman]

On Sat, Nov 15, 2014 at 9:38 AM, Michael Ross <gmx at ross.cx> wrote:

> On Sat, 15 Nov 2014 16:20:49 +0100, Dimitry Andric <dim at freebsd.org>
> wrote:
>
>  On 15 Nov 2014, at 13:53, Adrian Wontroba <aw1 at stade.co.uk> wrote:
>>
>>>
>>> On Sat, Nov 15, 2014 at 12:44:33PM +0100, Andrea Venturoli wrote:
>>>
>>>> On 11/15/14 05:48, Kevin Oberman wrote:
>>>>
>>>>> I'd wait a month or so and, if no problems that might impact you pop
>>>>> up,
>>>>> I'd go with 10.1
>>>>>
>>>> Uh... is direct upgrade (using sources) possible from 8.4 to 10.1?
>>>> No need to step through 9.x?
>>>>
>>>
>>> Even the move from 9.2 (a near year old 9/stable) to 10.1 (stable/10 as
>>> of about 3 weeks ago) is slightly problematic.
>>>
>>> Following the normal upgrade procedure of installkernel and then
>>> rebooting with the userland untouched runs into a problem whereby
>>> rc.conf falls apart with a shower of eval errors, no networking, ...
>>>
>>> I do not know the cause.
>>>
>>
>> I almost certainly know the cause: you are supposed to reboot into
>> single user mode after installkernel.  A regular boot to full multi user
>> mode may or may not work, depending on numerous unpredictable
>> circumstances. :-)
>>
>>
> If you follow the handbook,
> you are not supposed to reboot at all after installkernel.
> I think it was advised once, but it does no longer say so,
> it just says "drop to single user".
>
> Well, it still says "[single user] also minimizes any problems from
> running the old world on a new kernel." which you don't actually do if you
> follow the instructions.
>

I'm disturbed that this change was made. It's in invitation to an unlikely,
but very real disaster. It has not been changed in UPDATING and I strongly
feel that it should be reverted in the Handbook.

The problem with failing to reboot to single user (as opposed to just
dropping to single-user) is that you are installing (and running) the new
world while still running the old kernel. This, of itself could make the
system unstable until it is rebooted, but the more serious issue is that
you have an untested kernel that will be used on the next reboot. If it
fails to boot, you are in a deep hole as you already are running a new
world. You could just boot the old kernel and figure out what went wrong at
your leisure. Instead you are stuck with a new world and an old kernel at
best. That may or may not give you a usable system and dropping back to the
old world is not trivial. It can leave you down for a while as you recover.

I speak from pained experience having been bitten by this some years ago.
It took quite some effort to recover. I just happened to buildkernel at a
bad time when it was broken. It was fixed shortly, but I had no working
network, so could not get the fix or even pull down a CD image with an old
userland that would work. It would be a bit easier to deal with today as I
could use another system to pull down a memory stick system that could have
greatly simplified the fix, but there is a good reason to be sure that the
new kernel builds BEFORE updating userland. I think recommending this is a
very bad idea.

Going back the the original issue:
> cd /usr/src
> mergemaster -p
So far, so good.
> make installkernel
> make installworld
OK. Where were the buildworld and buildkernel? Both should have come after
the "mergemaster -p" though there has never been a case where "mergemaster
-p" has been required before buildworld. Still, there might be some day.
The man page states that it should precede the buildworld, too.
"-p    Pre-buildworld mode.  Compares only files known to be essential to
the success of {build|install}world, including /etc/make.conf."
> mergemaster
> shutdown -r now

I agree that this will usually work fine and I have done it, but I have
always done the same update on a local system first, just in case, and I
understand that I may shoot my system in the foot and that may require an
extended down-time.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com