Re: Removing fdisk and bsdlabel (legacy partition tools)

[ 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.

> 
> 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!!!!
> 
> 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.

> 
> 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.

> 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.

> 
> 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".

> Warner
> 
> 
> > Warner
> > --
> > Rod Grimes
> > rgrimes@freebsd.org
> >

-- 
Rod Grimes                                                 rgrimes@freebsd.org