OpenBSD Journal

Booting offsets greater than 8GB

Contributed by jose on from the welcome-to-the-21st-century dept.

Tom Cosgrove has committed the pieces that make booting from partitions with offsets greater than 8GB.
Modified files:
        sys/arch/i386/stand/biosboot: biosboot.S biosboot.8 
        sys/arch/i386/stand/installboot: installboot.c installboot.8 

Log message:
Major overhaul of biosboot and installboot, using EDD (LBA) reads if
the BIOS supports it.  File location data now geometry-independent
(biosboot groks part of the inode), so installboot loses -h and -s.

Many thanks to all those brave enough to try the snapshots.  Thanks
for the test reports, everyone.

ok deraadt@
Your hardware (BIOS) requirements are the dictating factor, so older BIOS versions may be problematic. But, this is prety cool. Well done, Tom. The 3.5 release is really shaping up.

(Comments are closed)

  1. By picki () on

    this >8gb problem annoys me so much, that I often decided not to install openbsd. Well done, although years to late...

    1. By tedu () on

      you have that many dual boot setups?

    2. By Anonymous Coward () on

      Why is it annoying?

  2. By Anonymous Coward () on

    I'm just curious. This is not meant to cause a huge flame war or rouse anger or anything.

    Mirabile has done this before for MirBSD. Why wasn't his code used when it was already in place earlier?

    1. By Anonymous Coward () on

      What is the point of doing anything when you have no need for it?

    2. By Nick Holland () on

      There are some things that were never liked about the old OpenBSD loader that were continued in the MirBSD loader.

      For example, you will NEVER see the "Bad Magic" message now, and hopefully not just because it got renamed to "ERR M" 8-).

      Toby Weingartner had an idea to make the biosboot (PBR) geometry-independent. The old biosboot was very sensitive to drive translation geometry, often producing the "Bad Magic" error when moving a drive from computer to computer, or fiddling with the system configuration, and anyone this has ever happened to will understand quickly why this was annoying.

      Reality is, while a lot of people talk about the 8G limit, I and most of the developers really found it Not An Issue, even if we wanted to multi-boot a system (which might explain why it was not done sooner). Understand and plan ahead, and no problem will be encountered. I have at least three machines here where I deliberately set up a ">8G issue" for testing, but I have precisely zero machines where I *needed* to do this. HOWEVER, the reduction of the drive translation issue has already improved my life far more than the >8G booting ever will. It is wonderful to take a drive out of an old P90, put it in a PII-400 and then put it in a 1.4GHz system, and have it Just Work. There are probably situations where the translation will break, and we have already found that some brand new machines don't support >128G booting (due to BIOS limitations), so the "ERR M" will show up from time to time, but probably far less often.

      Changing the boot process a very scary thing to do, requiring massive amounts of testing before we had confidence to put it in-tree. It wasn't something we wanted to do more than need be, so we weren't going to do half-measures.

      Great design, Toby, great implementation, Tom!

      1. By clvrmnky () on

        Nice explanation, Nick. This should go in some kind of FAQ.

      2. By mirabile () on

        The MirOS BSD partition boot record needs geometry
        because of the support for old BIOS and Soekris
        If LBA is used, the head/sector values are not
        used except for installboot(8) - I've seen more
        than just one system which fails to load more
        than one sector in LBA mode at once, if it has
        to cross a (virtual) track boundary.

        Hardware, especially x86 hardware, is more buggy
        than you will ever imagine.

        1. By Nick Holland () on

          That's why we asked for testing. Lots and lots of testing.

          We have well over 120 successes and zero failures reported to us so far. This is including Soekris, 80386, 80486, Pentium, and of course, lots of newer computers (the Soekris user appreciated the geometry independance of the new boot loader!). Well over 30 machines were tested (including a very old 80386 system) before the public testing requests was made.

          If you can show us a system which the new boot loader does NOT work, please do so. We want to make sure that this does NOT BREAK EXISTING MACHINES.

          I can assure you, our imagination for buggy hardware is very vivid. Our experience is pretty significant, as well. We are very aware of the issues. We think we have delt with them. Your efforts to prove us wrong are appreciated. 8)

          1. By mirabile () on

            Congratulations, then.
            You seem to have found a better way to work around.

  3. By asdfg () on

    Anyone knows how this would affect Soekris devices?

    1. By mirabile () on

      Q: Does code compiled with -march=pentium (not
      the one with -march=i486 -mcpu=pentium!) run on
      the 80486-compatible CPU of the soekris?
      I think not, but if the contrary, it'd be good.
      (Stock MirOS-current requires a pentium-class CPU)

      PS: I'm mirabile not Mirabile :-)

    2. By Nick Holland () on

      Shouldn't be any negative impact, you may find it easier to build a flash image on another machine and move it to the Soekris.

  4. By David Wijnants () on

    It's such a pain, always running out of primary partitions to install systems on.

    Linux installs and runs nicely in a logical partition, which is very decent of it, but I can't really see much fun in running dozens of Linuxes on my machine.

    What I really want is to run as many systems as possible in logical partitions, and still accommodate one or two that still insist on being primary.


  5. By Anonymous Coward () on

    This works a charm for me - booting OpenBSD installed in the last 30G of a 120G drive.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]