From nobody Wed Jan 24 23:22:18 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 4TL0Nr6htyz58vky for ; Wed, 24 Jan 2024 23:22:36 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (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 4TL0Nr4pTLz4lHL; Wed, 24 Jan 2024 23:22:36 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5ff9adbf216so51932997b3.1; Wed, 24 Jan 2024 15:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706138555; x=1706743355; 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=daP/+n1mU9T10x6s5lEt382e+jfRqTS77PHNRQsjopY=; b=jdoFn6edc2fflQQ6wft0MlVXLkLDCEL/KB/gFufimB/bIsIHsV8D7h74vpGtkFacz2 6Ts/hJco6eMuYQnILmJNUP3O8xH5YR51k3n19d2k1OAiGGfCoWvizf68Y1JljA/Hv1/z eJzsNGMLTM510TIBzVTnMRTwRbrAwn04jxM5XnYYX8gEaOZYO01E8gXFwaA/7Qi8aABq nUYDO2FOmF1nxesWmkOT4m2amfxx5U5uapop9mQNUzNOcpwCgRCSLNA0kqValTnVK71+ m6gTUEt+nDGVo0YlE8H+eqKUBPxzK5u4s1GfiyvJg+6uCq1gMiZP6Ss/+QzlVKQD/g5J 9yWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706138555; x=1706743355; 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=daP/+n1mU9T10x6s5lEt382e+jfRqTS77PHNRQsjopY=; b=w/dt+70uqE0aFfsImr12+cT+ZwZN7UAA9/0atLaJvo6QM4h/Zqcjml2EymKMJ+B5HB eJyIciSoO7ELjXpEzmx9oOZn1hHP1G0azH8r+uReJzYrEEfB8cQUNx7PsHL1q/UzheaZ aqPelXD/M/uYZLpgsMTeQtE25RC6DQazAw53+BzDuakqGyGmj7tmBGh0LbThiojh20Sm Dz8n68XdUums/SGbyCMyb+TxyfAVW8CkNEy2fP3I+uejUuufqVqcTuxEpeB/Bo1G3f1l 92s33czZXfsk1AVi/GG5J0AgMvtML73656cLi4kLoKAhVeN1WYWUKnuQDFr1L0Bt2UKm 0htQ== X-Gm-Message-State: AOJu0Yz0doinRj6z1zURY9fygreXwcVXtWpEVXG4icuV/x8JZB7sFHFT MdvX/KPqrm7gKUxvg6pnMXz1TsrQnSm+6IMwWnDhc2+SQ9AbgXyl4y54tcsN3sB8EbKdL8xV2/s ++SSJQQSsBu2k/6jNMP/S5Fz82lw= X-Google-Smtp-Source: AGHT+IH0mAHCl+YYlZS0ilqO/o7XRNWgOotkjMQx41VL1uoWs61v+31sn9oMx2FNLVgKEpCicVqgg/IYYQOGG/G5+bg= X-Received: by 2002:a81:8305:0:b0:5ff:60b4:86e6 with SMTP id t5-20020a818305000000b005ff60b486e6mr1760050ywf.19.1706138555327; Wed, 24 Jan 2024 15:22:35 -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: In-Reply-To: From: Kevin Oberman Date: Wed, 24 Jan 2024 15:22:18 -0800 Message-ID: Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) To: George Michaelson Cc: Warner Losh , Ed Maste , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000872c64060fb95646" X-Rspamd-Queue-Id: 4TL0Nr4pTLz4lHL 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:2607:f8b0::/32, country:US] --000000000000872c64060fb95646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Killing these would be excellent. I have not used either in many years for either MBR or GPT. The first time used gpart on an MBR disc, I realized that fdisk and bsdlabel, which I'd always found rather clunky, should die, but for years I kept seeing people claim that gpart was only for GPT and that fdisk/bsdlabel was the only way to do MBR. The name (gpt plus 2 letters) seemed to make this clear to some people. Hopefully this has pretty much passed. I do want to open a bug report to fix up the documentation which fails to clarify the units of numeric arguments in gpart, though... bytes vs. blocks for the most part. On Wed, Jan 24, 2024 at 2:28=E2=80=AFPM George Michaelson wrote: > 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. > > -G > > On Thu, Jan 25, 2024 at 3:30=E2=80=AFAM Warner Losh wrot= e: > > > > On Wed, Jan 24, 2024 at 8:45=E2=80=AFAM Ed Maste w= rote: > >> > >> 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 which > >> 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 would > >> happen in FreeBSD 15 only (no change in 14 or 13). > >> > >> Code review to disconnect fdisk: https://reviews.freebsd.org/D43575 > >> > >> 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 avoided > >> 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 > needed 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 things > > got weird with it, and for really big disks there were reports of issue= s > that > > I could never encounter when I set out to fix them... Most likely due t= o > 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 > 'sekret' > > bits from the kernel that might not remain exposed as we clean things u= p. > > Though the IOCTLs they do (or used to do) may no longer be relevant. It= 's > > been so long that I've forgotten.... > > > > Warner > > > > --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000872c64060fb95646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Killing these would be excellent. I have not use= d either in many years for either MBR or GPT. The first time used gpart on = an MBR disc, I realized that fdisk and bsdlabel, which I'd always found= rather clunky, should die, but for years I kept seeing people claim that g= part was only for GPT and that fdisk/bsdlabel was the only way to do MBR. T= he name (gpt plus 2 letters) seemed to make this clear to some people. Hope= fully this has pretty much passed.

I do= want to open a bug report to fix up the documentation which fails to clari= fy the units of numeric arguments in gpart, though... bytes vs. blocks for = the most part.

On Wed, Jan 24, 2024 at 2:28=E2=80=AFPM George Mich= aelson <ggm@algebras.org> wro= te:
I would agre= e 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.

-G

On Thu, Jan 25, 2024 at 3:30=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:
>
> On Wed, Jan 24, 2024 at 8:45=E2=80=AFAM Ed Maste <emaste@freebsd.org> wrote: >>
>> MBR (PC BIOS) partition tables were historically maintained with >> fdisk(8), but gpart(8) has long been the preferred method for work= ing
>> 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<= br> >> remove them. This is prompted by a recent bsdlabel bug report whic= h
>> uncovered a longstanding buffer overflow in that tool. Effort is m= uch
>> 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/D43575
>>
>> 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 contempor= ary
>> 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 rea= lly needed any
> more and was a product of CHS addressing... Now that we use LBA, it= 9;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 thin= g...
>
> 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 issu= es 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 u= se 'sekret'
> 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. I= t's
> been so long that I've forgotten....
>
> Warner
>



--
Kevin= Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
--000000000000872c64060fb95646--