Re: loading vmm.ko crashes main-n267684-e4b646ce1610

[Zhenlei Huang]

> On Jan 24, 2024, at 8:47 AM, void  wrote:
> 
> Hello,
> 
> Loading vmm either via vmm_load=YES in /boot/loader.conf or
> manually via kldload vmm crashes the system to db> prompt
> as shown in the link below:
> 
> http://void.f-m.fm.user.fm/Screenshot_20240122_135539.png
> 
> Thing is, access is via a html5 console with no up/down scrolling
> or buffer. Nothing can be entered into the db> prompt. There's plenty
> more information when it crashes, but the output scrolls off the top.
> 
> The main-n267684 is running a modified GENERIC-NODEBUG
> kernel and has debugging turned off in /etc/src.conf 
> (it has WITHOUT_ASSERT_DEBUG= and WITHOUT_DEBUG_FILES= and 
> WITH_MALLOC_PRODUCTION=)
> 
> Apart from turning these on again and rebuilding GENERIC, what other things
> need to be set to get a usable coredump when this happens?

You may want to configure the dump device before get the coredump.
See  
https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-obtain
 

 .

> 
> /var/crash has nothing in it.
> 
> thanks in advance for any assistance
> -- 
> 

Best regards,
Zhenlei

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: Error while linking bsdinstall

[Alfonso S. Siciliano]

On 19/01/2024 18:33, Fernando Apesteguía wrote:

Hi all,

I'm having a problem linking bsdinstall in current 
dfe30e41967f9b5112c42ca20ec2c366db74cef9


ld: error: undefined symbol: bsddialog_clear
 >>> referenced by part_wizard.c:76 
(/data/fernape_data/FreeBSD-repos/src/usr.sbin/bsdinstall/partedit/part_wizard.c:76)

 >>>               part_wizard.o:(part_wizard)
 >>> referenced by part_wizard.c:84 
(/data/fernape_data/FreeBSD-repos/src/usr.sbin/bsdinstall/partedit/part_wizard.c:84)

 >>>               part_wizard.o:(part_wizard)
 >>> referenced by partedit.c:126 
(/data/fernape_data/FreeBSD-repos/src/usr.sbin/bsdinstall/partedit/partedit.c:126)

 >>>               partedit.o:(main)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Anything I forgot to do? This is in a branch that I had lingering that I 
rebased with main without any issues.


Thanks in advance.



Hi,

I seem partedit "wants" to link to the old libbsddialog version.
bsddialog_clear() was added in 1.0, this version (the last) was imported
in BASE on October.
Probably a possible solution could be `make clean[dir]` in
/data/fernape_data/FreeBSD-repos/src/lib/libbsddialog/.

A more verbose error could tell what partedit "wants" (properly where)
to link.

Best Regards,
Alfonso

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.