From owner-freebsd-current@FreeBSD.ORG Sun Apr 21 00:36:40 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 886B0FF9; Sun, 21 Apr 2013 00:36:40 +0000 (UTC) (envelope-from prvs=18233350e1=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DC80014F8; Sun, 21 Apr 2013 00:36:39 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50003397896.msg; Sun, 21 Apr 2013 01:36:36 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 21 Apr 2013 01:36:36 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=18233350e1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Joshua Isom" , , References: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> <5172C699.8020708@smeets.im> <5172CF44.1050309@gwdg.de> <201304201741.r3KHfrJe001805@pozo.com> <517327C5.5050305@gmail.com> Subject: Re: Booting an alternative kernel from loader prompt fails the first time only Date: Sun, 21 Apr 2013 01:36:58 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03C0_01CE3E30.B6797AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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 00:36:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03C0_01CE3E30.B6797AD0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit ----- 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. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_03C0_01CE3E30.B6797AD0 Content-Type: application/octet-stream; name="alternative-boot.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="alternative-boot.patch" --- sys/boot/common/module.c.orig 2013-04-21 00:16:28.801989165 +0000=0A= +++ sys/boot/common/module.c 2013-04-21 00:18:23.544977000 +0000=0A= @@ -289,7 +289,8 @@=0A= break;=0A= } else if (last_file_format =3D=3D i && i !=3D 0) {=0A= /* Restart from the beginning */=0A= - last_file_format =3D i =3D 0;=0A= + last_file_format =3D 0;=0A= + i =3D -1;=0A= fp =3D NULL;=0A= continue;=0A= }=0A= ------=_NextPart_000_03C0_01CE3E30.B6797AD0--