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
