Re: Removing fdisk and bsdlabel (legacy partition tools)

> 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.

man page additions are not going to reach the people who may be
using this.  This should be a gonein(15) added to the binary.
I also suspect that all of the people doing ufs installs
are doing so via bsdlabel, not gpart.

> >
> > 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

How can you do bsdlabel -A -e /dev/foo with gpart?  As far as I know
that functionality never made it to gpart, neither the -A or -e.

> >
> > 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.

My prototype files that are read by bsdlabel -R as far as I know
can not be processed by gpart.
fdisk I can probably get away from, but thats a working binary
accross a lot of platforms which do not have gpart.

> >
> 
> 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

-- 
Rod Grimes                                                 rgrimes@freebsd.org