Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

I'll add it to the gsoc list, unless someone submits a pull request to make
it so in the mean time :)

Warner

On Sun, Jan 28, 2024 at 11:29 AM Tomek CEDRO  wrote:

> Yes! Installer is always used in emergency it would be great to provide
> some servicing tools there too :-)
>
> For years I was using bootable Linux to fix people computers and it would
> be nice to have that in FreeBSD :-)
>
> +1 for memstick full with additional service utilities (fix partitions,
> mount fs, undelete, ntfs support, etc) :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Tomek CEDRO]

Yes! Installer is always used in emergency it would be great to provide
some servicing tools there too :-)

For years I was using bootable Linux to fix people computers and it would
be nice to have that in FreeBSD :-)

+1 for memstick full with additional service utilities (fix partitions,
mount fs, undelete, ntfs support, etc) :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Tomoaki AOKI]

On Sat, 27 Jan 2024 21:52:06 -0700
Warner Losh  wrote:

> On Sat, Jan 27, 2024, 1:26 PM Cy Schubert  wrote:
> 
> > On January 26, 2024 7:13:15 PM PST, Ed Maste  wrote:
> > >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey  wrote:
> > >>
> > >> Probably many do, clueless there's a proposal to remove them,
> > >> as many wont be tracking lists (I havent been tracking lately,
> > >> focused on moving home, other will have other distractions)
> > >
> > >As Rod suggested I'll have the tools emit a warning when they are run,
> > >so that those users will become aware.
> > >https://reviews.freebsd.org/D43585
> > >https://reviews.freebsd.org/D43586
> > >
> >
> > We can also point people to the two new ports.
> >
> 
> The other thing we learned was that people use the installer to do
> interesting things in the emergency holographic shell or the installer w/o
> installing a system. We should look at ways we can shift to "mfs" so pkg
> add can work in that env. Then the basis of the objections collapse. Then
> it won't matter it isn't in base. Pkg add whatever recovery tools you think
> you need or like to use, formerly in base or no... sure, it will go away...
> but 99% of things are useful right away w/o a reboot...
> 
> I don't think it would be a hard project... likely one that could be done
> by creating a miniroot that can create the mfs, extract a tarnall to it
> then pivot root to that pkg could be bootsrrapped and it would be easy
> from there...
> 
> Warner

IIUC, there were opinions that "moving fidsk/bsdlabel to ports is not
good, because it could require internet access even when it is not
available".

For there, IIRC, dvd1.iso included pre-built pkgs. So it coul be the
best candidate.

But IIRC, memstick.img doesn't include pre-built pkgs. Having another
version of memstick.img something like full-memstick.img which contains
full sets (or selected pkgs) would be nice for specific cases that
hybrid media doesn't boot (maybe because of broken or too old BIOS).


> -- 
> > Cheers,
> > Cy Schubert 
> > FreeBSD UNIX:Web:  https://FreeBSD.org
> > NTP: Web:  https://nwtime.org
> > e^(i*pi)+1=0
> >
> > Pardon the typos. Small keyboard in use.


-- 
Tomoaki AOKI

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Sat, Jan 27, 2024, 1:26 PM Cy Schubert  wrote:

> On January 26, 2024 7:13:15 PM PST, Ed Maste  wrote:
> >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey  wrote:
> >>
> >> Probably many do, clueless there's a proposal to remove them,
> >> as many wont be tracking lists (I havent been tracking lately,
> >> focused on moving home, other will have other distractions)
> >
> >As Rod suggested I'll have the tools emit a warning when they are run,
> >so that those users will become aware.
> >https://reviews.freebsd.org/D43585
> >https://reviews.freebsd.org/D43586
> >
>
> We can also point people to the two new ports.
>

The other thing we learned was that people use the installer to do
interesting things in the emergency holographic shell or the installer w/o
installing a system. We should look at ways we can shift to "mfs" so pkg
add can work in that env. Then the basis of the objections collapse. Then
it won't matter it isn't in base. Pkg add whatever recovery tools you think
you need or like to use, formerly in base or no... sure, it will go away...
but 99% of things are useful right away w/o a reboot...

I don't think it would be a hard project... likely one that could be done
by creating a miniroot that can create the mfs, extract a tarnall to it
then pivot root to that pkg could be bootsrrapped and it would be easy
from there...

Warner


-- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX:Web:  https://FreeBSD.org
> NTP: Web:  https://nwtime.org
> e^(i*pi)+1=0
>
> Pardon the typos. Small keyboard in use.
>
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

On January 26, 2024 7:13:15 PM PST, Ed Maste  wrote:
>On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey  wrote:
>>
>> Probably many do, clueless there's a proposal to remove them,
>> as many wont be tracking lists (I havent been tracking lately,
>> focused on moving home, other will have other distractions)
>
>As Rod suggested I'll have the tools emit a warning when they are run,
>so that those users will become aware.
>https://reviews.freebsd.org/D43585
>https://reviews.freebsd.org/D43586
>

We can also point people to the two new ports.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:Web:  https://FreeBSD.org
NTP: Web:  https://nwtime.org
e^(i*pi)+1=0

Pardon the typos. Small keyboard in use.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

On Fri, 26 Jan 2024 at 16:10, Rodney W. Grimes
 wrote:
>
> You yet again seem to ignore what it was I said, UEFI/CSM != UEFI, and
> there are many buggy CSM's that roach on zeros in the CHS area.

I'm not sure what "zeros in the CHS area" is referring to -- gpart
writes values in the CHS fields, regardless of whether you're creating
a plain MBR or a PMBR for GPT.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey  wrote:
>
> Probably many do, clueless there's a proposal to remove them,
> as many wont be tracking lists (I havent been tracking lately,
> focused on moving home, other will have other distractions)

As Rod suggested I'll have the tools emit a warning when they are run,
so that those users will become aware.
https://reviews.freebsd.org/D43585
https://reviews.freebsd.org/D43586

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Sulev-Madis Silber]

add variation of this to stock image to get better rescue media. maybe 
installer could even be updated a bit. if that is really big issue. cons is 
that this requires network to be present. but where to get packages from anyway 
without it, perhaps dvd1. i actually find it confusing that highly technically 
skilled people who clearly run non-standard hw of various archs and with 
several oses, for work or hobby, argue how installer sucks. you can patch it. 
then you can use it locally or submit it to fbsd. i don't know, maybe i'll do 
it then?

--- cut ---
#!/bin/sh -Cefu


set -Cefu


kbdcontrol -r fast -l ee

test -d /tmp/unionfs/etc || mkdir -p /tmp/unionfs/etc

mount -t unionfs | fgrep -q /etc || mount_unionfs /tmp/unionfs/etc /etc

test -d /tmp/unionfs/root || mkdir -p /tmp/unionfs/root

mount -t unionfs | fgrep -q /root || mount_unionfs /tmp/unionfs/root /root

test -f /etc/wall_cmos_clock || touch /etc/wall_cmos_clock

test -f /etc/localtime || tzsetup Europe/Tallinn

pgrep -q adjkerntz || service adjkerntz start

ifconfig -a -G lo | grep '^[a-z0-9]' | cut -d : -f 1 | xargs -n 1 sh -c \
'echo ; service dhclient status "$0" || service dhclient forcestart "$0"'

test -f /tmp/ntpdate_run_done \
|| ( echo ; ntpdate dome && touch /tmp/ntpdate_run_done )

echo

service ntpd onestatus || service ntpd onestart

echo

test -f /tmp/ntpdate_run_done && ntpdate -q dome

echo

date

echo

test -f /boot/kernel/coretemp.ko && kldload -n coretemp

test -f /boot/kernel/amdtemp.ko && kldload -n amdtemp

sysctl -a | grep '[0-9]C$' | egrep -v '(_(CRT|PSV)|\.tjmax)'

sysctl -a | fgrep -q battery \
&& ( echo ; acpiconf -i 0 | grep -v ':[[:space:]]*$')

echo

--- cut ---

On 26 January 2024 22:11:44 EET, Freddie Cash  wrote:
>Sounds like a custom mfsBSD or Frenzy CD/USB would be better suited to
>these bare-metal rescue setups.  Something that has the specific tools you
>need already installed.  I know I've kept various versions of these CD
>images around for just this purpose.  I always found them nicer to use than
>the FreeBSD install CDs in rescue mode, as there's a fully-functional
>FreeBSD install to work from, including the ability to install packages
>temporarily.
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> Am 26.01.24 um 17:09 schrieb Rodney W. Grimes:
> >> Am 25.01.24 um 16:38 schrieb Ed Maste:
> >>> On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
> >>> sbin/growfs/tests/legacy_test.pl
> >>> tools/regression/msdosfs/msdosfstest-2.sh
> >>> tools/regression/tmpfs/t_vnd
> >>> tools/tools/nanobsd/legacy.sh
> 
> All these scripts that currently depend on bsdlabel could
> easily be converted to exclusively use gpart instead.
> 
> Other scripts that had been identified to use bsdlabel or
> disklabel are unused / not relevant for FreeBSD.
> 
> [...]
> >> The bsdlabel/disklabel/fdisk programs could be rewritten using
> >> gpart without too much effort, at least for the use cases that
> 
> After looking at the source code it appears that there is
> no need to rewrite any of the bsdlabel/disklabel code, since
> it already uses geom calls to access the partition data and
> only uses direct disk writes to write out the partition table
> (as does gpart, AFAICT).
> 
> So, I do not see any dependencies on deprecated kernel features.
> 
> I have not compared the bsdlabel code and gpart_write_partcode()
> in detail, but I do not see much of a difference at first glance.
> 
> Therefore, bsdlabel and disklabel could be kept in the base
> system, IMHO. (But fdisk should go ...)

I still have not seen anything compelling that says fdisk
must go, other than someone says there is a PR and I am
not sure how a bug fix effects the position of fdisk in
or out of base as the bug needs fixed regardless.

> 
> > That would be wonderful.  Even just getting it to spit out
> > the FULL MBR values that are in a protective 0x238 MBR
> > would go along way to diagnose some corrupt GPT disks.
> 
> If you need access to the protective MBR of a GPT partition,
> this feature should be added to gpart instead, IMHO.

I am fine with that too, probalby 99% of my use case
is just a sanity check that the MBR/PMBR is not messed
up, but that 1% case when it is one needs a way to
deal with it very carefully.
> 
> But what's wrong with using "file -s" for this purpose:
> 
> # file -s /dev/nda0
> /dev/nda0: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), 
 ^sic
> end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition 
^sic
> table (last)

Other than the sick mixing of hex and decimal output I suppose that
does infact get the :reading: of the MBR/PMBR to validate
there isnt an issue.  Its the repair work when those values are
nonsince I do not seeing file(1) fixing.

> 
> Do you need more information from the protective MBR?

I think that is all the information, same as output
by fdisk, just in a different and very hard to read
format.
> 
> This will not work on mounted file systems, though. But if
> you got the disk mounted, I'd expect you do not really need
> this information ...

Correct
> 
> >> have not become obsolete (e.g. CHS specifications) and only for
> >> use in scripts (i.e. no fdisk interactive edit mode).
> > 
> > You are fooling yourself if you think an MBR and CHS values
> > are obsolete.  GPT *IS* a type 0x238 MBR and see how many
> > BIOSes you can crash by writting garbage (Especially 0x0)
> > to the CHS values.  That MBR must have proper values, and
> > you cant just ignore that they exist.
> 
> Again something that gpart should be able to diagnose and fix.
> 
> Doesn't "gpart recover" already fix such protective MBRs?

I do not know for certain, but I think mainly "gpart recover"
is about fixing the 2 copies of the GPT to be consistant, can
it actually reconstuct a toasted PMBR?  It would be making
assumptions so I would expect to have to use some options
to force it to do this.

> >> Even parsing of the disktab format and a conversion to gpart
> >> backup format for use by gpart restore should not be too hard.
> >>
> >> That would keep the commands available for those that use them
> >> in scripts outside the FreeBSD sources, but would also allow to
> >> remove the kernel interfaces used by those legacy tools.
> >>
> >> I'd be willing to write those emulations of legacy tools, if
> >> there is interest in going that way ...
> > 
> > I would be interested in seeing these.
> > For me gpart does do a lot of things, but it is missing
> > some very low level stuff that is probably should have.
> 
> I read that to mean that gpart is useful for standard setup
> operations, but it lacks commands that might be useful to
> diagnose inconsistent parameters?

Yes, like a disk with a zapped PMBR just shows up as
empty, nothing, fully ready to let gpart slice and
dice it up until you realize.. uh oh, that wasnt
the drive I thought it was

> 
> Well, adding consistency checks and warning about potential
> issues might not have been on the requirements sheet, but if
> you specify checks that should be performed, these could be
> added either to "gpart show" or a "gaprt check" command could
> be implemented.

I think geom layer 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> On Fri, Jan 26, 2024 at 9:17?AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> > > freebsd-...@gndrsh.dnsmgr.net> wrote:
> > >
> > > > > 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 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:
> > > >
> > >
> > > In the last 20 years when have you needed this?
> >
> > Last week, and probably about every other month for the last
> > 30 years.
> >
> 
> What. specifically did you need to change, for what hardware, etc?

I needed to manually recraft the MBR that had been destroyed,
and doing so with tools I knew would not touch anything but
the MBR.  I know that fdisk well do exactly what I tell it
to and without any fight about the values I put in.  I do
not have that confidence in GPT or any other tool, I suspect
if you tell gpart to write a GPT setup to what appears to
be an empty disk you shall end up with that, an empty
disk as it is going to clear out more than just the MBR/PMBR.

> > >
> > > LBA start/end is all that's relevant these days. The CHS values are
> > > completely ignored
> > > by FreeBSD. We use packet mode in the boot loader since about Pentium
> > 150MHz
> > > or so.
> >
> > WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
> > are ONLY using FreeBSD
> >
> 
> Yes. And the world stopped using them too around that time, give or take 5
> years.

That response doesnt even fit with the assertion.
Or are you saying the world stopped using other OS's?  As that
is about the only thing that seems to fit your assertion.
 
> > > I did have to change these back in the day when we inferred what the CHS
> > > geometry
> > > was from the drive by looking at the MBR's partitions that you knew
> > > (assumed really)
> > > started on a cylinder value. This hasn't mattered in FreeBSD since sos
> > > rewrote ata
> > > the second time. DOS had to do these things because old-school MFM, RLL,
> > etc
> > > disks couldn't return their CHS, so DOS had to enshrine them in the MBR
> > to
> > > get
> > > a hint (or have the drive type BIOS to just know). Since we use LBA
> > > exclusively,
> > > none of this matter to FreeBSD.
> >
> > WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
> > and UEFI are PROPBABLY reading those values and might even do a
> > nice divide by zero for you should you write 0 in them.
> >
> 
> Maybe rather than using all caps you could give a specific example. I've
> not had to help anybody with CHS values in maybe 15 years, and even
> then it was rare. In the prior 10 years to that I went from shipping product
> where CHS had to be right, to shipping product where it didn't matter at
> all on a set of SBCs that were lagging the industry by 5 years.

I have given specifics, you seem to read right pass them, and since
I already see commits falling in I am assuming at this point it has
zero point in confersing with what is a Brick wall.

> 
> Also, UEFI doesn't care: It has no CHS APIs. It's all LBA. The only places
> in the
> standard where 'Cylinder' is mentioned is the (now obsolete) name for
> fields in
> a ATA packet that now mean different parts of the LBA for modern commands.

You yet again seem to ignore what it was I said, UEFI/CSM != UEFI, and
there are many buggy CSM's that roach on zeros in the CHS area.
Your lack of experience with these problems does not mean they lack
to exist.

When board makers rip out CSM and BIOS mode booting you can make
your assertion, until then this stuff matters as a simple case of fact.

> > > I've certainly never needed to tweak these in single user mode on an
> > > emergency
> > > basis. Why? Because you can't get to single user mode because the kernel
> > > won't
> > > even load if you have these wrong. So either you are booting some rescue
> > > disk
> > > to fix that (in which case you can craft it for your special
> > environment).,
> > > or you are
> >
> > rescue disk == any FreeBSD install media from the last 20 years.
> > your REALLY stuck in a small box 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Freddie Cash]

Sounds like a custom mfsBSD or Frenzy CD/USB would be better suited to
these bare-metal rescue setups.  Something that has the specific tools you
need already installed.  I know I've kept various versions of these CD
images around for just this purpose.  I always found them nicer to use than
the FreeBSD install CDs in rescue mode, as there's a fully-functional
FreeBSD install to work from, including the ability to install packages
temporarily.

-- 
Freddie Cash
fjwc...@gmail.com

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Stefan Esser]

Am 26.01.24 um 17:09 schrieb Rodney W. Grimes:

Am 25.01.24 um 16:38 schrieb Ed Maste:

On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
sbin/growfs/tests/legacy_test.pl
tools/regression/msdosfs/msdosfstest-2.sh
tools/regression/tmpfs/t_vnd
tools/tools/nanobsd/legacy.sh


All these scripts that currently depend on bsdlabel could
easily be converted to exclusively use gpart instead.

Other scripts that had been identified to use bsdlabel or
disklabel are unused / not relevant for FreeBSD.

[...]

The bsdlabel/disklabel/fdisk programs could be rewritten using
gpart without too much effort, at least for the use cases that


After looking at the source code it appears that there is
no need to rewrite any of the bsdlabel/disklabel code, since
it already uses geom calls to access the partition data and
only uses direct disk writes to write out the partition table
(as does gpart, AFAICT).

So, I do not see any dependencies on deprecated kernel features.

I have not compared the bsdlabel code and gpart_write_partcode()
in detail, but I do not see much of a difference at first glance.

Therefore, bsdlabel and disklabel could be kept in the base
system, IMHO. (But fdisk should go ...)


That would be wonderful.  Even just getting it to spit out
the FULL MBR values that are in a protective 0x238 MBR
would go along way to diagnose some corrupt GPT disks.


If you need access to the protective MBR of a GPT partition,
this feature should be added to gpart instead, IMHO.

But what's wrong with using "file -s" for this purpose:

# file -s /dev/nda0
/dev/nda0: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), 
end-CHS (0x3ff,255,63), startsector 1, 1953525167 sectors, extended partition 
table (last)


Do you need more information from the protective MBR?

This will not work on mounted file systems, though. But if
you got the disk mounted, I'd expect you do not really need
this information ...


have not become obsolete (e.g. CHS specifications) and only for
use in scripts (i.e. no fdisk interactive edit mode).


You are fooling yourself if you think an MBR and CHS values
are obsolete.  GPT *IS* a type 0x238 MBR and see how many
BIOSes you can crash by writting garbage (Especially 0x0)
to the CHS values.  That MBR must have proper values, and
you cant just ignore that they exist.


Again something that gpart should be able to diagnose and fix.

Doesn't "gpart recover" already fix such protective MBRs?


Even parsing of the disktab format and a conversion to gpart
backup format for use by gpart restore should not be too hard.

That would keep the commands available for those that use them
in scripts outside the FreeBSD sources, but would also allow to
remove the kernel interfaces used by those legacy tools.

I'd be willing to write those emulations of legacy tools, if
there is interest in going that way ...


I would be interested in seeing these.
For me gpart does do a lot of things, but it is missing
some very low level stuff that is probably should have.


I read that to mean that gpart is useful for standard setup
operations, but it lacks commands that might be useful to
diagnose inconsistent parameters?

Well, adding consistency checks and warning about potential
issues might not have been on the requirements sheet, but if
you specify checks that should be performed, these could be
added either to "gpart show" or a "gaprt check" command could
be implemented.

If you want such consistency checks added, then specify them
in a feature request PR, for example.

Best regards, STefan

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Fri, Jan 26, 2024 at 9:17 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > > > 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 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:
> > >
> >
> > In the last 20 years when have you needed this?
>
> Last week, and probably about every other month for the last
> 30 years.
>

What. specifically did you need to change, for what hardware, etc?


> >
> > LBA start/end is all that's relevant these days. The CHS values are
> > completely ignored
> > by FreeBSD. We use packet mode in the boot loader since about Pentium
> 150MHz
> > or so.
>
> WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
> are ONLY using FreeBSD
>

Yes. And the world stopped using them too around that time, give or take 5
years.


> >
> > I did have to change these back in the day when we inferred what the CHS
> > geometry
> > was from the drive by looking at the MBR's partitions that you knew
> > (assumed really)
> > started on a cylinder value. This hasn't mattered in FreeBSD since sos
> > rewrote ata
> > the second time. DOS had to do these things because old-school MFM, RLL,
> etc
> > disks couldn't return their CHS, so DOS had to enshrine them in the MBR
> to
> > get
> > a hint (or have the drive type BIOS to just know). Since we use LBA
> > exclusively,
> > none of this matter to FreeBSD.
>
> WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
> and UEFI are PROPBABLY reading those values and might even do a
> nice divide by zero for you should you write 0 in them.
>

Maybe rather than using all caps you could give a specific example. I've
not had to help anybody with CHS values in maybe 15 years, and even
then it was rare. In the prior 10 years to that I went from shipping product
where CHS had to be right, to shipping product where it didn't matter at
all on a set of SBCs that were lagging the industry by 5 years.

Also, UEFI doesn't care: It has no CHS APIs. It's all LBA. The only places
in the
standard where 'Cylinder' is mentioned is the (now obsolete) name for
fields in
a ATA packet that now mean different parts of the LBA for modern commands.


> >
> > I've certainly never needed to tweak these in single user mode on an
> > emergency
> > basis. Why? Because you can't get to single user mode because the kernel
> > won't
> > even load if you have these wrong. So either you are booting some rescue
> > disk
> > to fix that (in which case you can craft it for your special
> environment).,
> > or you are
>
> rescue disk == any FreeBSD install media from the last 20 years.
> your REALLY stuck in a small box Warner, please think outside
> that box.   You keep repeating FreeBSD FreeBSD FreeBSD, I have to
> inform you many of us who USE FreeBSD also USE other stuff, but
> we prefer to have FreeBSD be our goto system for this type of work.
>

Yes. I understand that. And with the packages installed, you still can
do that.


> > creating a special thing in multi-user, so you can install  For all these
> > use cases, fdisk
> > as a port is fine.
>
> I really do not want to have to maintain my own distribution.
>

And the project can no longer support programs that have buffer overflows
and other dangerous behavior when presented with untrusted information
from the disks that matters only to a few users.


> >
> > 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
> > > => 63  8388545  ada0  MBR  (4.0G)
> > >63  8388513 1  freebsd  [active]  (4.0G)
> > >   8388576   32- free -  (16K)
> > >
> > > Now I have learned that gpart backup/restore CAN get me
> > > at least basic bsdlabel -e function, but again it has
> > > no access to all the stuff stored that showsup with
> > > bsdlabel -A.  Which this is now the third time I have
> > > asked "how do I do bsdlabel -A -e 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Fri, Jan 26, 2024 at 9:02 AM Rodney W. Grimes <
freebsd-...@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 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
> > > => 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 easy
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 that
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 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 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 that
there's not a huge demand for coping with these edge cases.

Warner

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Toomas Soome]

> On 26. Jan 2024, at 18:21, Rodney W. Grimes  
> wrote:
> 
>> 
>> 
>>> On 26. Jan 2024, at 18:02, Rodney W. Grimes  
>>> 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 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
> => 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=/dev/zero of=/dev/FOO count=1
> 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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
 http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
>>> -- End of PGP section, PGP failed!
>>> 
>>> -- 
>>> Rod Grimes 
>>> rgri...@freebsd.org
> -- 
> Rod Grimes 
> rgri...@freebsd.org 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> 
> 
> > On 26. Jan 2024, at 18:02, Rodney W. Grimes  
> > 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 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
> >>> => 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=/dev/zero of=/dev/FOO count=1
GOOD LUCK!

> 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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> >> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
> > -- End of PGP section, PGP failed!
> > 
> > -- 
> > Rod Grimes 
> > rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > 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 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:
> >
> 
> In the last 20 years when have you needed this?

Last week, and probably about every other month for the last
30 years.

> 
> LBA start/end is all that's relevant these days. The CHS values are
> completely ignored
> by FreeBSD. We use packet mode in the boot loader since about Pentium 150MHz
> or so.

WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
are ONLY using FreeBSD
> 
> I did have to change these back in the day when we inferred what the CHS
> geometry
> was from the drive by looking at the MBR's partitions that you knew
> (assumed really)
> started on a cylinder value. This hasn't mattered in FreeBSD since sos
> rewrote ata
> the second time. DOS had to do these things because old-school MFM, RLL, etc
> disks couldn't return their CHS, so DOS had to enshrine them in the MBR to
> get
> a hint (or have the drive type BIOS to just know). Since we use LBA
> exclusively,
> none of this matter to FreeBSD.

WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
and UEFI are PROPBABLY reading those values and might even do a
nice divide by zero for you should you write 0 in them.

> 
> I've certainly never needed to tweak these in single user mode on an
> emergency
> basis. Why? Because you can't get to single user mode because the kernel
> won't
> even load if you have these wrong. So either you are booting some rescue
> disk
> to fix that (in which case you can craft it for your special environment).,
> or you are

rescue disk == any FreeBSD install media from the last 20 years.
your REALLY stuck in a small box Warner, please think outside
that box.   You keep repeating FreeBSD FreeBSD FreeBSD, I have to
inform you many of us who USE FreeBSD also USE other stuff, but
we prefer to have FreeBSD be our goto system for this type of work.

> creating a special thing in multi-user, so you can install  For all these
> use cases, fdisk
> as a port is fine.

I really do not want to have to maintain my own distribution.

> 
> 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
> > => 63  8388545  ada0  MBR  (4.0G)
> >63  8388513 1  freebsd  [active]  (4.0G)
> >   8388576   32- free -  (16K)
> >
> > Now I have learned that gpart backup/restore CAN get me
> > at least basic bsdlabel -e function, but again it has
> > no access to all the stuff stored that showsup with
> > bsdlabel -A.  Which this is now the third time I have
> > asked "how do I do bsdlabel -A -e with gpart"?  One
> > person at least answered that with:
> > gpart backup GEOM >backup
> > vi backup
> > gpart restore GEOM
> >
> 
> OK Let's look at these extra fields:
> 
> # /dev/md0:
> type: unknown
> disk: amnesiac
> label:
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 130
> sectors/unit: 2097152
> rpm: 3600
> interleave: 1
> trackskew: 0
> cylinderskew: 0
> headswitch: 0 # milliseconds
> track-to-track seek: 0 # milliseconds
> drivedata: 0
> 
> type isn't used at all in FreeBSD.
> disk is for /etc/disktab, something we've not really needed since FreeBSD 3
> or so.
> label can be set with gpart add/modify -l.
> I've never used flags. Can't speak to that.
> bytes/sector: This is a physical property of the drive, not the label.  You
> can find it with gpart list:
>% gpart list md0
>
>Consumers:
>1. Name: md0
>   Mediasize: 1073741824 (1.0G)
>   Sectorsize: 512
> The rest of this/that are reported or you can do math:
> fwheads: 255 <- tracks/cylinder
> fwsectors: 63 <-- sectors/track
> last: 2097151 <-- sectors/unit - 1
> now, cylenders and sectors/cylinder you can compute. geom does this for
> reading/writing disk labels.
> rpm is hard coded to 3600 these days. FreeBSD doesn't care.
> 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Toomas Soome]

> On 26. Jan 2024, at 18:02, Rodney W. Grimes  
> 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 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
>>> => 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.

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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
>> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
> -- End of PGP section, PGP failed!
> 
> -- 
> Rod Grimes rgri...@freebsd.org
> 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> Am 25.01.24 um 16:38 schrieb Ed Maste:
> > On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
> >>
> >> Those are the only users in the tree, but not for long :)
> > 
> > I have some reviews open to remove some old fdisk / diskabel /
> > bsdlabel invocations from the tree.
> > 
> > With those applied, for fdisk I see the following references
> > (excluding sbin/fdisk/* and comments, old examples, etc.):
> > 
> > contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> 
> This test contains NetBSD specific details and will not run
> on FreeBSD.
> 
> > tests/sys/cddl/zfs/bin/zpool_smi.ksh
> 
> More than 99% of the tests in tests/sys/cddl/zfs are skipped,
> including this one, which relies on commands that do not exist
> on FreeBSD.
> 
> > For bsdlabel / disklabel:
> > 
> > sbin/growfs/tests/legacy_test.pl
> 
> This test could easily be changed to use gpart.
> 
> > tools/regression/msdosfs/msdosfstest-2.sh
> 
> Trivially fixed.
> 
> > tools/regression/tmpfs/t_vnd
> 
> Trivially fixed.
> 
> > tools/tools/nanobsd/legacy.sh
> 
> Does already use gpart and could easily be fixed.
> 
> > contrib/netbsd-tests/kernel/t_umount.sh
> > contrib/netbsd-tests/kernel/t_umountstress.sh
> > contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> 
> These are unused and won't run without modification.
> 
> > sbin/newfs/runtest00.sh
> > sbin/newfs/runtest01.sh
> 
> Unused and do not run on a current version of FreeBSD.
> 
> > These will need to be addressed before actually removing any of these
> > binaries, of course.
> 
> I could fix those that are actually usable and installed on
> a current FreeBSD system within at most 1 hour.
> 
> >> 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 up.
> >> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> >> been so long that I've forgotten
> > 
> > If we eventually stop exporting those kernel interfaces the tools
> > would fail anyway, so IMO we can keep providing the kernel interfaces
> > along with the headers etc, and keep building from source until/unless
> > we drop support altogether.
> 
> The bsdlabel/disklabel/fdisk programs could be rewritten using
> gpart without too much effort, at least for the use cases that

That would be wonderful.  Even just getting it to spit out
the FULL MBR values that are in a protective 0x238 MBR
would go along way to diagnose some corrupt GPT disks.

> have not become obsolete (e.g. CHS specifications) and only for
> use in scripts (i.e. no fdisk interactive edit mode).

You are fooling yourself if you think an MBR and CHS values
are obsolete.  GPT *IS* a type 0x238 MBR and see how many
BIOSes you can crash by writting garbage (Especially 0x0)
to the CHS values.  That MBR must have proper values, and
you cant just ignore that they exist.

> 
> Even parsing of the disktab format and a conversion to gpart
> backup format for use by gpart restore should not be too hard.
> 
> That would keep the commands available for those that use them
> in scripts outside the FreeBSD sources, but would also allow to
> remove the kernel interfaces used by those legacy tools.
> 
> I'd be willing to write those emulations of legacy tools, if
> there is interest in going that way ...

I would be interested in seeing these.
For me gpart does do a lot of things, but it is missing
some very low level stuff that is probably should have.

> Regards, STefan
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

-- 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 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
> > => 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.

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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
-- End of PGP section, PGP failed!

-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Sulev-Madis Silber]

call me new, i only started with 4.6, being 19 years old at that time, which is 
pretty good i think

i've always found anything but gpart way too confusing to use. by that time i 
started with fbsd, chs was also gone for good. hence, no need, and when gpart 
came, i just switched over. and i consider myself a slow adapter to some of new 
things

also, why would ufs users need to be immediately assumed to be only using 
anything but gpart? it's not like ufs is some old legacy. also i don't really 
believe you could really use 15 with all the features except of some disk 
tools. on all new hw. on old hw, you won't be using 15. because fdisk is not 
the only thing we removed over years. unsure if sad or happy path. nbsd seems 
to support everything still i see. i don't know, maybe i should have really 
started with actual unix where i would have gotten lifelong preference to fdisk 
and disklabel. high respect if those ones read this tho

but yea, from all the replies, only thing i see is fdisk and disklabel is more 
comfortable to use, while giving no technical benefits at all. fuck knows if 
that's the reason to keep them then

i recall myself objecting before when there was call to remove grdc and pom. 
can't say about pom, i've used it for fun sometimes. grdc found use when 
checking if times are in sync. but those really belong to ports. it not like 
those disappear or get banned. i could put them there myself, if it comes up 
again and i still miss them

we have moved a lot of things to ports already, since 4.6. altho, if pkgbase 
comes along, some argue against it too, it would be hard to draw a line where 
the "base" ends. what's "officially" supported and what's not

but yeah, i can confirm that a lot of changes have annoyed me. switch to pkgng. 
or that libxo breaks stuff. pkgng now works i think, xo is still crapshoot. 
despite, i admit i like being able to get json from sysutils

so yeah changes kind of suck, but they still happen?

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Thu, Jan 25, 2024, 10:49 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> > 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 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:
>

In the last 20 years when have you needed this?

LBA start/end is all that's relevant these days. The CHS values are
completely ignored
by FreeBSD. We use packet mode in the boot loader since about Pentium 150MHz
or so.

I did have to change these back in the day when we inferred what the CHS
geometry
was from the drive by looking at the MBR's partitions that you knew
(assumed really)
started on a cylinder value. This hasn't mattered in FreeBSD since sos
rewrote ata
the second time. DOS had to do these things because old-school MFM, RLL, etc
disks couldn't return their CHS, so DOS had to enshrine them in the MBR to
get
a hint (or have the drive type BIOS to just know). Since we use LBA
exclusively,
none of this matter to FreeBSD.

I've certainly never needed to tweak these in single user mode on an
emergency
basis. Why? Because you can't get to single user mode because the kernel
won't
even load if you have these wrong. So either you are booting some rescue
disk
to fix that (in which case you can craft it for your special environment).,
or you are
creating a special thing in multi-user, so you can install  For all these
use cases, fdisk
as a port is fine.

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
> => 63  8388545  ada0  MBR  (4.0G)
>63  8388513 1  freebsd  [active]  (4.0G)
>   8388576   32- free -  (16K)
>
> Now I have learned that gpart backup/restore CAN get me
> at least basic bsdlabel -e function, but again it has
> no access to all the stuff stored that showsup with
> bsdlabel -A.  Which this is now the third time I have
> asked "how do I do bsdlabel -A -e with gpart"?  One
> person at least answered that with:
> gpart backup GEOM >backup
> vi backup
> gpart restore GEOM
>

OK Let's look at these extra fields:

# /dev/md0:
type: unknown
disk: amnesiac
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 130
sectors/unit: 2097152
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0

type isn't used at all in FreeBSD.
disk is for /etc/disktab, something we've not really needed since FreeBSD 3
or so.
label can be set with gpart add/modify -l.
I've never used flags. Can't speak to that.
bytes/sector: This is a physical property of the drive, not the label.  You
can find it with gpart list:
   % gpart list md0
   
   Consumers:
   1. Name: md0
  Mediasize: 1073741824 (1.0G)
  Sectorsize: 512
The rest of this/that are reported or you can do math:
fwheads: 255 <- tracks/cylinder
fwsectors: 63 <-- sectors/track
last: 2097151 <-- sectors/unit - 1
now, cylenders and sectors/cylinder you can compute. geom does this for
reading/writing disk labels.
rpm is hard coded to 3600 these days. FreeBSD doesn't care.
The rest are for interleaving, which FreeBSD doesn't do, so we don't care.

So you can influence the values, but they aren't used for anything by
FreeBSD
that matters.

What if you need them for something else? Then just use the disklabel port.
You'll never need to hack them tn single user mode, so you can use the port
for all use cases.

Warner


> Warner
> --
> Rod Grimes
> rgri...@freebsd.org
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Stefan Esser]

Am 25.01.24 um 16:38 schrieb Ed Maste:

On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:


Those are the only users in the tree, but not for long :)


I have some reviews open to remove some old fdisk / diskabel /
bsdlabel invocations from the tree.

With those applied, for fdisk I see the following references
(excluding sbin/fdisk/* and comments, old examples, etc.):

contrib/netbsd-tests/sbin/gpt/t_gpt.sh


This test contains NetBSD specific details and will not run
on FreeBSD.


tests/sys/cddl/zfs/bin/zpool_smi.ksh


More than 99% of the tests in tests/sys/cddl/zfs are skipped,
including this one, which relies on commands that do not exist
on FreeBSD.


For bsdlabel / disklabel:

sbin/growfs/tests/legacy_test.pl


This test could easily be changed to use gpart.


tools/regression/msdosfs/msdosfstest-2.sh


Trivially fixed.


tools/regression/tmpfs/t_vnd


Trivially fixed.


tools/tools/nanobsd/legacy.sh


Does already use gpart and could easily be fixed.


contrib/netbsd-tests/kernel/t_umount.sh
contrib/netbsd-tests/kernel/t_umountstress.sh
contrib/netbsd-tests/sbin/gpt/t_gpt.sh


These are unused and won't run without modification.


sbin/newfs/runtest00.sh
sbin/newfs/runtest01.sh


Unused and do not run on a current version of FreeBSD.


These will need to be addressed before actually removing any of these
binaries, of course.


I could fix those that are actually usable and installed on
a current FreeBSD system within at most 1 hour.


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 up.
Though the IOCTLs they do (or used to do) may no longer be relevant. It's
been so long that I've forgotten


If we eventually stop exporting those kernel interfaces the tools
would fail anyway, so IMO we can keep providing the kernel interfaces
along with the headers etc, and keep building from source until/unless
we drop support altogether.


The bsdlabel/disklabel/fdisk programs could be rewritten using
gpart without too much effort, at least for the use cases that
have not become obsolete (e.g. CHS specifications) and only for
use in scripts (i.e. no fdisk interactive edit mode).

Even parsing of the disktab format and a conversion to gpart
backup format for use by gpart restore should not be too hard.

That would keep the commands available for those that use them
in scripts outside the FreeBSD sources, but would also allow to
remove the kernel interfaces used by those legacy tools.

I'd be willing to write those emulations of legacy tools, if
there is interest in going that way ...

Regards, STefan

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Alexander Leidinger]

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 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
=> 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.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
Description: OpenPGP digital signature

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

On Thu, 25 Jan 2024 at 17:26, Robert R. Russell  wrote:
>
> FYI gpart doesn't allow you to create disklabel with more than 8 items
> either.

Specify the number of partitions at `gpart create` time:

# mdconfig -s 1G -t swap
md0
# gpart create -s bsd -n 20 md0
md0 created
# for i in $(jot 19); do gpart add -t freebsd-ufs -s 1M md0; done
md0a added
md0b added
..
md0t added
# gpart show md0
=>  0  2097152  md0  BSD  (1.0G)
0 20481  freebsd-ufs  (1.0M)
 2048 20482  freebsd-ufs  (1.0M)
..
36864 2048   20  freebsd-ufs  (1.0M)
38912  2058240   - free -  (1.0G)

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Robert R. Russell]

On Wed, 24 Jan 2024 10:44:57 -0500
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 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.
> 

FYI gpart doesn't allow you to create disklabel with more than 8 items
either.

robert@venus ~ 563$ doas mdconfig -l
md0 
robert@venus ~ 564$ doas mdconfig -lv
md0 vnode  40M  /usr/home/robert/test_disk.img  
robert@venus ~ 565$ doas gpart backup md0
MBR 4
1 freebsd 1 81919  
robert@venus ~ 566$ doas gpart backup md0s1
BSD 8
1  freebsd-ufs 0  4096  
2 freebsd-swap  4096  4096  
4  freebsd-ufs  8192  4096  
5  freebsd-ufs 12288  4096  
6  freebsd-ufs 16384  4096  
7  freebsd-ufs 20480  4096  
8  freebsd-ufs 24576  4096  
robert@venus ~ 567$ doas gpart add -t freebds-swap -s 2M md0s1
gpart: index '9': No space left on device
robert@venus ~ 568$ doas gpart add -t freebds-swap -s 2M -i 9 md0s1
gpart: index '9': Invalid argument
robert@venus ~ 569$ bsdlabel /dev/md0s1
bsdlabel: unable to get correct path for /dev/md0s1: Permission denied
robert@venus ~ 570$ doas bsdlabel /dev/md0s1 
# /dev/md0s1:
8 partitions:
#  size offsetfstype   [fsize bsize bps/cpg]
  a:   4096  04.2BSD0 0 0
  b:   4096   4096  swap
  c:  81919  0unused0 0 # "raw" part, don't edit
  d:   4096   81924.2BSD0 0 0
  e:   4096  122884.2BSD0 0 0
  f:   4096  163844.2BSD0 0 0
  g:   4096  204804.2BSD0 0 0
  h:   4096  245764.2BSD0 0 0
robert@venus ~ 571$ 

I still need to get a netBSD VM running and create a test file with more than 8
partitions under a bsdlabel to see if gpart crashes.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message <20240125101308.92e93...@slippy.cwsent.com>, Cy Schubert writes:
> In message <84c6f3b1-58b3-44f8-aeaf-35f78e059...@quip.cz>, Miroslav Lachman 
> wri
> tes:
> > On 25/01/2024 06:50, Cy Schubert wrote:
> > > In message 
> > >  l.
> > c
> >
> >
> > >>
> > >> What can they do that gpart can't do?
> > > 
> > > This was quite a while ago, booted off my recovery USB attempting to repa
> ir
> > > some self caused damage. The ability to edit (vi) a file with starting
> > > addresses and lengths, visually using bsdlabel, was suited to my panicked
> > > state as I worked to recover the machine.
> > > 
> > > A visual view of columns of a bsdlabel, editing a label using vi, checkin
> g
> > > and double checking numbers before committing them is handy.The visual
> > > format and the ability to adjust the numbers in an editor before committi
> ng
> > > them is handy. You can't do this with gpart, as it's transactional. And
> > > bsdinstall doesn't give one the opportunity to check the numbers in detai
> l
> > > on a console before committing them.
> >
> > If you really like your editor of choice to edit partition table, you 
> > can use gpart backup and gpart restore like this:
> >
> > gpart backup ada0 > ada0.part
> > vi ada0.part
> > gpart restore -F -l < ada0.part
>
> That would work.
>
> >
> > > Maybe a good GSoC project may be to replace bsdlabel's driect writes to
> > > disk with geom calls. Though, t doesn't need to be bsdlabel, but some kin
> d
> > > of utility that displays the existing label in an editor session where
> > > changes can be made, using the editor, and committed. This could even be 
> an
> > > enhancement to bsdinstall: call it expert mode or whatever.
> >
> > Manipulating partition table in editor session can be achieved by few 
> > lines of shell script as a wrapper around gpart backup & gpart restore.
>
> Or just build a gpart edit mode with the functions used to implement backup 
> and restore. Excellent idea. Thank you. A small project to work on.
>
> >
> > Kind regards
> > Miroslav Lachman

A freebsd-bsdlabel port has been created making way for its removal.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[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 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
=> 63  8388545  ada0  MBR  (4.0G)
   63  8388513 1  freebsd  [active]  (4.0G)
  8388576   32- free -  (16K)

Now I have learned that gpart backup/restore CAN get me
at least basic bsdlabel -e function, but again it has
no access to all the stuff stored that showsup with
bsdlabel -A.  Which this is now the third time I have
asked "how do I do bsdlabel -A -e with gpart"?  One
person at least answered that with:
gpart backup GEOM >backup
vi backup
gpart restore GEOM

Now I just have to rewrite my bsdlabel GEOM >backup
files to be be gpart GEOM >backup files (I have precanned
sets of bsdlabel files I use to do bsdlabel -w GEOM with.

> Warner
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Bakul Shah]

On Jan 25, 2024, at 8:15 AM, Warner Losh  wrote:
> 
> What can fdisk and/or disklabel repair that gpart can't?

May be add a section in gpart that shows how to map fdisk &
bsdlabel functionality to gpart? Better still, why not
provide scripts for fdisk/bsdlabel that use gpart underneath?
FreeBSD should strive to provide backward compatibility

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

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 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?

Warner

>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
 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.

Re: Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

On Thu, 25 Jan 2024 at 10:50, Mina Galić  wrote:
>
> i was looking at cd(4) today, and to my surprise, it was full of disklabel 
> references.

Oh, indeed - as with the old references in ccd(4) that should go. The
last reference to `struct disklabel` in the CAM SCSI cd driver was
removed over two decades ago.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
> >
> > Those are the only users in the tree, but not for long :)
> 
> I have some reviews open to remove some old fdisk / diskabel /
> bsdlabel invocations from the tree.
> 
> With those applied, for fdisk I see the following references
> (excluding sbin/fdisk/* and comments, old examples, etc.):
> 
> contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> tests/sys/cddl/zfs/bin/zpool_smi.ksh
> 
> For bsdlabel / disklabel:
> 
> sbin/growfs/tests/legacy_test.pl
> tools/regression/msdosfs/msdosfstest-2.sh
> tools/regression/tmpfs/t_vnd
> tools/tools/nanobsd/legacy.sh
> contrib/netbsd-tests/kernel/t_umount.sh
> contrib/netbsd-tests/kernel/t_umountstress.sh
> contrib/netbsd-tests/sbin/gpt/t_gpt.sh
> sbin/newfs/runtest00.sh
> sbin/newfs/runtest01.sh
> 
> 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 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 up.
> > Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> > been so long that I've forgotten
> 
> If we eventually stop exporting those kernel interfaces the tools
> would fail anyway, so IMO we can keep providing the kernel interfaces
> along with the headers etc, and keep building from source until/unless
> we drop support altogether.
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: Re: Removing fdisk and bsdlabel (legacy partition tools)

[Mina Galić]

>  > Those are the only users in the tree, but not for long :)
>  
>  I have some reviews open to remove some old fdisk / diskabel /
>  bsdlabel invocations from the tree.
>  
>  With those applied, for fdisk I see the following references
>  (excluding sbin/fdisk/* and comments, old examples, etc.):
>  
>  contrib/netbsd-tests/sbin/gpt/t_gpt.sh
>  tests/sys/cddl/zfs/bin/zpool_smi.ksh
>  
>  For bsdlabel / disklabel:
>  
>  sbin/growfs/tests/legacy_test.pl
>  tools/regression/msdosfs/msdosfstest-2.sh
>  tools/regression/tmpfs/t_vnd
>  tools/tools/nanobsd/legacy.sh
>  contrib/netbsd-tests/kernel/t_umount.sh
>  contrib/netbsd-tests/kernel/t_umountstress.sh
>  contrib/netbsd-tests/sbin/gpt/t_gpt.sh
>  sbin/newfs/runtest00.sh
>  sbin/newfs/runtest01.sh

i was looking at cd(4) today, and to my surprise, it was full of disklabel 
references.
I haven't looked at the code itself yet, to see how far the documentation has 
drifted apart from reality, but to most users, our documentation is reality.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

On Wed, 24 Jan 2024 at 12:30, Warner Losh  wrote:
>
> Those are the only users in the tree, but not for long :)

I have some reviews open to remove some old fdisk / diskabel /
bsdlabel invocations from the tree.

With those applied, for fdisk I see the following references
(excluding sbin/fdisk/* and comments, old examples, etc.):

contrib/netbsd-tests/sbin/gpt/t_gpt.sh
tests/sys/cddl/zfs/bin/zpool_smi.ksh

For bsdlabel / disklabel:

sbin/growfs/tests/legacy_test.pl
tools/regression/msdosfs/msdosfstest-2.sh
tools/regression/tmpfs/t_vnd
tools/tools/nanobsd/legacy.sh
contrib/netbsd-tests/kernel/t_umount.sh
contrib/netbsd-tests/kernel/t_umountstress.sh
contrib/netbsd-tests/sbin/gpt/t_gpt.sh
sbin/newfs/runtest00.sh
sbin/newfs/runtest01.sh

These will need to be addressed before actually removing any of these
binaries, of course.

> 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 up.
> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> been so long that I've forgotten

If we eventually stop exporting those kernel interfaces the tools
would fail anyway, so IMO we can keep providing the kernel interfaces
along with the headers etc, and keep building from source until/unless
we drop support altogether.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message <84c6f3b1-58b3-44f8-aeaf-35f78e059...@quip.cz>, Miroslav Lachman 
wri
tes:
> On 25/01/2024 06:50, Cy Schubert wrote:
> > In message  c
>
>
> >>
> >> What can they do that gpart can't do?
> > 
> > This was quite a while ago, booted off my recovery USB attempting to repair
> > some self caused damage. The ability to edit (vi) a file with starting
> > addresses and lengths, visually using bsdlabel, was suited to my panicked
> > state as I worked to recover the machine.
> > 
> > A visual view of columns of a bsdlabel, editing a label using vi, checking
> > and double checking numbers before committing them is handy.The visual
> > format and the ability to adjust the numbers in an editor before committing
> > them is handy. You can't do this with gpart, as it's transactional. And
> > bsdinstall doesn't give one the opportunity to check the numbers in detail
> > on a console before committing them.
>
> If you really like your editor of choice to edit partition table, you 
> can use gpart backup and gpart restore like this:
>
> gpart backup ada0 > ada0.part
> vi ada0.part
> gpart restore -F -l < ada0.part

That would work.

>
> > Maybe a good GSoC project may be to replace bsdlabel's driect writes to
> > disk with geom calls. Though, t doesn't need to be bsdlabel, but some kind
> > of utility that displays the existing label in an editor session where
> > changes can be made, using the editor, and committed. This could even be an
> > enhancement to bsdinstall: call it expert mode or whatever.
>
> Manipulating partition table in editor session can be achieved by few 
> lines of shell script as a wrapper around gpart backup & gpart restore.

Or just build a gpart edit mode with the functions used to implement backup 
and restore. Excellent idea. Thank you. A small project to work on.

>
> Kind regards
> Miroslav Lachman


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message <2369865.bDOn7JOVgO@ravel>, Olivier Certner writes:
> --nextPart5823302.8T7jmnknE8
> Content-Transfer-Encoding: 7Bit
> Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
> From: Olivier Certner 
> To: Cy Schubert 
> Subject: Re: Removing fdisk and bsdlabel (legacy partition tools)
> Date: Thu, 25 Jan 2024 10:43:18 +0100
> Message-ID: <2369865.bDOn7JOVgO@ravel>
> In-Reply-To: <20240125055019.ccf1...@slippy.cwsent.com>
> MIME-Version: 1.0
>
> Hi,
>
> > A visual view of columns of a bsdlabel, editing a label using vi, checking 
> > and double checking numbers before committing them is handy.The visual 
> > format and the ability to adjust the numbers in an editor before committing
>  
> > them is handy. You can't do this with gpart, as it's transactional. And 
> > bsdinstall doesn't give one the opportunity to check the numbers in detail 
> > on a console before committing them.
>
> You seem to want to be able to stack a number of modifications before actuall
> y pushing them.  Actually, gpart(8) already can do that!  Please see the "OPE
> RATIONAL FLAGS" section in gpart(8).
>
> In between your tentative modifications, just use 'gpart show' to see where y
> ou stand.

gpart(8) should have a vi mode. That is different than having changes 
pending and committing them. A person is still entering commands rather 
than doing something like editing a spreadsheet, which is what editing a 
file is kind-of like. Even something like,

gpart show ada0s2 > some_file
vi some_file
gpart batch ada0s2 < some_file


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rolf M. Dietze]

Quoting Cy Schubert :


In message 
, Warner Losh writes:

--b0adc9060fbe7411
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.40onlwkz099...@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?


This was quite a while ago, booted off my recovery USB attempting to repair
some self caused damage. The ability to edit (vi) a file with starting
addresses and lengths, visually using bsdlabel, was suited to my panicked
state as I worked to recover the machine.

A visual view of columns of a bsdlabel, editing a label using vi, checking
and double checking numbers before committing them is handy.The visual
format and the ability to adjust the numbers in an editor before committing
them is handy. You can't do this with gpart, as it's transactional. And
bsdinstall doesn't give one the opportunity to check the numbers in detail
on a console before committing them.

Maybe a good GSoC project may be to replace bsdlabel's driect writes to
disk with geom calls. Though, t doesn't need to be bsdlabel, but some kind
of utility that displays the existing label in an editor session where
changes can be made, using the editor, and committed. This could even be an
enhancement to bsdinstall: call it expert mode or whatever.


well, I'v been there many times.

There is another regular usecase, this time for fdisk for me, that ist
repairing a windows boot disk. I have no idea of waht to use if not fdisk
to do that, rather than booting linux to run fdisk for windows repairs.
That in fact would be the only linux box, only to support windows...

/rmd

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Miroslav Lachman]

On 25/01/2024 06:50, Cy Schubert wrote:

In message 




What can they do that gpart can't do?


This was quite a while ago, booted off my recovery USB attempting to repair
some self caused damage. The ability to edit (vi) a file with starting
addresses and lengths, visually using bsdlabel, was suited to my panicked
state as I worked to recover the machine.

A visual view of columns of a bsdlabel, editing a label using vi, checking
and double checking numbers before committing them is handy.The visual
format and the ability to adjust the numbers in an editor before committing
them is handy. You can't do this with gpart, as it's transactional. And
bsdinstall doesn't give one the opportunity to check the numbers in detail
on a console before committing them.


If you really like your editor of choice to edit partition table, you 
can use gpart backup and gpart restore like this:


gpart backup ada0 > ada0.part
vi ada0.part
gpart restore -F -l < ada0.part


Maybe a good GSoC project may be to replace bsdlabel's driect writes to
disk with geom calls. Though, t doesn't need to be bsdlabel, but some kind
of utility that displays the existing label in an editor session where
changes can be made, using the editor, and committed. This could even be an
enhancement to bsdinstall: call it expert mode or whatever.


Manipulating partition table in editor session can be achieved by few 
lines of shell script as a wrapper around gpart backup & gpart restore.


Kind regards
Miroslav Lachman

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Olivier Certner]

Hi,

> A visual view of columns of a bsdlabel, editing a label using vi, checking 
> and double checking numbers before committing them is handy.The visual 
> format and the ability to adjust the numbers in an editor before committing 
> them is handy. You can't do this with gpart, as it's transactional. And 
> bsdinstall doesn't give one the opportunity to check the numbers in detail 
> on a console before committing them.

You seem to want to be able to stack a number of modifications before actually 
pushing them.  Actually, gpart(8) already can do that!  Please see the 
"OPERATIONAL FLAGS" section in gpart(8).

In between your tentative modifications, just use 'gpart show' to see where you 
stand.
 
Thanks and regards.

-- 
Olivier Certner

signature.asc
Description: This is a digitally signed message part.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Alex Dupre]

Ed Maste wrote:
> I would like to disconnect these from the build, and subsequently
> remove them.

I'm in favour of this change. Having different tools (some modern and
updated, others deprecated and limited) in base to do the same task can
confuse the users. If possible move them to ports for people still using
them, with a clear deprecation warning.

-- 
Alex Dupre

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message 
, Warner Losh writes:
> --b0adc9060fbe7411
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Jan 24, 2024, 10:07=E2=80=AFPM Cy Schubert  om>
> wrote:
>
> > In message <202401242347.40onlwkz099...@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?

This was quite a while ago, booted off my recovery USB attempting to repair 
some self caused damage. The ability to edit (vi) a file with starting 
addresses and lengths, visually using bsdlabel, was suited to my panicked 
state as I worked to recover the machine.

A visual view of columns of a bsdlabel, editing a label using vi, checking 
and double checking numbers before committing them is handy.The visual 
format and the ability to adjust the numbers in an editor before committing 
them is handy. You can't do this with gpart, as it's transactional. And 
bsdinstall doesn't give one the opportunity to check the numbers in detail 
on a console before committing them.

Maybe a good GSoC project may be to replace bsdlabel's driect writes to 
disk with geom calls. Though, t doesn't need to be bsdlabel, but some kind 
of utility that displays the existing label in an editor session where 
changes can be made, using the editor, and committed. This could even be an 
enhancement to bsdinstall: call it expert mode or whatever.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Wed, Jan 24, 2024, 10:07 PM Cy Schubert 
wrote:

> In message <202401242347.40onlwkz099...@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 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 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 things
> > > > 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 use
> '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
>  rgri...@freebsd.or
> > g
> >
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
>
> e^(i*pi)+1=0
>
>
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message , "Patrick M. 
Hause
n" writes:
> Hi all,
>
> > Am 25.01.2024 um 00:47 schrieb Rodney W. Grimes =
> :
> >=20
> >> 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
>
> I totally undestand that point, but what exactly do these tools do that
> gpart cannot? On MBR disks? With BSD partitions?
>
> Ever since I found out that gpart can manage *all* on-disk partition =
> formats
> I have not been using anything else. You can create your MBR partitions
> and BSD labels just fine with gpart. At least in all situations I =
> encountered,
> there might of course be edge cases I simply don't know.

On occasion when trying to manipulate a disk label, gpart will refuse to. 
Usually when creating or manipulating a label on a zvol one doesn't want to 
use on the host system, that is destined to be used in a VM. It's simpler 
to create the partitions and labels beforehand, attach the zvol to the VM, 
boot and install (or test) within the VM. In this case one doesn't even 
care if geom sees the "disk" or its partitions on the host because the 
"disk" is destined for use in a VM.

I've created zvols for use by various VMs in this manner.

I agree with Rod's remark that when one is in panic mode working through a 
difficult situation extra tools, not fewer, can help.

Regarding extra tools, I do maintain a full copy of FreeBSD on a USB disk, 
in order to recover from catastrophic situations. They're extremely rare, 
the last of which was the result of a commit that broke loader (or was it a 
boot blocks -- I can't remember the exact details anymore) in 12 or 
13-CURRENT. The extra tools came in handy as I worked through the mess.

>
> gpart is not the "GPT partition tool". It's the universal swiss army =
> knife
> "GEOM partition tool" for all disk partitioning in any format supported.
>
> Kind regards,
> Patrick=
>


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message <202401242347.40onlwkz099...@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.

>
> 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 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 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 things
> > > 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 use '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 rgri...@freebsd.or
> g
>


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Patrick M. Hausen]

Hi all,

> Am 25.01.2024 um 00:47 schrieb Rodney W. Grimes 
> :
> 
>> 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.
> 
> 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.

I totally undestand that point, but what exactly do these tools do that
gpart cannot? On MBR disks? With BSD partitions?

Ever since I found out that gpart can manage *all* on-disk partition formats
I have not been using anything else. You can create your MBR partitions
and BSD labels just fine with gpart. At least in all situations I encountered,
there might of course be edge cases I simply don't know.

gpart is not the "GPT partition tool". It's the universal swiss army knife
"GEOM partition tool" for all disk partitioning in any format supported.

Kind regards,
Patrick

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> 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.

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 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 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 use 
> > '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. It's
> > been so long that I've forgotten
> >
> > Warner
-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Kevin Oberman]

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 PM 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 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 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 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 use
> '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. It's
> > been so long that I've forgotten
> >
> > Warner
> >
>
>

-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Tomek CEDRO]

On Wed, Jan 24, 2024 at 6:30 PM Warner Losh wrote:
 The in-kernel gpart copes so much better.
> (..) > I wouldn't object to making these ports (..)

+1 for moving fdisk and bsdlabel to ports instead deleting :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Removing fdisk and bsdlabel (legacy partition tools)

[George Michaelson]

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 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 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 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 use '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. It's
> been so long that I've forgotten
>
> Warner
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Miroslav Lachman]

On 24/01/2024 19:50, Rodney W. Grimes 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.


man page additions are not going to reach the people who may be
using this.  This should be a gonein(15) added to the binary.
I also suspect that all of the people doing ufs installs
are doing so via bsdlabel, not gpart.


I have many FreeBSD installations running in a UFS-based VM, created 
using bsdinstall or manually using gpart. I haven't touched fdisk and 
bsdlabel in at least a decade.



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


How can you do bsdlabel -A -e /dev/foo with gpart?  As far as I know
that functionality never made it to gpart, neither the -A or -e.


I was curious what this command does that is so special, but it seems to 
be of no use anymore:


% bsdlabel -A /dev/ada0 


bsdlabel: disks with more than 2^32-1 sectors are not supported

Do we really need a tool that can't handle disks of average size (in 
this case 4TB)?


Kind regards
Miroslav Lachman

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Julian H. Stacey]

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 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.

Probably many do, clueless there's a proposal to remove them,
as many wont be tracking lists (I havent been tracking lately, 
focused on moving home, other will have other distractions)

Personaly:
  I run a mix of machines from servers with 14 back through to
  clients with 4.11 http://berklix.com/scanjet/ 

  Some boxes work well, have no benefit from upgrade & no capability
  to support the bloat from 4 to 15 but still very useful in
  heterogenous internal nets.

  Security is moot behind some firewalls, small is beautiful, &
  sometimes essential, eg I plan to hitch another small old toshiba
  libretto in a waterproof box to use parallel port to drive stepper
  motors for a satellite dish.
  
  I master disk images & trees for such old boxes, mounted on more modern
  FreeBSD, but common fdisk is nice on host & target.
  
  I also use fdisk maintained MBR on eg USB sticks on key ring,
  combining rescue & install partitions of new BSD + backup of
  encrypted data, + A DOS slice for export import for non BSD world.

MBR via fdisk is a familiar comfort in a world of variant OS's.
BSD people who've wrestled with weird Linux boot stuff may sypathise
with the idea if retaining familiar fdisk for non latest BSD people.

But if people really espouse tangible benefit to kicking fdisk out of src/, 
I just hope same people first copy fdisk in to ports/ before out of src/

Cheers,
-- 
Julian Stacey.  Arm Ukraine.  Contraception V Global heating & resource wars. 
Gmail & Googlemail Fail http://berklix.org/jhs/mail/#bad 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Mike Karels]

On 24 Jan 2024, at 12:50, Rodney W. Grimes 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.
>
> man page additions are not going to reach the people who may be
> using this.  This should be a gonein(15) added to the binary.
> I also suspect that all of the people doing ufs installs
> are doing so via bsdlabel, not gpart.

I suspect that more ufs installs are done with bsdinstall than with
bsdlabel.  The interactive mode is much easier to use than bsdlabel -e,
where you have to do your own arithmetic.  A couple of wrappers around
bsdinstall could make it a much better replacement for bsdlabel -e, etc.
(No criticism of bsdlabel, but it's so old I don't remember if I wrote
it; I think I did.)  I have a number of test systems using ufs, and I
do my modifications with gpart, which accepts humanized numbers and
does the arithmetic.

Mike

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Cy Schubert]

In message 
, Ed Maste writes:
> 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.
>

We need to fix the kern.geom.debugflags sysctl foot shooting option so that 
it works. (Not that bsdlabel or fdisk worked around the issue). Otherwise 
one is left with boot to single user or from alternate media if that 
doesn't work.

I do have a patch that circumvents the problem. I haven't looked it it in 
years and probably needs some cleanup though.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Rodney W. Grimes]

> 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.

man page additions are not going to reach the people who may be
using this.  This should be a gonein(15) added to the binary.
I also suspect that all of the people doing ufs installs
are doing so via bsdlabel, not gpart.

> >
> > 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

How can you do bsdlabel -A -e /dev/foo with gpart?  As far as I know
that functionality never made it to gpart, neither the -A or -e.

> >
> > 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.

My prototype files that are read by bsdlabel -R as far as I know
can not be processed by gpart.
fdisk I can probably get away from, but thats a working binary
accross a lot of platforms which do not have gpart.

> >
> 
> 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 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 use
> '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. It's
> been so long that I've forgotten
> 
> Warner

-- 
Rod Grimes rgri...@freebsd.org

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Poul-Henning Kamp]

Ed Maste writes:

> 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.

By all means!

It may even be possible to shave some of the weirder bits out of
GEOM when they're gone.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

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 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 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 use
'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. It's
been so long that I've forgotten

Warner

Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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.