> On 26. Jan 2024, at 18:02, Rodney W. Grimes <freebsd-...@gndrsh.dnsmgr.net>
> wrote:
>
> -- Start of PGP signed section.
>> Am 2024-01-25 18:49, schrieb Rodney W. Grimes:
>>>> On Thu, Jan 25, 2024, 9:11?AM Ed Maste <ema...@freebsd.org> wrote:
>>>>
>>>>> On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
>>>>> <freebsd-...@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:
>>> 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)
>>
>> What are you using cyl/hd/sec values for on a system which runs FreeBSD
>> current or on which you would have to use FreeBSD-current in case of a
>> repair need? What is the disk hardware on those systems that you still
>> need cyl/hd/sec and LBA doesn't work? Serious questions out of
>> curiosity.
>
> Your making way to many assuptions, I deal with all sorts of operating
> systems, not just FreeBSD, and I often many drives from many systems
> connected to a FreeBSD box doing work to repair various anomolyies.
> FreeBSD is my swiss army knife of choice for fixing things.
>
> UEFI CMS and BIOS emplemntations can get very confused about a
> disk if these values are not properly set. Also make a big
> mental note that GPT is really just a BIOS type 0x238 MBR
> entry and if that entry is messed up you are screwed. I am
> not sure gpart has anyway to fix the protective MBR other
> than to rewrite it, probably destroying access to the whole
> contents of the disk.
>
That does not make too much sense because PMBR is just fake partition covering
whole disk (within the data type size limit), with the hope that MBR only tool
will see all the space is allocated and will not attempt anything silly. Right
after sector 0, in sector 1 there is GPT, followed by GPT table array — that
is, if anything will attempt to write anything other into sectors 1-33 (or
depending on how large is your table array), you are in trouble as the primary
GPT is destroyed.
rgds,
toomas
> I am getting rather tired of hearing from people who just simply
> do not use these tools or can not phantom there are legitamate
> uses for them. But it is evident the project has decided to
> remote them to ports no matter what, so be it, yet another
> reason for me to use less FreeBSD and more of someone elses
> product.
>
>>
>> Bye,
>> Alexander.
>>
>> --
>> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
>> http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
> -- End of PGP section, PGP failed!
>
> --
> Rod Grimes rgri...@freebsd.org
>
