amd64/163442: boot/loader.conf not processed at boot time
jhb at freebsd.org
Wed Dec 21 22:01:41 UTC 2011
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
> 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.
More information about the freebsd-amd64