Date: Wed, 24 Jan 2024 22:28:44 -0700 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, George Michaelson <ggm@algebras.org>, Ed Maste <emaste@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Removing fdisk and bsdlabel (legacy partition tools) Message-ID: <CANCZdfq%2BF1iFpUkDEYdcxPJfp96Ymz8KjBGaK_JNN1i09s7P=A@mail.gmail.com> In-Reply-To: <20240125050736.A11871AC@slippy.cwsent.com> References: <202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net> <20240125050736.A11871AC@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <Cy.Schubert@cschubert.c= om> 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 <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 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 <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > NTP: <cy@nwtime.org> Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > > --000000000000b0adc9060fbe7411 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Wed, Jan 24, 2024, 10:07=E2=80=AFPM Cy Schubert <= ;<a href=3D"mailto:Cy.Schubert@cschubert.com">Cy.Schubert@cschubert.com</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In message <<a href= =3D"mailto:202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net" target=3D"_blank"= rel=3D"noreferrer">202401242347.40ONlWKZ099356@gndrsh.dnsmgr.net</a>>, = "Rodney W. <br> Grimes"<br> writes:<br> > > I would agree personally, to moving to ports (eg ports/sysutils) = with<br> > > a DEPRECATED in the DESCR or something, or better yet a Make<br> > > invokation event to say "superceded, here is how to proceed = against<br> > > advice") or something.<br> ><br> > They are totally useless as ports when your booted from install<br> > media and working from a standalone shell.=C2=A0 These are the exact<b= r> > times you want things like fdisk and bsdlabel so you can figure<br> > out wtf is going on, and bsdinstall is NOT gona help you.<br> <br> This is certainly a good point.<br></blockquote></div></div><div dir=3D"aut= o"><br></div><div dir=3D"auto">What can they do that gpart can't do?</d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">Warner</div><div dir=3D"au= to"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> ><br> > I know there are a boat load of people that have built there<br> > own installers for VM's and stuff, running UFS and I bet you<br> > they are using MBR disks too.=C2=A0 PLEASE do not kick these tiny<br> > little and very usable and pretty univeral (as far as I know<br> > ALL BSD's have fdisk and bsdlabel/disklabel) tools out of<br> > the base system. <br> ><br> > The world is NOT 2TB nvme drives with GPT, EFI and ZFS,<br> > yours might not be, but I am pretty certain I am not<br> > alone in this other world.<br> ><br> > > -G<br> > > <br> > > On Thu, Jan 25, 2024 at 3:30?AM Warner Losh <<a href=3D"mailto= :imp@bsdimp.com" target=3D"_blank" rel=3D"noreferrer">imp@bsdimp.com</a>>= ; wrote:<br> > > ><br> > > > On Wed, Jan 24, 2024 at 8:45?AM Ed Maste <<a href=3D"mail= to:emaste@freebsd.org" target=3D"_blank" rel=3D"noreferrer">emaste@freebsd.= org</a>> wrote:<br> > > >><br> > > >> MBR (PC BIOS) partition tables were historically maintai= ned with<br> > > >> fdisk(8), but gpart(8) has long been the preferred metho= d for working<br> > > >> with partition tables of all types. fdisk has been decla= red as<br> > > >> obsolete in the man page since 2015. Similarly BSD diskl= abels were<br> > > >> historically maintained with bsdlabel. It does not yet h= ave a<br> > > >> deprecation notice - I have proposed a man page addition= in<br> > > >> <a href=3D"https://reviews.freebsd.org/D43563" rel=3D"no= referrer noreferrer" target=3D"_blank">https://reviews.freebsd.org/D43563</= a>.<br> > > >><br> > > >> I would like to disconnect these from the build, and sub= sequently<br> > > >> remove them. This is prompted by a recent bsdlabel bug r= eport which<br> > > >> uncovered a longstanding buffer overflow in that tool. E= ffort is much<br> > > >> better focused on contemporary, maintained tools rather = than<br> > > >> investigating issues in deprecated ones. Removing these = tools would<br> > > >> happen in FreeBSD 15 only (no change in 14 or 13).<br> > > >><br> > > >> Code review to disconnect fdisk: <a href=3D"https://revi= ews.freebsd.org/D43575" rel=3D"noreferrer noreferrer" target=3D"_blank">htt= ps://reviews.freebsd.org/D43575</a><br> > > >><br> > > >> Note that this effort is limited to these maintenance to= ols only -<br> > > >> there is no change to kernel or gpart support for MBR or= BSD<br> > > >> disklablel partitioning. That said, MBR partitioning and= BSD<br> > > >> disklabels are best considered legacy formats and should= be avoided<br> > > >> for new installations, if possible.<br> > > >><br> > > >> If anyone is using fdisk and/or bsdlabel rather than gpa= rt I would<br> > > >> appreciate knowing what is preventing you from using the= contemporary<br> > > >> tools.<br> > > ><br> > > ><br> > > > nanobsd's legacy.sh still is using disklabel in two spot= s.<br> > > ><br> > > > But one is to just do gpart create -s bsd and the other is t= o display it.<br> >=C2=A0 Easy<br> > > > to fix, but even easier to delete legacy.sh entirely. It'= ;s not really nee<br> > ded any<br> > > > more and was a product of CHS addressing... Now that we use = LBA, it's<br> > > > better to use the new embedded ones. Even at $WORK where we = kinda<br> > > > use legacy, we replace the partitioning stuff with our own c= ustom thing..<br> > .<br> > > ><br> > > > Those are the only users in the tree, but not for long :)<br= > > > ><br> > > > fdisk was good, but somewhere around the CHS -> LBA trans= ition things<br> > > > got weird with it, and for really big disks there were repor= ts of issues <br> > that<br> > > > I could never encounter when I set out to fix them... Most l= ikely due to <br> > a<br> > > > mismatch in the CHS data and the LBA data being recorded in = the MBR.<br> > > > The in-kernel gpart copes so much better.<br> > > ><br> > > > I wouldn't object to making these ports, but both these = programs use 'sek<br> > ret'<br> > > > bits from the kernel that might not remain exposed as we cle= an things up.<br> > > > Though the IOCTLs they do (or used to do) may no longer be r= elevant. It's<br> > > > been so long that I've forgotten....<br> > > ><br> > > > Warner<br> > -- <br> > 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<br> > g<br> ><br> <br> <br> -- <br> Cheers,<br> Cy Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com" target=3D"_bla= nk" rel=3D"noreferrer">Cy.Schubert@cschubert.com</a>><br> FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 <a href= =3D"https://FreeBSD.org" rel=3D"noreferrer noreferrer" target=3D"_blank">ht= tps://FreeBSD.org</a><br> NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:cy@nwtim= e.org" target=3D"_blank" rel=3D"noreferrer">cy@nwtime.org</a>>=C2=A0 =C2= =A0 Web:=C2=A0 <a href=3D"https://nwtime.org" rel=3D"noreferrer noreferrer"= target=3D"_blank">https://nwtime.org</a><br>; <br> =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<br> <br> <br> </blockquote></div></div></div> --000000000000b0adc9060fbe7411--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq%2BF1iFpUkDEYdcxPJfp96Ymz8KjBGaK_JNN1i09s7P=A>