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

On Sun, Apr 21, 2013 at 01:36:58AM +0100, Steven Hartland wrote:
> 
> ----- 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.

I've been noticing this issue on my laptop, and I can confirm that the
patch fixes it.

-Mark