matthew at linuxfromscratch.org
Sun Dec 30 01:00:03 PST 2012
On Sat, 2012-12-29 at 21:40 -0800, Nathan Coulson wrote:
> On Sat, Dec 29, 2012 at 8:51 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> > I would like to propose adding gptfdisk to LFS.
> > http://sourceforge.net/projects/gptfdisk/
> > It allows creation and management of GUID Partition Table (GPT) disks
> > using a fdisk type syntax. It's much easier to use than gnu parted.
> > After using a GPT partitioned disk for a while, I recommend it over the
> > ancient BIOS/MBR partitioned disks. The package builds gdisk, cgdisk,
> > sgdisk (similar to fdisk, cfdisk, and sfdisk), and fixparts.
> > The table looks like:
> > # gdisk -l /dev/sdc
> > GPT fdisk (gdisk) version 0.8.5
> > Partition table scan:
> > MBR: protective
> > BSD: not present
> > APM: not present
> > GPT: present
> > Found valid GPT with protective MBR; using GPT.
> > Disk /dev/sdc: 78165360 sectors, 37.3 GiB
> > Logical sector size: 512 bytes
> > Disk identifier (GUID): 1A083159-55E5-40A2-BC78-C269AB11A96E
> > Partition table holds up to 128 entries
> > First usable sector is 34, last usable sector is 78165326
> > Partitions will be aligned on 2048-sector boundaries
> > Total free space is 299020 sectors (146.0 MiB)
> > Number Start (sector) End (sector) Size Code Name
> > 1 2048 23298000 11.1 GiB 8300 /opt for sdc2
> > 2 23592960 44040192 9.8 GiB 8300 / for lfs-7.2-rc1
> > 3 44042240 78165326 16.3 GiB 8300 / for svn-20121216
> > --------
> > When I created the first two partitions, I used GB instead of GiB so the
> > ending points created some small gaps.
> > The package requires libuuid (from util-linux) and ncurses.
> > There are some optional libraries (ICU library at
> > http://site.icu-project.org for unicode partition names) and sgdisk
> > requires popt.
> > The build requires editing or patching the Makefile if the ICU or popt
> > library files are not available. Then a simple make. The executables
> > and man pages are installed with a simple cp.
> > -----
> > The other alternative is to put the package in BLFS but that makes LFS
> > incomplete because it would not be available to manage a GPT disk by
> > itself. We could put it in both LFS and BLFS (for the optional
> > dependencies).
> > Thoughts?
> > -- Bruce
> I do prefer it for it's simplicity over parted, but I think BLFS would
> be good enough for that tool. As nice as it is, we don't use fdisk
> or gdisk in LFS. (And in BLFS, we have the choice of parted or gdisk)
I agree. We use the host's tools to create the partition layout for
LFS, so they can continue to be used should things need altering before
hitting BLFS. It looks like a useful addition to BLFS though. Maybe an
additional sentence or two in the note in
chapter02/creatingpartition.xml could point the reader in the right
direction for GPT and EFI partitioning schemes and related software?
More information about the lfs-dev