Re: Removing fdisk and bsdlabel (legacy partition tools)
- In reply to: Rodney W. Grimes: "Re: Removing fdisk and bsdlabel (legacy partition tools)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 24 Jan 2024 20:50:58 UTC
On 24/01/2024 19:50, Rodney W. Grimes 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. > > 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 have many FreeBSD installations running in a UFS-based VM, created using bsdinstall or manually using gpart. I haven't touched fdisk and bsdlabel in at least a decade. >>> 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. I was curious what this command does that is so special, but it seems to be of no use anymore: % bsdlabel -A /dev/ada0 bsdlabel: disks with more than 2^32-1 sectors are not supported Do we really need a tool that can't handle disks of average size (in this case 4TB)? Kind regards Miroslav Lachman