I'll add it to the gsoc list, unless someone submits a pull request to make
it so in the mean time :)
Warner
On Sun, Jan 28, 2024 at 11:29 AM Tomek CEDRO wrote:
> Yes! Installer is always used in emergency it would be great to provide
> some servicing tools there too :-)
>
> For years I was
Yes! Installer is always used in emergency it would be great to provide
some servicing tools there too :-)
For years I was using bootable Linux to fix people computers and it would
be nice to have that in FreeBSD :-)
+1 for memstick full with additional service utilities (fix partitions,
mount
On Sat, 27 Jan 2024 21:52:06 -0700
Warner Losh wrote:
> On Sat, Jan 27, 2024, 1:26 PM Cy Schubert wrote:
>
> > On January 26, 2024 7:13:15 PM PST, Ed Maste wrote:
> > >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
> > >>
> > >> Probably many do, clueless there's a proposal to remove
On Sat, Jan 27, 2024, 1:26 PM Cy Schubert wrote:
> On January 26, 2024 7:13:15 PM PST, Ed Maste wrote:
> >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
> >>
> >> Probably many do, clueless there's a proposal to remove them,
> >> as many wont be tracking lists (I havent been tracking
On January 26, 2024 7:13:15 PM PST, Ed Maste wrote:
>On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
>>
>> Probably many do, clueless there's a proposal to remove them,
>> as many wont be tracking lists (I havent been tracking lately,
>> focused on moving home, other will have other
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,
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
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
> 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
> >>>
> 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
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
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
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 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
> > >>
> 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
>
>
> > 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:
>
[ 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
> 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
> 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
-- 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
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
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
>
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
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
On Thu, 25 Jan 2024 at 17:26, Robert R. Russell wrote:
>
> FYI gpart doesn't allow you to create disklabel with more than 8 items
> either.
Specify the number of partitions at `gpart create` time:
# mdconfig -s 1G -t swap
md0
# gpart create -s bsd -n 20 md0
md0 created
# for i in $(jot 19); do
On Wed, 24 Jan 2024 10:44:57 -0500
Ed Maste wrote:
> MBR (PC BIOS) partition tables were historically maintained with
> fdisk(8), but gpart(8) has long been the preferred method for working
> with partition tables of all types. fdisk has been declared as
> obsolete in the man page since 2015.
In message <20240125101308.92e93...@slippy.cwsent.com>, Cy Schubert writes:
> In message <84c6f3b1-58b3-44f8-aeaf-35f78e059...@quip.cz>, Miroslav Lachman
> wri
> tes:
> > On 25/01/2024 06:50, Cy Schubert wrote:
> > > In message
> > > l.
> > c
> >
> >
> > >>
> > >> What can they do that gpart
> 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
On Jan 25, 2024, at 8:15 AM, Warner Losh wrote:
>
> What can fdisk and/or disklabel repair that gpart can't?
May be add a section in gpart that shows how to map fdisk &
bsdlabel functionality to gpart? Better still, why not
provide scripts for fdisk/bsdlabel that use gpart underneath?
FreeBSD
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,
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
On Thu, 25 Jan 2024 at 10:50, Mina Galić wrote:
>
> i was looking at cd(4) today, and to my surprise, it was full of disklabel
> references.
Oh, indeed - as with the old references in ccd(4) that should go. The
last reference to `struct disklabel` in the CAM SCSI cd driver was
removed over two
> 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
>
> > 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,
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/*
In message <84c6f3b1-58b3-44f8-aeaf-35f78e059...@quip.cz>, Miroslav Lachman
wri
tes:
> On 25/01/2024 06:50, Cy Schubert wrote:
> > In message c
>
>
> >>
> >> What can they do that gpart can't do?
> >
> > This was quite a while ago, booted off my recovery USB attempting to repair
> > some self
In message <2369865.bDOn7JOVgO@ravel>, Olivier Certner writes:
> --nextPart5823302.8T7jmnknE8
> Content-Transfer-Encoding: 7Bit
> Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
> From: Olivier Certner
> To: Cy Schubert
> Subj
Quoting Cy Schubert :
In message
, Warner Losh writes:
--b0adc9060fbe7411
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jan 24, 2024, 10:07=E2=80=AFPM Cy Schubert
wrote:
> In message
On 25/01/2024 06:50, Cy Schubert wrote:
In message
What can they do that gpart can't do?
This was quite a while ago, booted off my recovery USB attempting to repair
some self caused damage. The ability to edit (vi) a file with starting
addresses and lengths, visually using bsdlabel, was
Hi,
> A visual view of columns of a bsdlabel, editing a label using vi, checking
> and double checking numbers before committing them is handy.The visual
> format and the ability to adjust the numbers in an editor before committing
> them is handy. You can't do this with gpart, as it's
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
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>,
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
> > >
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
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
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
> 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
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
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
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,
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
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
>
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
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
> 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
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
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.
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
58 matches
Mail list logo
