Page MenuHomeFreeBSD

NanoBSD: support for GPT partitioning
Needs ReviewPublic

Authored by thomas on May 17 2015, 7:12 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 6, 7:55 AM
Unknown Object (File)
Sat, Apr 6, 7:31 AM
Unknown Object (File)
Dec 28 2023, 12:24 PM
Unknown Object (File)
Dec 17 2023, 3:14 PM
Unknown Object (File)
Dec 13 2023, 1:47 PM
Unknown Object (File)
Nov 22 2023, 2:16 AM
Unknown Object (File)
Oct 21 2023, 5:45 AM
Unknown Object (File)
Oct 21 2023, 1:53 AM
Subscribers

Details

Reviewers
imp
Summary

This change introduces a new variable NANO_PART_SCHEME, which can be used to
specify the desired partitioning scheme. The default is "MBR", providing a
legacy PC partition table, for backwards compatibility.

The alternate value "GPT" causes a GPT partitioning to be used instead. The
two system slices are p1 and p2. The configuration slice is p3. An additional
boot slice p15 is created to hold the GPT boot code.

Test Plan

Tested with the "rescue_amd64" configuration

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage

Event Timeline

thomas retitled this revision from to NanoBSD: support for GPT partitioning.
thomas updated this object.
thomas edited the test plan for this revision. (Show Details)
thomas added a reviewer: imp.

This is a good start, but I think needs some cleanup.

Also, I have a bunch of patches to use mkimage which doesn't require root at all, as well as brook's NO_ROOT stuff to build the mtree files that makefs can use to populate the whole tree. These patches are incomplete at this time, but is more in the direction I'd hoped to go. How does that fit with what you've done?

tools/tools/nanobsd/defaults.sh
425

Why not have
CFG_PART=s3 # for MBR
or
CFG_PART=p3 # for GPT
CFG_DEV=${NANO_DRIVE}${CFG_PART}

and use that here:

echo "mount -o ro /dev/${CFG_DEV}" > conf/default/etc/remount

With similar for the other partitions / slices we used to use...

530

Won't gpart do all this math now so we don't need to? And can't we just call gpart directly to do it?

613–623

I thought gpart was able to do this too, w/o needing to resort to bsdlabel at all.

Thanks for your feedback, Warner! I will send an updated patch.