amd64/163442: boot/loader.conf not processed at boot time

[John Baldwin]

On Wednesday, December 21, 2011 12:55:27 pm Thomas D. Dean wrote:
> On Wed, 2011-12-21 at 07:43 -0500, John Baldwin wrote:
> > On 12/20/11 1:06 PM, Thomas D. Dean wrote:
> 
> > Uh, so using grub to load the loader was the fix?  That isn't a
> > real fix.  Can you disable the beastie (beastie_disable="YES") and
> > the automatic boot (autoboot_delay="NO") in loader.conf and then
> > either use a serial console or a camera to capture the messages on
> > the screen when it loads the modules.  Then do a boot -v from the
> > prompt and save the output of 'dmesg' to a file after it boots.
> > Put that file up somewhere where I can look at it to see if there
> > were errors parsing the modules loaded from the loader.
> > 
> 
> Sorry, I was not clear.
> 
> I installed grub in my original configuration of the new machine, built
> from components, no OS.  I created gpt partitions on two disks with 
> linux.
> 
> I installed windows 7 on the first disk, then, linux with grub on the 
> second disk, fixing grub to boot windows.  Then, I installed FreeBSD on 
> the second disk.  Again, I edited grub (in linux) to boot all three.
> 
> At this point, I had grub configured to directly load the FreeBSD 
> kernel, not using the loader.  So, any loader configurations were not 
> effective because the loader was never executed.  The beastie never 
> appeared.  Until the discussion on this list, I never noticed the 
> absence.  This was a mistake on my part. I wanted to use the FreeBSD
> loader and get the benefits of configuring modules, etc., at boot time.
> 
> Going back to linux and configuring grub properly to use the FreeBSD 
> loader fixed the problem.
> 
> I can try to gather information, but, I will have to go back to the 
> improper (broken?) grub configuration to do it.

Oh, nevermind, I understand now.  No need for further information.

-- 
John Baldwin