Re: Removing fdisk and bsdlabel (legacy partition tools)

> Am 26.01.24 um 17:09 schrieb Rodney W. Grimes:
> >> Am 25.01.24 um 16:38 schrieb Ed Maste:
> >>> On Wed, 24 Jan 2024 at 12:30, Warner Losh <imp@bsdimp.com> wrote:
> >>> sbin/growfs/tests/legacy_test.pl
> >>> tools/regression/msdosfs/msdosfstest-2.sh
> >>> tools/regression/tmpfs/t_vnd
> >>> tools/tools/nanobsd/legacy.sh
> 
> All these scripts that currently depend on bsdlabel could
> easily be converted to exclusively use gpart instead.
> 
> Other scripts that had been identified to use bsdlabel or
> disklabel are unused / not relevant for FreeBSD.
> 
> [...]
> >> The bsdlabel/disklabel/fdisk programs could be rewritten using
> >> gpart without too much effort, at least for the use cases that
> 
> After looking at the source code it appears that there is
> no need to rewrite any of the bsdlabel/disklabel code, since
> it already uses geom calls to access the partition data and
> only uses direct disk writes to write out the partition table
> (as does gpart, AFAICT).
> 
> So, I do not see any dependencies on deprecated kernel features.
> 
> I have not compared the bsdlabel code and gpart_write_partcode()
> in detail, but I do not see much of a difference at first glance.
> 
> Therefore, bsdlabel and disklabel could be kept in the base
> system, IMHO. (But fdisk should go ...)

I still have not seen anything compelling that says fdisk
must go, other than someone says there is a PR and I am
not sure how a bug fix effects the position of fdisk in
or out of base as the bug needs fixed regardless.

> 
> > That would be wonderful.  Even just getting it to spit out
> > the FULL MBR values that are in a protective 0x238 MBR
> > would go along way to diagnose some corrupt GPT disks.
> 
> If you need access to the protective MBR of a GPT partition,
> this feature should be added to gpart instead, IMHO.

I am fine with that too, probalby 99% of my use case
is just a sanity check that the MBR/PMBR is not messed
up, but that 1% case when it is one needs a way to
deal with it very carefully.
> 
> But what's wrong with using "file -s" for this purpose:
> 
> # file -s /dev/nda0
> /dev/nda0: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), 
                                                                     ^sic
> end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition 
            ^sic
> table (last)

Other than the sick mixing of hex and decimal output I suppose that
does infact get the :reading: of the MBR/PMBR to validate
there isnt an issue.  Its the repair work when those values are
nonsince I do not seeing file(1) fixing.

> 
> Do you need more information from the protective MBR?

I think that is all the information, same as output
by fdisk, just in a different and very hard to read
format.
> 
> This will not work on mounted file systems, though. But if
> you got the disk mounted, I'd expect you do not really need
> this information ...

Correct
> 
> >> have not become obsolete (e.g. CHS specifications) and only for
> >> use in scripts (i.e. no fdisk interactive edit mode).
> > 
> > You are fooling yourself if you think an MBR and CHS values
> > are obsolete.  GPT *IS* a type 0x238 MBR and see how many
> > BIOSes you can crash by writting garbage (Especially 0x0)
> > to the CHS values.  That MBR must have proper values, and
> > you cant just ignore that they exist.
> 
> Again something that gpart should be able to diagnose and fix.
> 
> Doesn't "gpart recover" already fix such protective MBRs?

I do not know for certain, but I think mainly "gpart recover"
is about fixing the 2 copies of the GPT to be consistant, can
it actually reconstuct a toasted PMBR?  It would be making
assumptions so I would expect to have to use some options
to force it to do this.

> >> Even parsing of the disktab format and a conversion to gpart
> >> backup format for use by gpart restore should not be too hard.
> >>
> >> That would keep the commands available for those that use them
> >> in scripts outside the FreeBSD sources, but would also allow to
> >> remove the kernel interfaces used by those legacy tools.
> >>
> >> I'd be willing to write those emulations of legacy tools, if
> >> there is interest in going that way ...
> > 
> > I would be interested in seeing these.
> > For me gpart does do a lot of things, but it is missing
> > some very low level stuff that is probably should have.
> 
> I read that to mean that gpart is useful for standard setup
> operations, but it lacks commands that might be useful to
> diagnose inconsistent parameters?

Yes, like a disk with a zapped PMBR just shows up as
empty, nothing, fully ready to let gpart slice and
dice it up until you realize.. uh oh, that wasnt
the drive I thought it was....

> 
> Well, adding consistency checks and warning about potential
> issues might not have been on the requirements sheet, but if
> you specify checks that should be performed, these could be
> added either to "gpart show" or a "gaprt check" command could
> be implemented.

I think geom layer already does the checks, and if you fail
the checks you get a nice "empty" drive.

"gpart check" could be interesting.

> If you want such consistency checks added, then specify them
> in a feature request PR, for example.

> Best regards, STefan
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org