Date: Wed, 24 Jan 2024 21:07:36 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: George Michaelson <ggm@algebras.org>, Warner Losh <imp@bsdimp.com>, Ed Maste <emaste@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) Message-ID: <20240125050736.A11871AC@slippy.cwsent.com> In-Reply-To: <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net> References: <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240125050736.A11871AC>