From nobody Thu Jan 25 05:28:44 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 4TL8WZ0w3nz57mYX for ; Thu, 25 Jan 2024 05:28:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4TL8WY60Nqz4ZXx for ; Thu, 25 Jan 2024 05:28:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-557dcb0f870so7718420a12.2 for ; Wed, 24 Jan 2024 21:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706160536; x=1706765336; 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=2EnfXe+X+FrIDLBweawqwTSslO0pKOQ0pLss9RQ40NA=; b=j7SIghHg/lyn4b8eGnpjLncdACHIEnjAKq9ImKh9vAzV7ML/wbB/ljObBB8+YTSgHs DLijr0XMH31bedrKNAIh5gZ3nboKvwPtO1bZ/9WC5vEpFQCt34TiqWA4+Cm0LavSG2Q7 oaW/wDXt9DTPUR6Lm+roTKYY68Sp9yggSNTVwBZgXjelai74TZYKHD+lmsOWmH78SlgJ 9fDLVFK+iODeaRGx8Ty0lROMo/8AdOoNbpk20tjWAAQ/9y1rZwH5SZhStdBivcx/IuJ4 jK5TmlHtWCU2DJG222/jkRgMbRx0hwoCDvhgBsBnfCoNffmxQ9e4JOKv0DmZ8F3Fep0D iHHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706160536; x=1706765336; 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=2EnfXe+X+FrIDLBweawqwTSslO0pKOQ0pLss9RQ40NA=; b=HhPmJCWiMsPlQQLynrmSdd+0Ts40CgpLdYRIpy6IAE8lIBl24IPEU65rYMUvtxLjpl MPwKtTwb1eicsOcdzTuDvnxWHgf+ZOen6GZvygTP4Cc4sX0/hP7glVP8VoOx57/9UJPu Pyqfy4PDcaQ30Db8pmQk7kM5COrRkY5baYiywRawTsaat7V1iN2HYt+4FkA06xlmZCyN l00ofa46DALlo1zp1NE1ZzFk0SamJ1T/bE7PJ4346bhtiC3d8Nrcwpy4A1GuftEWqqj9 q9LQFE3+jeDPUIY6ZjD/mCSY1EA9QxZhh2AhZWr0VzFhmURsJzBE6vwb7iRf9ExMvbt1 ticA== X-Gm-Message-State: AOJu0YxCCzU7UbWaV7AhowbaWl8pWwQTY/xr9w1pD/euh8JFzswzi3/n 48Yg50t4VS6BvbKb2jRfOx+KUTf2vJ90HaPewrCdWsgSWRHdDjlcERZjL8kYXwRL6OWEWKuN6YY T/ecYi82s7OhcqbWeDrjAcJ/3TXosPtS7BLuwZi0jlIlash92Tn4= X-Google-Smtp-Source: AGHT+IHqJor39+j5wgOsQn9oTeRYsVTJbFesVw7ZPB0n4KwRhb5slGnQBd8peOepdlvPXqg1e1MB+pzFDFmQe5R0EHw= X-Received: by 2002:a50:d598:0:b0:559:d75f:4902 with SMTP id v24-20020a50d598000000b00559d75f4902mr232350edi.74.1706160536197; Wed, 24 Jan 2024 21:28:56 -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: <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net> <20240125050736.A11871AC@slippy.cwsent.com> In-Reply-To: <20240125050736.A11871AC@slippy.cwsent.com> From: Warner Losh Date: Wed, 24 Jan 2024 22:28:44 -0700 Message-ID: Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) To: Cy Schubert Cc: "Rodney W. Grimes" , George Michaelson , Ed Maste , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000b0adc9060fbe7411" X-Rspamd-Queue-Id: 4TL8WY60Nqz4ZXx 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] --000000000000b0adc9060fbe7411 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2024, 10:07=E2=80=AFPM Cy Schubert wrote: > In message <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: > > > I would agree personally, to moving to ports (eg ports/sysutils) with > > > a DEPRECATED in the DESCR or something, or better yet a Make > > > invokation event to say "superceded, here is how to proceed against > > > advice") or something. > > > > They are totally useless as ports when your booted from install > > media and working from a standalone shell. These are the exact > > times you want things like fdisk and bsdlabel so you can figure > > out wtf is going on, and bsdinstall is NOT gona help you. > > This is certainly a good point. > What can they do that gpart can't do? Warner > > > > > I know there are a boat load of people that have built there > > own installers for VM's and stuff, running UFS and I bet you > > they are using MBR disks too. PLEASE do not kick these tiny > > little and very usable and pretty univeral (as far as I know > > ALL BSD's have fdisk and bsdlabel/disklabel) tools out of > > the base system. > > > > The world is NOT 2TB nvme drives with GPT, EFI and ZFS, > > yours might not be, but I am pretty certain I am not > > alone in this other world. > > > > > -G > > > > > > On Thu, Jan 25, 2024 at 3:30?AM Warner Losh wrote: > > > > > > > > On Wed, Jan 24, 2024 at 8:45?AM Ed Maste wrote= : > > > >> > > > >> MBR (PC BIOS) partition tables were historically maintained with > > > >> fdisk(8), but gpart(8) has long been the preferred method for > working > > > >> with partition tables of all types. fdisk has been declared as > > > >> obsolete in the man page since 2015. Similarly BSD disklabels were > > > >> historically maintained with bsdlabel. It does not yet have a > > > >> deprecation notice - I have proposed a man page addition in > > > >> https://reviews.freebsd.org/D43563. > > > >> > > > >> I would like to disconnect these from the build, and subsequently > > > >> remove them. This is prompted by a recent bsdlabel bug report whic= h > > > >> uncovered a longstanding buffer overflow in that tool. Effort is > much > > > >> better focused on contemporary, maintained tools rather than > > > >> investigating issues in deprecated ones. Removing these tools woul= d > > > >> happen in FreeBSD 15 only (no change in 14 or 13). > > > >> > > > >> Code review to disconnect fdisk: https://reviews.freebsd.org/D4357= 5 > > > >> > > > >> Note that this effort is limited to these maintenance tools only - > > > >> there is no change to kernel or gpart support for MBR or BSD > > > >> disklablel partitioning. That said, MBR partitioning and BSD > > > >> disklabels are best considered legacy formats and should be avoide= d > > > >> for new installations, if possible. > > > >> > > > >> If anyone is using fdisk and/or bsdlabel rather than gpart I would > > > >> appreciate knowing what is preventing you from using the > contemporary > > > >> tools. > > > > > > > > > > > > nanobsd's legacy.sh still is using disklabel in two spots. > > > > > > > > But one is to just do gpart create -s bsd and the other is to > display it. > > Easy > > > > to fix, but even easier to delete legacy.sh entirely. It's not > really nee > > ded any > > > > more and was a product of CHS addressing... Now that we use LBA, it= 's > > > > better to use the new embedded ones. Even at $WORK where we kinda > > > > use legacy, we replace the partitioning stuff with our own custom > thing.. > > . > > > > > > > > Those are the only users in the tree, but not for long :) > > > > > > > > fdisk was good, but somewhere around the CHS -> LBA transition thin= gs > > > > got weird with it, and for really big disks there were reports of > issues > > that > > > > I could never encounter when I set out to fix them... Most likely > due to > > a > > > > mismatch in the CHS data and the LBA data being recorded in the MBR= . > > > > The in-kernel gpart copes so much better. > > > > > > > > I wouldn't object to making these ports, but both these programs us= e > 'sek > > ret' > > > > bits from the kernel that might not remain exposed as we clean > things up. > > > > Though the IOCTLs they do (or used to do) may no longer be relevant= . > It's > > > > been so long that I've forgotten.... > > > > > > > > Warner > > -- > > Rod Grimes > rgrimes@freebsd.or > > g > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > > --000000000000b0adc9060fbe7411 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 24, 2024, 10:07=E2=80=AFPM Cy Schubert <= ;Cy.Schubert@cschubert.com= > wrote:
In message <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net>, = "Rodney W.
Grimes"
writes:
> > I would agree personally, to moving to ports (eg ports/sysutils) = with
> > a DEPRECATED in the DESCR or something, or better yet a Make
> > invokation event to say "superceded, here is how to proceed = against
> > advice") or something.
>
> They are totally useless as ports when your booted from install
> media and working from a standalone shell.=C2=A0 These are the exact > times you want things like fdisk and bsdlabel so you can figure
> out wtf is going on, and bsdinstall is NOT gona help you.

This is certainly a good point.

What can they do that gpart can't do?

Warner

>
> I know there are a boat load of people that have built there
> own installers for VM's and stuff, running UFS and I bet you
> they are using MBR disks too.=C2=A0 PLEASE do not kick these tiny
> little and very usable and pretty univeral (as far as I know
> ALL BSD's have fdisk and bsdlabel/disklabel) tools out of
> the base system.
>
> The world is NOT 2TB nvme drives with GPT, EFI and ZFS,
> yours might not be, but I am pretty certain I am not
> alone in this other world.
>
> > -G
> >
> > On Thu, Jan 25, 2024 at 3:30?AM Warner Losh <imp@bsdimp.com>= ; wrote:
> > >
> > > On Wed, Jan 24, 2024 at 8:45?AM Ed Maste <emaste@freebsd.= org> wrote:
> > >>
> > >> MBR (PC BIOS) partition tables were historically maintai= ned with
> > >> fdisk(8), but gpart(8) has long been the preferred metho= d for working
> > >> with partition tables of all types. fdisk has been decla= red as
> > >> obsolete in the man page since 2015. Similarly BSD diskl= abels were
> > >> historically maintained with bsdlabel. It does not yet h= ave a
> > >> deprecation notice - I have proposed a man page addition= in
> > >> https://reviews.freebsd.org/D43563.
> > >>
> > >> I would like to disconnect these from the build, and sub= sequently
> > >> remove them. This is prompted by a recent bsdlabel bug r= eport which
> > >> uncovered a longstanding buffer overflow in that tool. E= ffort is much
> > >> better focused on contemporary, maintained tools rather = than
> > >> investigating issues in deprecated ones. Removing these = tools would
> > >> happen in FreeBSD 15 only (no change in 14 or 13).
> > >>
> > >> Code review to disconnect fdisk: htt= ps://reviews.freebsd.org/D43575
> > >>
> > >> Note that this effort is limited to these maintenance to= ols only -
> > >> there is no change to kernel or gpart support for MBR or= BSD
> > >> disklablel partitioning. That said, MBR partitioning and= BSD
> > >> disklabels are best considered legacy formats and should= be avoided
> > >> for new installations, if possible.
> > >>
> > >> If anyone is using fdisk and/or bsdlabel rather than gpa= rt I would
> > >> appreciate knowing what is preventing you from using the= contemporary
> > >> tools.
> > >
> > >
> > > nanobsd's legacy.sh still is using disklabel in two spot= s.
> > >
> > > But one is to just do gpart create -s bsd and the other is t= o display it.
>=C2=A0 Easy
> > > to fix, but even easier to delete legacy.sh entirely. It'= ;s not really nee
> ded any
> > > more and was a product of CHS addressing... Now that we use = LBA, it's
> > > better to use the new embedded ones. Even at $WORK where we = kinda
> > > use legacy, we replace the partitioning stuff with our own c= ustom thing..
> .
> > >
> > > Those are the only users in the tree, but not for long :) > > >
> > > fdisk was good, but somewhere around the CHS -> LBA trans= ition things
> > > got weird with it, and for really big disks there were repor= ts of issues
> that
> > > I could never encounter when I set out to fix them... Most l= ikely due to
> a
> > > mismatch in the CHS data and the LBA data being recorded in = the MBR.
> > > The in-kernel gpart copes so much better.
> > >
> > > I wouldn't object to making these ports, but both these = programs use 'sek
> ret'
> > > bits from the kernel that might not remain exposed as we cle= an things up.
> > > Though the IOCTLs they do (or used to do) may no longer be r= elevant. It's
> > > been so long that I've forgotten....
> > >
> > > Warner
> --
> Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.or
> g
>


--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 ht= tps://FreeBSD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2= =A0 Web:=C2=A0 https://nwtime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0


--000000000000b0adc9060fbe7411--