Eponymous
   



About
My Infrequently Updated Blog. The web-based journal of M. Forde, computer nerd, endurance athlete, and DeLorean owner


contact

Subscribe
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Flavors
There's more than one way to view this weblog; try these flavors on for size.

  • index
  • circa 1993
  • Sections

  • main
  • musings
  • running
  • DeLorean
  • code
  • unix
  • album
  • TBM
  • Archives

  • 2022
  • 2021
  • 2020
  • 2019
  • 2018
  • 2017
  • 2016
  • 2015
  • 2014
  • 2013
  • 2012
  • 2011
  • 2010
  • 2009
  • 2008
  • 2007
  • Disclaimers, Copyrights, Privacy, Etc.

  • ToS
  • Copyrights
  • Links

  • olix0r.net
  • netmeister.org
  • Giraffes
  • Eat. Run. Sleep.

  •        
    12 Oct 2013

    Problems with loader.conf

    First the background. The story of how I got into this mess:



    I'm trying to get ACPI working on my laptop under FreeBSD. Specifically, I'm trying to get Resume to work properly. Suspend works, and resume seems to partially work. The fans spin up, the keyboard's backlight comes back on, but no screen. And without video, it's a little hard to figure out what's going on.

    ACPI works great on my server. It's running the same FreeBSD 9.1 x86-64 build that the laptop is, but the biggest difference is that it's an intel motherboard. The laptop is an Alienware, for our purposes, I might as well just call it a Dell.

    I started comparing the ASL output from both machines and noticed some things. First, the Alienware's ACPI implementation looks for the OS to be various forms of Windows or "Linux." The intel ACPI implementation also looks for these Windows variants and "Linux" but it has an additional OS string. It has an entry for "FreeBSD."

    I figured the easiest next step was to use iasl co compile the intel ASL source and load that DSDT onto the laptop.

    I calculated the odds it would work vs the odds I was doing something incredibly stupid... and I went ahead and did it anyway...

    I compiled the asl and I set /boot/loader.conf to override the DSDT with the intel one I had just compiled and I rebooted. At first everything was good. The machine went down, I got the boot loader, and the FreeBSD kernel started to load. Seconds into the kernel load, it rebooted itself. After the second time, I powered off and tried a cold boot. Same problem just as I had feared.

    Now i was in a situation where I couldn't successfully boot because of an error in loader.conf I needed to find a way to edit it.

    And here's the solution:



    The FreeBSD bootloader, like many others, works in stages. At a certain point, it can be interrupted at which point it provides a set of simple yet powerful commands to control various aspects of the loading process. If you still have that default menu at load, I beleive the option to chose is 6. I disable that menu so during a brief countdown I hit escape before the boot loader turns control over to the kernel.

    Once in the boot loader prompt, I entered the following commands:

    unload
    load kernel
    boot
    


    Pretty simple right? The unload command does what it says, it unloads the kernel and any modules loader.conf had pulled into memory. The load kernel command grabs the kernel and loads it into memory... but only the kernel thus ignoring the broken DSDT in loader.conf. And of course boot tells the boot loader to continue booting the system.

    Once booted, I removed the bad DSDT from loader.conf.

    [/unix] [permanent link]