> 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 <i...@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 rgri...@freebsd.org
