Re: Booting an alternative kernel from loader prompt fails the first time only

From: Steven Hartland <killing_at_multiplay.co.uk>
Date: Sun, 21 Apr 2013 01:36:58 +0100
----- Original Message ----- 
From: "Joshua Isom" <jrisom_at_gmail.com>
To: <freebsd-current_at_freebsd.org>
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_at_multiplay.co.uk.
Received on Sat Apr 20 2013 - 22:36:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC