From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 00:09:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B1D8D96; Sun, 16 Nov 2014 00:09:09 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C02619CF; Sun, 16 Nov 2014 00:09:08 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id h15so1605478igd.8 for ; Sat, 15 Nov 2014 16:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UTRQr/tf0YsCgTlhQREygqA8GAnlGAWajO6/oNKfsdc=; b=x6BTH1Gnbg3sszJ/L0wZh1EXbmLpns5Vh0IjE+jWUMB+ED03b9EX+ENmn5DYcZ/Kng /6z2cO6VPDHmbU2tqVspS0CY480RIuQi6ZQqUvwJp+DqP/rlnaEhKQXo0SLckWj5+FEc ykzctkMI4DMjvj2vL/flJ6N8/uSt/RqtDNzR8aPjMeWPWsXWnY+H9LUm2lhDHRbu8H1O sBqTAcEHKCvD7fVSTAMJAIEhQjyXwGdJfCz+RT1eYrt6966xDWiLQYVhOZ4Dmfn+jJFe atGCid2OrpiSa+/5T7GZ1fFHoet9o4j29AfNIqemLFaPRq0s543wDXJYhddaLqa5tS5F EFrQ== MIME-Version: 1.0 X-Received: by 10.42.100.14 with SMTP id y14mr4449icn.64.1416096548159; Sat, 15 Nov 2014 16:09:08 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.7.169 with HTTP; Sat, 15 Nov 2014 16:09:08 -0800 (PST) In-Reply-To: References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> Date: Sat, 15 Nov 2014 16:09:08 -0800 X-Google-Sender-Auth: U0qHsL_8trrute8fh7HMxrkkU9Q Message-ID: Subject: Re: best overall upgrade from 8.x? From: Kevin Oberman To: Michael Ross Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List , Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 00:09:09 -0000 On Sat, Nov 15, 2014 at 9:38 AM, Michael Ross wrote: > On Sat, 15 Nov 2014 16:20:49 +0100, Dimitry Andric > wrote: > > On 15 Nov 2014, at 13:53, Adrian Wontroba 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@gmail.com