Killing these would be excellent. I have not used either in many years for either MBR or GPT. The first time used gpart on an MBR disc, I realized that fdisk and bsdlabel, which I'd always found rather clunky, should die, but for years I kept seeing people claim that gpart was only for GPT and that fdisk/bsdlabel was the only way to do MBR. The name (gpt plus 2 letters) seemed to make this clear to some people. Hopefully this has pretty much passed.
I do want to open a bug report to fix up the documentation which fails to clarify the units of numeric arguments in gpart, though... bytes vs. blocks for the most part. On Wed, Jan 24, 2024 at 2:28 PM George Michaelson <g...@algebras.org> wrote: > 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 <i...@bsdimp.com> wrote: > > > > On Wed, Jan 24, 2024 at 8:45 AM Ed Maste <ema...@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 > > > > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
