From owner-freebsd-current@FreeBSD.ORG Sun Apr 21 08:02:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C103912; Sun, 21 Apr 2013 08:02:11 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 02B299E9; Sun, 21 Apr 2013 08:02:10 +0000 (UTC) Received: from p5dc3f97b.dip0.t-ipconnect.de ([93.195.249.123] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UTpDr-0006vQ-7p; Sun, 21 Apr 2013 10:02:07 +0200 Message-ID: <51739CFA.4040403@gwdg.de> Date: Sun, 21 Apr 2013 10:02:02 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Steven Hartland Subject: Re: Booting an alternative kernel from loader prompt fails the first time only References: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> <5172C699.8020708@smeets.im> <5172CF44.1050309@gwdg.de> <201304201741.r3KHfrJe001805@pozo.com> <517327C5.5050305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: ae@freebsd.org, Joshua Isom , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 21 Apr 2013 08:02:11 -0000 On 21.04.2013 02:36 (UTC+2), Steven Hartland wrote: > > ----- Original Message ----- From: "Joshua Isom" > To: > Sent: Sunday, April 21, 2013 12:41 AM > Subject: Re: Booting an alternative kernel from loader prompt fails the > first time only > > >> On 4/20/2013 12:41 PM, Manfred Antar wrote: >>> At 10:24 AM 4/20/2013, Rainer Hurling wrote: >>>> On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote: >>>>> On 20.04.13 18:05, Steven Hartland wrote: >>>>>> When trying to boot an alternative kernel from the loader prompt >>>>>> it fails the first time the command is run but succeeds the second >>>>>> time. >>>>>> >>>>>> Type '?' for a list of commands, 'help' for more detailed help. >>>>>> OK boot kernel.generic >>>>>> Booting... >>>>>> don't know how to load module '/boot/kernel.generic/kernel' >>>>>> OK boot kernel.generic >>>>>> Booting... >>>>>> /boot/kernel.generic/kernel text=0xd21288 data=...... >>>>>> >>>>> >>>>> Yes, I've been seeing the same thing for about 6-12 months maybe more. >>>>> None of the people I asked were able to confirm, so I'm happy that I'm >>>>> not imagining it :) >>>> >>>> I also can confirm this behaviour for month now (on 10.0-CURRENT amd64 >>>> with clang). >>>> >>>> Rainer >>>> >>> >>> Have you tried: >>> OK boot /boot/kernel.generic/kernel >>> >>> Use full path name always works for me >>> Manfred > > I believe this may well have been introduced by:- > http://svnweb.freebsd.org/base?view=revision&revision=241069 > > When booting with a /boot/loader.conf that contains a module load line > e.g. zfs_load="YES" then this is loaded before the kernel. > > Loading any module causes last_file_format to get set so when the next > file that's loaded is in fact a kernel it still try's to load it as a > "kernel module" using what was stored with last_file_format. > > This fails and trips the "Restart from the beginning" case which contains: > last_file_format = i = 0; > fp = NULL; > continue; > > So "i" gets set to 0 but the loop then increments it to 1 before running > the next iteration, so its impossible to use first handler in the retry > case; which I suspect is the kernel loader. > > This also explains why the second call to boot works as last_file_format > is now 0 due to the previous failure. > > If this is the issue the attached patch should fix it. I can't test it > ATM as my current box is at the office and doesn't have remote KVM, so > I need to be in front of it. > > If anyone can confirm this attached patch fixes the problem then I'll get > it committed, otherwise I'll test on Monday. I tried your patch with recent 10.0-CURRENT amd64 (r249715, clang), and it seems to work. I can set module path, load some modules, and afterwards load a kernel in one call. Thank you very much. Best wishes, Rainer > > Regards > Steve