> > > > 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.
*SIGH* Seriously if you think it is so fake NUKE it and see how good your system works. dd if=/dev/zero of=/dev/FOO count=1 GOOD LUCK! > 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 -- Rod Grimes rgri...@freebsd.org
