Re: Removing fdisk and bsdlabel (legacy partition tools)

On Wed, Jan 24, 2024, 10:07 PM Cy Schubert <Cy.Schubert@cschubert.com>
wrote:

> In message <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > 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.
> >
> > They are totally useless as ports when your booted from install
> > media and working from a standalone shell.  These are the exact
> > times you want things like fdisk and bsdlabel so you can figure
> > out wtf is going on, and bsdinstall is NOT gona help you.
>
> This is certainly a good point.
>

What can they do that gpart can't do?

Warner

>
> >
> > I know there are a boat load of people that have built there
> > own installers for VM's and stuff, running UFS and I bet you
> > they are using MBR disks too.  PLEASE do not kick these tiny
> > little and very usable and pretty univeral (as far as I know
> > ALL BSD's have fdisk and bsdlabel/disklabel) tools out of
> > the base system.
> >
> > The world is NOT 2TB nvme drives with GPT, EFI and ZFS,
> > yours might not be, but I am pretty certain I am not
> > alone in this other world.
> >
> > > -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 nee
> > ded 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
> 'sek
> > ret'
> > > > 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.or
> > g
> >
>
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
> NTP:           <cy@nwtime.org>    Web:  https://nwtime.org
>
>                         e^(i*pi)+1=0
>
>
>