Re: Removing fdisk and bsdlabel (legacy partition tools)

I would agree personally, to moving to ports (eg ports/sysutils) with
a DEPRECATED in the DESCR or something, or better yet a Make
invokation event to say "superceded, here is how to proceed against
advice") or something.

-G

On Thu, Jan 25, 2024 at 3:30 AM Warner Losh <imp@bsdimp.com> wrote:
>
> On Wed, Jan 24, 2024 at 8:45 AM Ed Maste <emaste@freebsd.org> wrote:
>>
>> MBR (PC BIOS) partition tables were historically maintained with
>> fdisk(8), but gpart(8) has long been the preferred method for working
>> with partition tables of all types. fdisk has been declared as
>> obsolete in the man page since 2015. Similarly BSD disklabels were
>> historically maintained with bsdlabel. It does not yet have a
>> deprecation notice - I have proposed a man page addition in
>> https://reviews.freebsd.org/D43563.
>>
>> I would like to disconnect these from the build, and subsequently
>> remove them. This is prompted by a recent bsdlabel bug report which
>> uncovered a longstanding buffer overflow in that tool. Effort is much
>> better focused on contemporary, maintained tools rather than
>> investigating issues in deprecated ones. Removing these tools would
>> happen in FreeBSD 15 only (no change in 14 or 13).
>>
>> Code review to disconnect fdisk: https://reviews.freebsd.org/D43575
>>
>> Note that this effort is limited to these maintenance tools only -
>> there is no change to kernel or gpart support for MBR or BSD
>> disklablel partitioning. That said, MBR partitioning and BSD
>> disklabels are best considered legacy formats and should be avoided
>> for new installations, if possible.
>>
>> If anyone is using fdisk and/or bsdlabel rather than gpart I would
>> appreciate knowing what is preventing you from using the contemporary
>> tools.
>
>
> nanobsd's legacy.sh still is using disklabel in two spots.
>
> But one is to just do gpart create -s bsd and the other is to display it. Easy
> to fix, but even easier to delete legacy.sh entirely. It's not really needed any
> more and was a product of CHS addressing... Now that we use LBA, it's
> better to use the new embedded ones. Even at $WORK where we kinda
> use legacy, we replace the partitioning stuff with our own custom thing...
>
> Those are the only users in the tree, but not for long :)
>
> fdisk was good, but somewhere around the CHS -> LBA transition things
> got weird with it, and for really big disks there were reports of issues that
> I could never encounter when I set out to fix them... Most likely due to a
> mismatch in the CHS data and the LBA data being recorded in the MBR.
> The in-kernel gpart copes so much better.
>
> I wouldn't object to making these ports, but both these programs use 'sekret'
> bits from the kernel that might not remain exposed as we clean things up.
> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> been so long that I've forgotten....
>
> Warner
>