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

RCS and $FreeBSD$ purge

[Steve Kargl]

I'm currently syncing src/lib/msun with my private libm 
repository where I do much of my hacking on libm issues.
In looking at diffs, I see a few lingering RCS and
$FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
contains

/* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $") */

Should this be cleaned up or ws intentional left in the 
source code?


-- 
Steve

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