OpenBSD Journal

GPT support enabled

Contributed by tj on from the LBA-1 dept.

Amongst the flurry of commits from the l2k15 hackathon, Ken Westerback (krw@) has been hacking away on GPT support, and it's now enabled in the GENERIC kernel.

CVSROOT:	/cvs
Module name:	src
Changes by:	krw@cvs.openbsd.org	2015/09/10 10:30:23

Modified files:
	sys/arch/amd64/conf: GENERIC 
	sys/arch/i386/conf: GENERIC 
	sys/conf       : files 
	sys/kern       : subr_disk.c 
	sys/sys        : disklabel.h 

Log message:
Now that the GPT code tries really hard not to get in the way and
accidentally capture disks ...

Eliminate kernel option GPT and associated #ifdef GPT/#endif. Let
everybody get on the GPT bandwagon and we'll see what wheels fly
off.

Requested by & ok deraadt@

This comes after many recent GPT-related fixes hitting the tree. If you've got disks over 2TB in size, now is the time to start testing.

(Comments are closed)


Comments
  1. By Renaud Allard (renaud) renaud@allard.it on

    This hackaton is exceptional in new features. UEFI boot, GTP, hypervisor...

    About GPT, should GPT be used if OpenBSD is the only OS on the disk?

    Comments
    1. By Ilyas Bakirov (82.200.241.50) on

      > This hackaton is exceptional in new features. UEFI boot, GTP, hypervisor...
      >
      > About GPT, should GPT be used if OpenBSD is the only OS on the disk?
      GPT is not mandatory. But if you have disks larger than 2TB then you must use GPT

      Comments
      1. By Josh Grosse (129.9.75.197) on

        > ...But if you have disks larger than 2TB then you must use GPT...

        Not quite. Prior to this addition of GPT to the OS, MBRs have been required for boot disks (and disks shared with other OSes) on MBR architectures. But only the first two TB of the disk can be mapped with an MBR partition table. See FAQ 14.8 for the details.

        GPT provisioning tools have not yet been committed to fdisk(8), only the protective MBR, per option -g.

        Comments
        1. By journeysquid (Tor) on http://www.openbsd.org/donations.html

          > > ...But if you have disks larger than 2TB then you must use GPT...
          >
          > Not quite. Prior to this addition of GPT to the OS, MBRs have been required for boot disks (and disks shared with other OSes) on MBR architectures. But only the first two TB of the disk can be mapped with an MBR partition table. See FAQ 14.8 for the details.
          >
          > GPT provisioning tools have not yet been committed to fdisk(8), only the protective MBR, per option -g.
          >

          Is fdisk required at all if a drive will never be booted or otherwise accessed by the BIOS (i.e. a data-only softraid array)?

          Comments
          1. By Josh Grosse (68.37.10.225) on

            > Is fdisk required at all if a drive will never be booted or otherwise accessed by the BIOS (i.e. a data-only softraid array)?

            Nope. You only need fdisk to provision MBRs (and soon, apparently, GPTs) on boot disks or on disks that are shared with other OSes. Otherwise, you only need disklabels. (And yes, you could get away with no disklabel if the drive is to be used for a single filesystem or as raw storage.)

    2. By Renaud Allard (renaud) on

      Is GPT already fully enabled in snapshots? Can I boot on a 2Tb+ disk with GPT?
      I tried an install on a 3Tb disk, and the installer tells me:
      'fdisk: disk too large (6291456000 sectors). size truncated.

      If I use "fdisk -g -i /dev/rsd0c", I get the same message asking me if I want to create a MBR.

      But if I do a simple fdisk afterwards, it tells me I have a EFI GPT.

      However, it fails to install bootblocks in the end, and obviously booting fails.

      Comments
      1. By Anonymous Coward (68.37.10.225) on

        > Is GPT already fully enabled in snapshots?

        Per krw@'s report, the GPT provisioning tool will be fdisk, but the development is not yet committed. So at the moment you can boot a GPT but provisioning must be done from another OS.

  2. By Anonymous Coward (91.109.247.173) on

    Flurry of commits? I'm checking freshbsd.org regularly and there's hardly any OpenBSD commit...

    Comments
    1. By Anonymous Coward (212.251.191.104) on

      > Flurry of commits? I'm checking freshbsd.org regularly and there's hardly any OpenBSD commit...

      Try to check period 8 - 13 sep here:
      https://marc.info/?l=openbsd-cvs&r=1&w=2
      Think you'll find they weren't slacking....

    2. By Anonymous Coward (5.79.68.161) on

      > Flurry of commits? I'm checking freshbsd.org regularly and there's hardly any OpenBSD commit...

      FreshBSD's CVS-Git mirror for OpenBSD is regularly broken and down for days at a time. It's not very reliable for anything except Git-based projects.

Latest Articles

Credits

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 deadly.org 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.]