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

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

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), 
end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition 
table (last)

Do you need more information from the protective MBR?

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

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

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

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.

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

Best regards, STefan