> 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
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
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
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
20 matches
Mail list logo
