[lfs-dev] gptfdisk

Bruce Dubbs bruce.dubbs at gmail.com
Sun Dec 30 10:07:08 PST 2012


Randy McMurchy wrote:
> On 12/30/2012 3:00 AM, Matt Burgess wrote:
>> 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.
>>>
>>> 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?
>
> FWIW, I also agree with Nathan and Matt. I also think that with so many
> disk partitioning software choices available that LFS should not choose
> *one* to put in the book. To me it takes away from the "Your distro,
> your rules" motto.

We now install fdisk as a part of util-linux so we have chosen one 
method right now for LFS.

My issue is that if the user reboots to the new LFS, there is no way to 
change the partition table if it is a GPT.  The use would have to reboot 
back to the host, make the change and reboot to LFS.  The user can't 
even look at the GPT table.

On the other hand, pretty much the same arguments can be made for wget 
and a few other BLFS packages that I consider essential: sudo, openssl, 
openssh, which, and bc (for my scripts).

Perhaps adding the page to BLFS and expanding the first paragraph in 
section 9.3 of LFS would be the way to go.

   -- Bruce



More information about the lfs-dev mailing list