Re: Removing fdisk and bsdlabel (legacy partition tools)

On Fri, Jan 26, 2024 at 9:02 AM Rodney W. Grimes <
freebsd-rwg@gndrsh.dnsmgr.net> wrote:

> -- Start of PGP signed section.
> > Am 2024-01-25 18:49, schrieb Rodney W. Grimes:
> > >> On Thu, Jan 25, 2024, 9:11?AM Ed Maste <emaste@freebsd.org> wrote:
> > >>
> > >> > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> > >> > <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> > >> > >
> > >> > > > These will need to be addressed before actually removing any of
> these
> > >> > > > binaries, of course.
> > >> > >
> > >> > > You seem to have missed /rescue.  Now think about that long
> > >> > > and hard, these tools classified as so important that they
> > >> > > are part of /rescue.  Again I can not stress enough how often
> > >> > > I turn to these tools in a repair mode situation.
> > >> >
> > >> > I haven't missed rescue, it is included in the work in progress I
> > >> > mentioned. Note that rescue has included gpart since 2007.
> > >> >
> > >>
> > >> What can fdisk and/or disklabel repair that gpart can't?
> > >
> > > As far as I know there is no way in gpart to get to the
> > > MBR cyl/hd/sec values, you can only get to the LBA start
> > > and end values:
> > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> > >     start 63, size 8388513 (4095 Meg), flag 80 (active)
> > >         beg: cyl 0/ head 1/ sector 1;
> > >         end: cyl 1023/ head 15/ sector 63
> > >
> > > gpart show ada0
> > > =>     63  8388545  ada0  MBR  (4.0G)
> > >        63  8388513     1  freebsd  [active]  (4.0G)
> > >   8388576       32        - free -  (16K)
> >
> > What are you using cyl/hd/sec values for on a system which runs FreeBSD
> > current or on which you would have to use FreeBSD-current in case of a
> > repair need? What is the disk hardware on those systems that you still
> > need cyl/hd/sec and LBA doesn't work? Serious questions out of
> > curiosity.
>
> Your making way to many assuptions, I deal with all sorts of operating
> systems, not just FreeBSD, and I often many drives from many systems
> connected to a FreeBSD box doing work to repair various anomolyies.
> FreeBSD is my swiss army knife of choice for fixing things.
>

Then install the port and be done with it.


> UEFI CMS and BIOS emplemntations can get very confused about a
> disk if these values are not properly set.  Also make a big
> mental note that GPT is really just a BIOS type 0x238 MBR
> entry and if that entry is messed up you are screwed.  I am
> not sure gpart has anyway to fix the protective MBR other
> than to rewrite it, probably destroying access to the whole
> contents of the disk.
>

That might be a legitimate complaint. But you can still fix that with
a port. Nothing stopping you from adding packages. And as pkgbase
rolls into life for FreeBSD 15, these would be omitted by default
anyway: they are too niche for today's needs to be in the already
too large default bundle.


> I am getting rather tired of hearing from people who just simply
> do not use these tools or can not phantom there are legitamate
> uses for them.  But it is evident the project has decided to
> remote them to ports no matter what, so be it, yet another
> reason for me to use less FreeBSD and more of someone elses
> product.
>

I'm saying that for most users gpart is sufficient. You have special needs
that the project can no longer meet with in-tree tools, but provides an easy
way to add them on by ports. None of your use cases require them to
be available in /rescue or single-user scenarios. They are all adequately
covered by a pkg install. Just like hundreds of other special use cases
that need a pkg. Need to partition your MMC card, install mmc-util. Need
to boot the NanoPi P2S card, install u-boot-nanopi-p2s. Etc. While cross
BSD functionality is nice to have, the current tools don't even support that
very well (try to use a address sanitizer version of disklabel and discover
the buffer overflows). So if it's important to you and maybe some others,
you'll need to "pay the freight" of that functionality by making these ports
and having the community of users that needs this to work continue making
them work as new bugs come to light.

FreeBSD's fdisk and disklabel are flawed in a number of other ways.
They most work cross platform, but aren't 100% what you want in all
cases. You can't write big endian disk labels on a little endian machine,
for example. The CHS handling in fdisk isn't quite right always for drives
that are larger than 1023 cylinders: we round differently than at least
3.0ish
Linux expects. disklabel has trouble writing to alternate locations that
some
BSD architectures need. Given that none of these problems have been fixed
in the 20ish years that I've been at least dimly aware of them suggests that
there's not a huge demand for coping with these edge cases.

Warner