From nobody Fri Jan 26 16:40:24 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TM3N875H8z58Rhd for ; Fri, 26 Jan 2024 16:40:40 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TM3N83Lcbz4l5y for ; Fri, 26 Jan 2024 16:40:40 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1706287238; bh=XrB31BrOipHZa3qH4shizLWKt9uekIvsNLibZz88cKs=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=HBWTn8ZewQrplL482e+BbgBvgxPwJ4R1zIENn9Q+bLPCUKGGA4uQ4kMGurb3kFn/1 Z40iTX6Dwia7xbhdXMZ5h9EZu3LCF4zwjsJY2qcxOeeep8L0yYUVMUvBcCWfrB8xfi pcCtp5PnkeEONkhP7KGdaqDyejrH7FrCMCDQOaUPJ5DN0ZYNdaS9IznNpdx3IICkou kZafJJRlTbpOmpEsMlQnap7govST5tzbq+KYVdm+cBON8GO4QontQmfsAawo0XoLXv jHyrKuyV+7AqQnUimSg9xK4B+8iwbxVzvXT0hctAt7PKgz0PBGr9g0KvYtEfeb3Q8D o9ljDlspzbkmA== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id D4D2D740215; Fri, 26 Jan 2024 16:40:36 +0000 (UTC) From: Toomas Soome Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F0426EF8-7AD0-4641-9138-CFB20337145F" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) Date: Fri, 26 Jan 2024 18:40:24 +0200 In-Reply-To: <202401261621.40QGLIv7006285@gndrsh.dnsmgr.net> Cc: Alexander Leidinger , Warner Losh , Ed Maste , FreeBSD Current To: "Rodney W. Grimes" References: <202401261621.40QGLIv7006285@gndrsh.dnsmgr.net> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Proofpoint-ORIG-GUID: Q1H3WwW1LzSyIU4H-AldsjhE0TuM1aua X-Proofpoint-GUID: Q1H3WwW1LzSyIU4H-AldsjhE0TuM1aua X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-25_14,2024-01-25_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 malwarescore=0 spamscore=0 clxscore=1015 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2401260123 X-Rspamd-Queue-Id: 4TM3N83Lcbz4l5y X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] --Apple-Mail=_F0426EF8-7AD0-4641-9138-CFB20337145F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26. Jan 2024, at 18:21, Rodney W. Grimes = wrote: >=20 >>=20 >>=20 >>> On 26. Jan 2024, at 18:02, Rodney W. Grimes = wrote: >>>=20 >>> -- 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 = wrote: >>>>>>=20 >>>>>>> On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes >>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> These will need to be addressed before actually removing any = of these >>>>>>>>> binaries, of course. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> I haven't missed rescue, it is included in the work in progress = I >>>>>>> mentioned. Note that rescue has included gpart since 2007. >>>>>>>=20 >>>>>>=20 >>>>>> What can fdisk and/or disklabel repair that gpart can't? >>>>>=20 >>>>> 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 >>>>>=20 >>>>> gpart show ada0 >>>>> =3D> 63 8388545 ada0 MBR (4.0G) >>>>> 63 8388513 1 freebsd [active] (4.0G) >>>>> 8388576 32 - free - (16K) >>>>=20 >>>> What are you using cyl/hd/sec values for on a system which runs = FreeBSD=20 >>>> current or on which you would have to use FreeBSD-current in case = of a=20 >>>> repair need? What is the disk hardware on those systems that you = still=20 >>>> need cyl/hd/sec and LBA doesn't work? Serious questions out of=20 >>>> curiosity. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> 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. >=20 > *SIGH* Seriously if you think it is so fake NUKE it and see how good = your system works. >=20 > dd if=3D/dev/zero of=3D/dev/FOO count=3D1 > GOOD LUCK! >=20 It is fake in a sense that a) its role is to denote the marked space is = in use and b) in case of large disks, the PMBR end is not the same as = disk end (due to data type limit). It is entirely other matter what happens when PMBR is wiped. However, = even if you wipe it, it is trivial to restore. rgds, toomas >> 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. >>>=20 >>>>=20 >>>> Bye, >>>> Alexander. >>>>=20 >>>> --=20 >>>> http://www.Leidinger.net Alexander@Leidinger.net: PGP = 0x8F31830F9F2772BF >>>> http://www.FreeBSD.org netchild@FreeBSD.org : PGP = 0x8F31830F9F2772BF >>> -- End of PGP section, PGP failed! >>>=20 >>> --=20 >>> Rod Grimes = rgrimes@freebsd.org > --=20 > Rod Grimes = rgrimes@freebsd.org --Apple-Mail=_F0426EF8-7AD0-4641-9138-CFB20337145F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 26. Jan 2024, at 18:21, Rodney W. Grimes = <freebsd-rwg@gndrsh.dnsmgr.net> wrote:



On 26. Jan = 2024, at 18:02, Rodney W. Grimes <freebsd-rwg@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 <emaste@freebsd.org> = wrote:

On Thu, 25 Jan 2024 at 11:00, = Rodney W. Grimes
<freebsd-rwg@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
=3D> =     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=3D/dev/zero = of=3D/dev/FOO count=3D1
GOOD = LUCK!


It is fake in a sense that = a) its role is to denote the marked space is in use and b) in case of = large disks, the PMBR end is not the same as disk end (due to data type = limit).

It is entirely other matter what = happens when PMBR is wiped. However, even if you wipe it, it is trivial = to = restore.

rgds,
toomas

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 = Alexander@Leidinger.net: PGP = 0x8F31830F9F2772BF
http://www.FreeBSD.org =    netchild@FreeBSD.org  : PGP = 0x8F31830F9F2772BF
-- End of PGP section, PGP = failed!

-- 
Rod Grimes =             &n= bsp;           &nbs= p;            =            rgrimes@= freebsd.org
-- 
Rod Grimes =             &n= bsp;           &nbs= p;            =            <= a href=3D"mailto:rgrimes@freebsd.org" style=3D"font-family: = Hack-Regular; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: = 0px;">rgrimes@freebsd.org

= --Apple-Mail=_F0426EF8-7AD0-4641-9138-CFB20337145F--