From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 07:51:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1770106564A for ; Fri, 14 Oct 2011 07:51:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 195E78FC17 for ; Fri, 14 Oct 2011 07:51:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA17602; Fri, 14 Oct 2011 10:51:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1REcXo-000PaR-Bn; Fri, 14 Oct 2011 10:51:04 +0300 Message-ID: <4E97E9E5.2020908@FreeBSD.org> Date: Fri, 14 Oct 2011 10:51:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4E580B14.7090208@FreeBSD.org> <1A828073-1D5F-4850-9379-4AB62CF3DAE3@xcllnt.net> <4E5B4BFB.9040907@FreeBSD.org> <4E5BF43A.5050306@FreeBSD.org> <4E5CB502.5020508@FreeBSD.org> In-Reply-To: <4E5CB502.5020508@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , FreeBSD-Current Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 07:51:16 -0000 on 30/08/2011 13:01 Andriy Gapon said the following: > > So, just to re-iterate, I think that this is indeed a regression and the one > that could be particularly unhelpful for a new release - the time when people > are much more likely to end up at the mountroot prompt during an installation of > a new system or an upgrade. Marcel, is there any chance that this regression can be fixed before the release? If not, then maybe it would be proper to pull the change that introduced it out of the release branch (r214006) ? > on 29/08/2011 23:19 Andriy Gapon said the following: >> on 29/08/2011 19:45 Marcel Moolenaar said the following: >>> >>> On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote: >>> >>>> on 27/08/2011 18:16 Marcel Moolenaar said the following: >>>>> >>>>> On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote: >>>>> >>>>>> >>>>>> It seems that after the introduction of the mountroot scripting language a user >>>>>> now has exactly one chance to try to specify a correct root device at the >>>>>> mountroot prompt. I am not sure that that is convenient/enough. >>>>> >>>>> This is no different from before. >>>> >>>> Are you sure? >>>> I remember trying multiple (incorrect) possibilities at the prompt and not >>>> getting the panic. But I know that sometimes I have cases of "false memories", >>>> so _I_ am not sure. >>> >>> I'm sure now that we're both not sure :-) >>> >>> It's possible the failure mode varied by how the root mount >>> failed... >> >> >> Judging from the code before r214006 it shouldn't have panic-ed upon such a failure: >> static int >> vfs_mountroot_ask(void) >> { >> char name[128]; >> char *mountfrom; >> char *options; >> >> for(;;) { >> ... >> gets(name, sizeof(name), 1); >> if (name[0] == '\0') >> return (1); >> if (name[0] == '?') { >> printf("\nList of GEOM managed disk devices:\n "); >> g_dev_print(); >> continue; >> } >> if (!vfs_mountroot_try(name, NULL)) >> return (0); >> } >> } >> >> >> So this "endless" loop was exited only if vfs_mountroot_try() returned success >> (error == 0) or if a user entered an empty string. >> > > -- Andriy Gapon