From nobody Fri Jan 26 17:36:03 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 4TM4cL00BJz58WwD for ; Fri, 26 Jan 2024 17:36:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TM4cK5Sk3z4rsJ for ; Fri, 26 Jan 2024 17:36:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-55a86795a3bso408014a12.1 for ; Fri, 26 Jan 2024 09:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706290575; x=1706895375; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7vWNAouHV4DzhQwj2IFI2PIXGfZ56bKLR13AP7N4ml0=; b=VFS2PONCm7BdKB5y+w8SiciyyBK6YcMXw8oCdwC0WEZSzSgtecpHIIRAem4Pfrf1aP pSEeFbwiYbtC7OmEwiunfQFm3OEILsCapLLDW/siBCzm8IJnyZ/ta0cWt08tsjXJdxkB rzYntfmTJlVoFcVI16TtFu+j+OmBb9T+0UmjlAJtOUEYot/9DW3HhnJA12Iu3ZVjUlxR Bd1MtNAP/6iFWQNF7C4unQA+KE4ZqowyedHUvsxu0i9xmYviQvvr39pVJnTVn+FHmcMA 27SeXuH+JQndaifTih56eSQK7puiI/c6j78DThZx+HhLxCGjrJoMeyF8EZnnVsmTePBi YYCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706290575; x=1706895375; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7vWNAouHV4DzhQwj2IFI2PIXGfZ56bKLR13AP7N4ml0=; b=fSdyJOGRaYvEeLjnY+WmYweOqoJLRNrHluo0OgCqXSSeMsQZkKwmxXPLRtFoB+q/Eh ZyTa6JehIRn5F/HZgYAqAxqYSyTxpCBDEQSiliDM3NuBjf3k5hDtyH3I4Uj83UrKCBVn Ccze3Rvgkgw/A0sux53peX8w+Dr5ehihljuXJfC6/jo5oh+BAUxBNE43CgSOGa9DrXB3 e+m89L0Jpc4knZR1NGe/n5o/usFYP2d1ptU47Oxuj7664kX65fc+uYTKVB7x361nKM1F 8rx8lXM8UJvwe/+RV8DhDWw8QxsdsTyXLuZ9tH1Dq9gADi9C29qQe46+R6zJwkKv3Obv bsHA== X-Gm-Message-State: AOJu0YwcBG8NzsbPwYQAeJN7K2d8Vv38pU2CstNbQ3gRmMIjdkj+Ucn5 utD/Paub86YJ2vZvjCf++wYXqnkvxOYCavz0ZKiFM429JGSJhH6rOCEMTlv5YGWAplsD7BDAugX fxWzk65UzAp0dWgKJj+E9YFbiklxG3wCIuiKxSg0p9034jOxDFVE= X-Google-Smtp-Source: AGHT+IHPTkqG4B43h8CPqJQANZm/+4790ZHf5qGmr34wBW1S/eRo3KAbxydvCESbxXnFVMtmbr/yTgse2AvakGcxsX4= X-Received: by 2002:aa7:c3c9:0:b0:55d:344e:2cd0 with SMTP id l9-20020aa7c3c9000000b0055d344e2cd0mr2548edr.40.1706290574854; Fri, 26 Jan 2024 09:36:14 -0800 (PST) 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 References: <202401261602.40QG2Upe006210@gndrsh.dnsmgr.net> In-Reply-To: <202401261602.40QG2Upe006210@gndrsh.dnsmgr.net> From: Warner Losh Date: Fri, 26 Jan 2024 10:36:03 -0700 Message-ID: Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) To: "Rodney W. Grimes" Cc: Alexander Leidinger , Ed Maste , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000009925ad060fdcbbe8" X-Rspamd-Queue-Id: 4TM4cK5Sk3z4rsJ 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:15169, ipnet:2a00:1450::/32, country:US] --0000000000009925ad060fdcbbe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 26, 2024 at 9:02=E2=80=AFAM 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 wrote: > > >> > > >> > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes > > >> > wrote: > > >> > > > > >> > > > These will need to be addressed before actually removing any o= f > 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. > Then install the port and be done with it. > 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 might be a legitimate complaint. But you can still fix that with a port. Nothing stopping you from adding packages. And as pkgbase rolls into life for FreeBSD 15, these would be omitted by default anyway: they are too niche for today's needs to be in the already too large default bundle. > 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. > I'm saying that for most users gpart is sufficient. You have special needs that the project can no longer meet with in-tree tools, but provides an eas= y way to add them on by ports. None of your use cases require them to be available in /rescue or single-user scenarios. They are all adequately covered by a pkg install. Just like hundreds of other special use cases that need a pkg. Need to partition your MMC card, install mmc-util. Need to boot the NanoPi P2S card, install u-boot-nanopi-p2s. Etc. While cross BSD functionality is nice to have, the current tools don't even support tha= t very well (try to use a address sanitizer version of disklabel and discover the buffer overflows). So if it's important to you and maybe some others, you'll need to "pay the freight" of that functionality by making these port= s and having the community of users that needs this to work continue making them work as new bugs come to light. FreeBSD's fdisk and disklabel are flawed in a number of other ways. They most work cross platform, but aren't 100% what you want in all cases. You can't write big endian disk labels on a little endian machine, for example. The CHS handling in fdisk isn't quite right always for drives that are larger than 1023 cylinders: we round differently than at least 3.0ish Linux expects. disklabel has trouble writing to alternate locations that some BSD architectures need. Given that none of these problems have been fixed in the 20ish years that I've been at least dimly aware of them suggests tha= t there's not a huge demand for coping with these edge cases. Warner --0000000000009925ad060fdcbbe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 26, 2024 at 9:02=E2=80=AF= AM Rodney W. Grimes <fr= eebsd-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 actuall= y removing any of these
> >> > > > binaries, of course.
> >> > >
> >> > > You seem to have missed /rescue.=C2=A0 Now think ab= out that long
> >> > > and hard, these tools classified as so important th= at they
> >> > > are part of /rescue.=C2=A0 Again I can not stress e= nough 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 200= 7.
> >> >
> >>
> >> What can fdisk and/or disklabel repair that gpart can't?<= br> > >
> > 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)
> >=C2=A0 =C2=A0 =C2=A0start 63, size 8388513 (4095 Meg), flag 80 (ac= tive)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0beg: cyl 0/ head 1/ sector 1; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end: cyl 1023/ head 15/ sector 6= 3
> >
> > gpart show ada0
> > =3D>=C2=A0 =C2=A0 =C2=A063=C2=A0 8388545=C2=A0 ada0=C2=A0 MBR= =C2=A0 (4.0G)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 63=C2=A0 8388513=C2=A0 =C2=A0 =C2=A01= =C2=A0 freebsd=C2=A0 [active]=C2=A0 (4.0G)
> >=C2=A0 =C2=A08388576=C2=A0 =C2=A0 =C2=A0 =C2=A032=C2=A0 =C2=A0 =C2= =A0 =C2=A0 - free -=C2=A0 (16K)
>
> What are you using cyl/hd/sec values for on a system which runs FreeBS= D
> 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.

Then install the port and be done with it.
= =C2=A0
UEFI CMS and BIOS emplemntations can get very confused about a
disk if these values are not properly set.=C2=A0 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.=C2=A0 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 might be a l= egitimate complaint. But you can still fix that with
a port. Noth= ing stopping you from adding packages. And as pkgbase
rolls into = life for FreeBSD 15, these would be omitted by default
anyway: th= ey are too niche for today's needs to be in the already
too l= arge default bundle.
=C2=A0
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.=C2=A0 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.

I'm saying that for most u= sers gpart is sufficient. You have special needs
that the project= can no longer meet with in-tree tools, but provides an easy
way = to add them on by ports. None of your use cases require them to
b= e available in /rescue or single-user scenarios. They are all adequately
covered by a pkg install. Just like hundreds of other special use c= ases
that need a pkg. Need to partition your MMC card, install mm= c-util. Need
to boot the NanoPi P2S card, install u-boot-nanopi-p= 2s. Etc. While cross
BSD functionality is nice to have, the curre= nt tools don't even support that
very well (try to use a addr= ess sanitizer version of disklabel and discover
the buffer overfl= ows). So if it's important to you and maybe some others,
you&= #39;ll need to "pay the freight" of that functionality by making = these ports
and having the community of users that needs this to = work continue making
them work as new bugs come to light.

FreeBSD's fdisk and disklabel=C2=A0are flawed in a nu= mber of other ways.
They most work cross platform, but aren't= 100% what you want in all
cases. You can't write big endian = disk labels on a little endian machine,
for example. The CHS hand= ling in fdisk isn't quite right always for drives
that are la= rger than 1023 cylinders: we round differently than at least 3.0ish
Linux expects. disklabel has trouble writing to alternate locations that= some
BSD architectures need. Given that none of these problems h= ave been fixed
in the 20ish years that I've been at least dim= ly aware of them suggests that
there's not a huge demand for = coping with these edge cases.

Warner
--0000000000009925ad060fdcbbe8--