Re: Removing fdisk and bsdlabel (legacy partition tools)

> On Fri, Jan 26, 2024 at 9:17?AM Rodney W. Grimes <
> freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> > > freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> > >
> > > > > 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:
> > > >
> > >
> > > In the last 20 years when have you needed this?
> >
> > Last week, and probably about every other month for the last
> > 30 years.
> >
> 
> What. specifically did you need to change, for what hardware, etc?

I needed to manually recraft the MBR that had been destroyed,
and doing so with tools I knew would not touch anything but
the MBR.  I know that fdisk well do exactly what I tell it
to and without any fight about the values I put in.  I do
not have that confidence in GPT or any other tool, I suspect
if you tell gpart to write a GPT setup to what appears to
be an empty disk you shall end up with that, an empty
disk as it is going to clear out more than just the MBR/PMBR.

> > >
> > > LBA start/end is all that's relevant these days. The CHS values are
> > > completely ignored
> > > by FreeBSD. We use packet mode in the boot loader since about Pentium
> > 150MHz
> > > or so.
> >
> > WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
> > are ONLY using FreeBSD!!!!
> >
> 
> Yes. And the world stopped using them too around that time, give or take 5
> years.

That response doesnt even fit with the assertion.
Or are you saying the world stopped using other OS's?  As that
is about the only thing that seems to fit your assertion.
 
> > > I did have to change these back in the day when we inferred what the CHS
> > > geometry
> > > was from the drive by looking at the MBR's partitions that you knew
> > > (assumed really)
> > > started on a cylinder value. This hasn't mattered in FreeBSD since sos
> > > rewrote ata
> > > the second time. DOS had to do these things because old-school MFM, RLL,
> > etc
> > > disks couldn't return their CHS, so DOS had to enshrine them in the MBR
> > to
> > > get
> > > a hint (or have the drive type BIOS to just know). Since we use LBA
> > > exclusively,
> > > none of this matter to FreeBSD.
> >
> > WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
> > and UEFI are PROPBABLY reading those values and might even do a
> > nice divide by zero for you should you write 0 in them.
> >
> 
> Maybe rather than using all caps you could give a specific example. I've
> not had to help anybody with CHS values in maybe 15 years, and even
> then it was rare. In the prior 10 years to that I went from shipping product
> where CHS had to be right, to shipping product where it didn't matter at
> all on a set of SBCs that were lagging the industry by 5 years.

I have given specifics, you seem to read right pass them, and since
I already see commits falling in I am assuming at this point it has
zero point in confersing with what is a Brick wall.

> 
> Also, UEFI doesn't care: It has no CHS APIs. It's all LBA. The only places
> in the
> standard where 'Cylinder' is mentioned is the (now obsolete) name for
> fields in
> a ATA packet that now mean different parts of the LBA for modern commands.

You yet again seem to ignore what it was I said, UEFI/CSM != UEFI, and
there are many buggy CSM's that roach on zeros in the CHS area.
Your lack of experience with these problems does not mean they lack
to exist.

When board makers rip out CSM and BIOS mode booting you can make
your assertion, until then this stuff matters as a simple case of fact.

> > > I've certainly never needed to tweak these in single user mode on an
> > > emergency
> > > basis. Why? Because you can't get to single user mode because the kernel
> > > won't
> > > even load if you have these wrong. So either you are booting some rescue
> > > disk
> > > to fix that (in which case you can craft it for your special
> > environment).,
> > > or you are
> >
> > rescue disk == any FreeBSD install media from the last 20 years.
> > your REALLY stuck in a small box Warner, please think outside
> > that box.   You keep repeating FreeBSD FreeBSD FreeBSD, I have to
> > inform you many of us who USE FreeBSD also USE other stuff, but
> > we prefer to have FreeBSD be our goto system for this type of work.
> >
> 
> Yes. I understand that. And with the packages installed, you still can
> do that.

How many times
do you get that ports dont just "install" on a freebsd distirubtion
media.... or your chosing to ignore that side of my point.

And in many situation thats all I got to work with.  Not every
repair work gets to come back to a lab and have its hard drive
riped out to figure out something zorched the MBR/PMBR or GPT
tables.


> 
> 
> > > creating a special thing in multi-user, so you can install  For all these
> > > use cases, fdisk
> > > as a port is fine.
> >
> > I really do not want to have to maintain my own distribution.
> >
> 
> And the project can no longer support programs that have buffer overflows
> and other dangerous behavior when presented with untrusted information
> from the disks that matters only to a few users.

How does a moving the code to ports exactly address that?  Are
we really just gona sweep it away with that as the "solution"
to a buffer overflow?

> > > 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)
> > > >
> > > > Now I have learned that gpart backup/restore CAN get me
> > > > at least basic bsdlabel -e function, but again it has
> > > > no access to all the stuff stored that showsup with
> > > > bsdlabel -A.  Which this is now the third time I have
> > > > asked "how do I do bsdlabel -A -e with gpart"?  One
> > > > person at least answered that with:
> > > > gpart backup GEOM >backup
> > > > vi backup
> > > > gpart restore GEOM
> > > >
> > >
> > > OK Let's look at these extra fields:
> > >
> > > # /dev/md0:
> > > type: unknown
> > > disk: amnesiac
> > > label:
> > > flags:
> > > bytes/sector: 512
> > > sectors/track: 63
> > > tracks/cylinder: 255
> > > sectors/cylinder: 16065
> > > cylinders: 130
> > > sectors/unit: 2097152
> > > rpm: 3600
> > > interleave: 1
> > > trackskew: 0
> > > cylinderskew: 0
> > > headswitch: 0 # milliseconds
> > > track-to-track seek: 0 # milliseconds
> > > drivedata: 0
> > >
> > > type isn't used at all in FreeBSD.
> > > disk is for /etc/disktab, something we've not really needed since
> > FreeBSD 3
> > > or so.
> > > label can be set with gpart add/modify -l.
> > > I've never used flags. Can't speak to that.
> > > bytes/sector: This is a physical property of the drive, not the label.
> > You
> > > can find it with gpart list:
> > >    % gpart list md0
> > >    ....
> > >    Consumers:
> > >    1. Name: md0
> > >       Mediasize: 1073741824 (1.0G)
> > >       Sectorsize: 512
> > > The rest of this/that are reported or you can do math:
> > >     fwheads: 255 <- tracks/cylinder
> > >     fwsectors: 63 <-- sectors/track
> > >     last: 2097151 <-- sectors/unit - 1
> > > now, cylenders and sectors/cylinder you can compute. geom does this for
> > > reading/writing disk labels.
> > > rpm is hard coded to 3600 these days. FreeBSD doesn't care.
> > > The rest are for interleaving, which FreeBSD doesn't do, so we don't
> > care.
> > >
> > > So you can influence the values, but they aren't used for anything by
> > > FreeBSD
> > > that matters.
> > >
> > > What if you need them for something else? Then just use the disklabel
> > port.
> > > You'll never need to hack them tn single user mode, so you can use the
> > port
> > > for all use cases.
> >
> > Booting a FreeBSD install image is the use case, you seem to not
> > realize people do use that for "RESCUE".
> 
> 
> FreeBSD 14 CD images will exist online for ~forever.
> 
> Warner

-- 
Rod Grimes                                                 rgrimes@freebsd.org