Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

> 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

Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

> 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

Re: Removing fdisk and bsdlabel (legacy partition tools)

> 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

Re: noatime on ufs2

> Am 2024-01-10 22:49, schrieb Mark Millard: > > > I never use atime, always noatime, for UFS. That said, I'd never > > propose > > changing the long standing defaults for commands and calls. I'd avoid: > > [good points I fully agree on] > > There's one possibility which nobody talked about

Re: noatime on ufs2

> Olivier Certner wrote on > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > What I'm saying is that, based on others' input so far, my own (long, even > > if not as long as yours) experience and some late reflection, is that > > "noatime" should be the default (everywhere, all mounts and all

Re: Proposal: Disable compression of newsyslog by default

> On 2023-12-23 10:17, Ceri Davies wrote: > > I really don?t like the idea of adding flags that make the program ignore a > > config file. I also think this is premature until ZFS installs are default > > on all architectures. > > > > However, if you must (and I see you have) change this,

Re: Proposal: Disable compression of newsyslog by default

> On 2023-12-23 06:52, Konstantin Belousov wrote: > > On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote: > >> Hi, > >> > >> Inspired by D42961, I propose that we move forward with disabling the > >> compression by default in newsyslog, as implemented in > >> https://reviews.freebsd.org/D43169

Re: FreeBSD 14.0-BETA5 Now Available

> On Mon, 23 Oct 2023 at 11:06, Rodney W. Grimes > wrote: > > > > This is a regression of forms... I have been using ventoy to boot FreeBSD > > since 12 or so and this is the first I have heard of a failure to boot > > FreeBSD with Ventoy, so my ask is, what

Re: FreeBSD 14.0-BETA5 Now Available

> On Mon, 16 Oct 2023 at 13:46, Gy?rgy P?sztor > wrote: > > > >> I am interested in looking for a way to make Ventoy support more > >> reliable, but that will not happen for 14.0. > > > > Is it depending on Ventoy? > > Yes, Ventoy needs to be updated for newer FreeBSD releases. For more info,

Re: Surprise null root password

> It turns out all seven hosts in my cluster report > a null password for root in /usr/src/etc/master.passwd: > root::0:0::0:0:Charlie &:/root:/bin/sh > > Is that intentional? No, but I suspect your build/update procedures are infact telling the system to do this. Someone else pointed out

Re: Surprise null root password

> On 26 May 2023, at 12:35, bob prohaska wrote: > > > While going through normal security email from a Pi2 > > running -current I was disturbed to find: > > > > Checking for passwordless accounts: > > root::0:0::0:0:Charlie &:/root:/bin/sh > > > > The machine had locked up on a -j4 buildworld

Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support

> On Thu, 11 May 2023 23:08:30 +0200 > Yuri wrote: > > > Warner Losh wrote: > > > > > > > > > On Thu, May 11, 2023, 2:50 PM Rodney W. Grimes > > > mailto:freebsd-...@gndrsh.dnsmgr.net>> > > > wrote: > > > > > &g

Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support

> On Thu, May 11, 2023, 2:16 PM Yuri wrote: > > > Warner Losh wrote: > > > The branch main has been updated by imp: > > > > > > URL: > > https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > > > > > > commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > > > Author:

Re: textdumps are too slow

> On Fri, Apr 7, 2023 at 12:08?PM Warner Losh wrote: > > > > > > > > On Fri, Apr 7, 2023 at 6:20?AM Poul-Henning Kamp > > wrote: > >> > >> > >> Alan Somers writes: > >> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp > >> > wrote: > >> > >> > > I would expect them to be

Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211

> > Emmanuel Vadot writes: > > On Thu, 02 Feb 2023 20:58:58 + > > "Poul-Henning Kamp" wrote: > > > > > > > > parv/FreeBSD writes: > > > > > > > > Does backlight(8) works for you? > > > > > > > > Thanks for the clue. It does! It does ... > > > > > > > > - I get the same

Re: CAM: extract HDD informations about failure/to fail?

> On Sun, Nov 27, 2022 at 8:15 AM FreeBSD User wrote: > > > Hello, > > > > well, the aim of my post sounds strange, but I'm serious. > > Background: I run at home a 14-CURRENT based server with a ZFS volume > > (RAIDZ) comprised from > > 4x 4 TB HDD. A couple of days I had to exchange the HGST

Re: dmesg content lifetime

> On 22 Nov 2022, at 9:34, Dan Mack wrote: > > > It disappears a piece at a time - the oldest entries disappear first. > > However, it vanishes even when there are only 2-3 lines in it so I didn't > > think capacity was in play as I expected. > > > > So for example I might see a rate-limit

Re: psm0: unable to allocate IRQ

> On 2022-10-02 17:45, Chris wrote: > > I've spent the last 2 days attempting to get a fresh install of > > stable/13-n252407-f42139db639 working on a Dell Inspiron 5755. > > Just attempted it again with the > 14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the > same results. Yet

Re: MCE: Does this look possibly like a slot issue?

> > > Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using all > the memory. Depending on the results of that one thing that is often overlooked when trying to trouble shoot memory systems in modern Intel systems is the fact that the DIMM now talks directly to the CPU chip that

Re: CURRENT doesn't recognise synaptics touchpad

> Hi all, > > I have another issue with my recent re-installation to Current: touchpad > support seems to have vanished. I know it works because the keyboard lights > up when I touch it, it also works under linux (dual-boot), and it worked > with the previous installation of FreeBSD, where I

Re: Future of ident(1)

Has anyone considered that ident(1) works on all the binaries produced by FreeBSD for the first 25 years it existed? Ie, you can run ident on a FreeBSD 1.0 binary... I also believe it can be run on binaries from many other systems. So though we have lost the data in FreeBSD 14, the other data

Re: Building ZFS disk images

> On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes > wrote: > > > > > On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston wrote: > > > > > > > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > > > > > There's this: > >

Re: Building ZFS disk images

> On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston wrote: > > > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > > > There's this: > > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . I > > > haven't used it myself. > > > > Would it be useful to have an rc.d

Re: [HEADSUP] making /bin/sh the default shell for root

> On 9/22/21 10:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be > > confusing > > as a default shell for many as all other unix like settled on a bourne

Re: [HEADSUP] making /bin/sh the default shell for root

> > Quoting Miroslav Lachman <000.f...@quip.cz>: > > > On 22/09/2021 22:50, grarpamp wrote: > >>> propose to make it the default shell for root starting FreeBSD > >>> 14.0-RELEASE > >> > >> Make it so. > >> > >> The whole rest of rc, pkg, base scripts and subsystems use a lot of > >> sh, not

Re: [HEADSUP] making /bin/sh the default shell for root

> On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > > Hello, > > > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > > > For years now, csh is the default root shell for FreeBSD, csh can be > > > confusing >

Re: Wi-Fi: HP ZBook 17 G2

> According to , iwm(4) > should work. > > Neither wpa_gui (with wpa_supplicant-devel 2021.06.14) nor > net-mgt/wifimgr can detect any network. > > What am I missing? I am not sure.. but... see below... > > /etc/rc.conf includes: > >

Re: PATH: /usr/local before or after /usr ?

> > > On Fri, 16 Jul 2021 09:01:49 -0600 > Alan Somers wrote: > > > FreeBSD has always placed /usr/local/X after /usr/X in the default > > PATH. AFAICT that convention began with SVN revision 37 "Initial > > import of 386BSD 0.1 othersrc/etc". Why is that? It would make > > sense to me that

Re: Files in /etc containing empty VCSId header

> On Thu, Jun 10, 2021 at 03:26:58PM -0700, Kevin Oberman wrote: > > On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin wrote: > > > > > > > On 9. Jun 2021, at 01:15, Ian Lepore wrote: > > > > > > > > ?On Tue, 2021-06-08 at 15:11 -0700, Rodney

Re: Files in /etc containing empty VCSId header

> On 2021-Jun-08 17:13:45 -0600, Ian Lepore wrote: > >On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote: > >> There is a command for that which does or use to do a pretty > >> decent job of it called whereis(1). > > Thanks. That looks useful. &g

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

> On 8 Jun, Michael Gmelin wrote: > > > > > > On Thu, 3 Jun 2021 15:09:06 +0200 > > Michael Gmelin wrote: > > > >> On Tue, 1 Jun 2021 13:47:47 +0200 > >> Michael Gmelin wrote: > >> > >> > Hi, > >> > > >> > Since upgrading servers from 12.2 to 13.0, I get > >> > > >> >

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

> > On Thu, 3 Jun 2021 15:09:06 +0200 > Michael Gmelin wrote: > > > On Tue, 1 Jun 2021 13:47:47 +0200 > > Michael Gmelin wrote: > > > > > Hi, > > > > > > Since upgrading servers from 12.2 to 13.0, I get > > > > > > Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe > > >

Re: Files in /etc containing empty VCSId header

> On Tue, 8 Jun 2021 09:41:34 + > Mark Linimon wrote: > > > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote: > > > Sometimes it's a real interesting exercise to figure out where a > > > file on your runtime system comes from in the source world. There is a command for that

Re: Alternate Screen

> There was a recent discussion about a terminal database update and the > new Alternate Screen behavior. I'm curious about the resolution, but I > can't find that discussion. Would someone kindly send a clue-by-four > via overnight express? > > Ultimately, I'd like to know how to get the

Re: RFC: changing the default NFSv4 minor version?

> Rodney W. Grimes wrote: > [stuff snipped] > >Daniel Ebdrup Jensen wrote: > >> Hi Rick, > >> > >> If I understand your plans correctly, you're not going to be making > >> it so that minorversion=N complains? > > > >Ah, I thi

Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu

> > On 2021-May-14, at 05:52, Rodney W. Grimes gndrsh.dnsmgr.net> wrote: > > >> Note: The context was using a non-debug main build > >> from mid-2021-Mar. (More details identified > >> later.) > >> > >> The issue happend wh

Re: RFC: changing the default NFSv4 minor version?

> On Thu, May 13, 2021 at 11:02:35PM +, Rick Macklem wrote: > >Hi, > > > >I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main. > >I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0. > >(In particular, the sessions mechanism for "exactly once RPC semantics"

Re: More rtsx issues (13.0-R system) was: Re: CURRENT crashes at early boot on Lenovo T540p...

> On 5/13/21 9:00 PM, Rodney W. Grimes wrote: > >> On 12.05.2021 21:01, Marc Veldman wrote: > >> > >>> I?m not sure if this is an interesting data point or not, > >>> but a warm boot without the card inserted succeeds after > >>> a cold b

Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu

> Note: The context was using a non-debug main build > from mid-2021-Mar. (More details identified > later.) > > The issue happend while attempting a: > > # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew > > where the drives involved in the command were: > > zpold: a USB3 SSD,

Re: HEADSUP: i2c(8) has been washed and ironed

> I have renovated the i2c(8) program and while I belive all argument > processing is 100% compatible, various undocumented aspects of the > program may have changed, amongst these precisely what goes to > stdout and stderr. > > Apologies if this breaks any of your scripts. > > > There is one

More rtsx issues (13.0-R system) was: Re: CURRENT crashes at early boot on Lenovo T540p...

> On 12.05.2021 21:01, Marc Veldman wrote: > > > I?m not sure if this is an interesting data point or not, > > but a warm boot without the card inserted succeeds after > > a cold boot with the card inserted. > > It could explain, why my tests with "same code path" gave different results! I am

Re: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!

> On 07.05.2021 14:36, Lev Serebryakov wrote: > > >> ?? Looks like there is problem with rtsx driver! > > ?Oh, I forgot to add: disabling SD Card Reader in BIOS solves problem! > > > > ?And console on these crashes is totally dead, and disks are not detected > > yet, so I can not look at

Re: sys/sys/param.h: 'main' instead of 'Master'?

> On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote: > > On Fri, 16 Apr 2021 at 16:22, Warner Losh wrote: > > > > > > > > As well as "Origin". > > > > > > > > (Single) Source of Truth, maybe? > > > > > > s/Master, p/P/ also makes sense. > > > > IMO instead of lightly rewording the

Re: sys/sys/param.h: 'main' instead of 'Master'?

> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: > > > > While viewing sys/sys/param.h I noticed that the comment of the > > definition of __FreeBSD_version is probably out of date. > > > > Since the switch to Git, doesn't it have to be 'main' instead of 'master'? > > > > This isn't based

Re: TCP Connection hang - MSS again

> 06.04.2021 19:54, Rodney W. Grimes wrote: > >> 05.04.2021 19:44, Rozhuk Ivan wrote: > >> > >>>>> As I understand, in some cases remote host does not reply with MSS > >>>>> option, and host behind router continue use mss 8960, that dropped

Re: TCP Connection hang - MSS again

> 05.04.2021 19:44, Rozhuk Ivan wrote: > > >>> As I understand, in some cases remote host does not reply with MSS > >>> option, and host behind router continue use mss 8960, that dropped > >>> by router. > >> If the peer does not provide an MSS option, your local FreeBSD based > >> host should

Re: FreeBSD 13.0-RC5 Now Available

> On 4/3/21 3:34 PM, Glen Barber wrote: > > The fifth RC build of the 13.0-RELEASE release cycle is now available. > > > > Beautiful. If we see RC8 then that is fine. Testing is a wonderful > process and I feel far better about a well tested release than an > instant "oops" with 13.1 kicked out

Re: testers needed: loader: use display pixel density for font autoselection

> > On 26. Feb 2021, at 17:56, Rodney W. Grimes > > wrote: > > > >>> On 26. Feb 2021, at 05:42, Rodney W. Grimes > >>> wrote: > >>> > >>>>> On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: > >>>

Re: KTLS with zfs recv

> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > My understanding is that KTLS works very well with OpenSSL for sending, > > but > > > not as well for receiving, because there's nothing like a recvfile

Re: KTLS with zfs recv

> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > My understanding is that KTLS works very well with OpenSSL for sending, > > but > > > not as well for receiving, because there's nothing like a recvfile

Re: KTLS with zfs recv

> My understanding is that KTLS works very well with OpenSSL for sending, but > not as well for receiving, because there's nothing like a recvfile > syscall. However, it works great for both send and receive with NFS, where > all the data remains in the kernel. What about zfs recv? A very common

Re: testers needed: loader: use display pixel density for font autoselection

> > On 26. Feb 2021, at 05:42, Rodney W. Grimes > > wrote: > > > >>> On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: > >>> > >>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote: > >>>> hi! > >>

Re: testers needed: loader: use display pixel density for font autoselection

> > On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: > > > > On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote: > >> hi! > >> > >> I have done some work to make font pickup a bit smarter (hopefully > >> better;), but my own ability to test is limited to one bugged supermicro > >>

Re: loader/boot fonts are painfully small (again)

> > > > On 11. Feb 2021, at 23:21, Yuri Pankov wrote: > > > > Lenovo P51 laptop, 15'' 4k (3840x2160) display. > > > > Booting from the latest available current snapshot (20210107), fonts > > were at least readable; updating to the latest bits (manually installing > > new loader as well) made

Re: cgit: orientation

> On Tue, Feb 9, 2021 at 5:52 PM Warner Losh wrote: > > > > > > > On Tue, Feb 9, 2021 at 5:47 PM Graham Perrin > > wrote: > > > >> Given this, for example: > >> > >> < > >> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c=stable%2F12 This link probably came from

Re: Failure of release build with release.sh on 14-CURRENT amd64

-- Start of PGP signed section. > On Mon, Feb 01, 2021 at 05:13:42PM -0800, Rodney W. Grimes wrote: > > >One could build your own local pkg repository that contained pkg > >and what ever other pkg's are needed during a make release and > >modify the /etc/pkg/Fr

Re: Failure of release build with release.sh on 14-CURRENT amd64

On some day Glen Barber wrote: > On Mon, Feb 01, 2021 at 09:38:33PM +, tech-lists wrote: > > On Mon, Feb 01, 2021 at 09:27:44PM +, Glen Barber wrote: > > > On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote: > > > > Found > > > > A pre-built version of pkg could not be found for

Re: Enabling AESNI by default

> We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS,

Re: Plans for git

> On Sat, Sep 19, 2020, 2:44 PM Lucas Nali de Magalh?es > wrote: > > > Just My 2?? > > > > On Sep 3, 2020, at 5:19 PM, Warner Losh wrote: > > > > ?On Thu, Sep 3, 2020 at 1:32 PM Chris wrote: > > > > On 2020-09-03 11:33, Kristof Provost wrote: > > > > On 3 Sep 2020, at 19:56, Chris wrote: > > >

Re: Deprecating ftpd in the FreeBSD base system?

> In message om> > , Ed Maste writes: > > FTP is (becoming?) a legacy protocol, and I think it may be time to > > remove the ftp server from the FreeBSD base system - with the recent > > security advisory for ftpd serving as a reminder. > > > > I've proposed adding a deprecation notice to the man

Re: Plans for git (was: Please check the current beta git conversions)

> > > > On Sep 1, 2020, at 10:59 PM, Greg 'groggy' Lehey wrote: > > > > On Tuesday, 1 September 2020 at 13:14:10 -0400, Ed Maste wrote: > >> We've been updating the svn-git converter and pushing out a new > >> converted repo every two weeks, and are now approaching the time where > >> we'd

Re: nightly snapshot for CURRENT ?

> On Mon, Jul 27, 2020 at 04:23:22PM +0200, Emmanuel Vadot wrote: > > On Mon, 27 Jul 2020 14:14:13 + > > Glen Barber wrote: > > > > > On Sat, Jul 25, 2020 at 12:29:42PM +0200, Emmanuel Vadot wrote: > > > > On Fri, 24 Jul 2020 22:28:39 + > > > > Glen Barber wrote: > > > > > > > > > On

Re: ipv6_ipfilter_rules= is obsolete ?

> In /etc/defaults/rc.conf I see this > > ipv6_ipfilter_rules="/etc/ipf6.rules" > # rules definition file for ipfilter, > # see /usr/src/contrib/ipfilter/rules for examples > > man 8 ipf says > > ipf -6 ipv4 and ipv6 rules are stored in a single table and can be read > from a single file.

Re: Undeletable files after kyua test runs

> Hi Kevin, > Hi David, > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > > I recently stumbled across undeletable files that are generated by kyua > > > test runs, > > > for example > > > > > > -rwxr-xr-x 1 root

Re: routed && route6d removal proposal

> 23.06.2020 2:26, Rodney W. Grimes wrote: > > >> 22.06.2020 19:49, Rodney W. Grimes wrote: > >>> Whats unmaintained about code that has no need to change cause it just > >>> pretty much works? > >> Have you actually tried running routed(8) as

Re: ? ????? ??: vnc can't connect to socket

> > On 21. Jun 2020, at 23:12, Rodney W. Grimes > > wrote: > > > >>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote: > >>>>> On 21. Jun 2020, at 14:28, Kostya Berger > >>>>> wrote: > >>>>> > &g

Re: routed && route6d removal proposal

> 22.06.2020 19:49, Rodney W. Grimes wrote: > > > Whats unmaintained about code that has no need to change cause it just > > pretty much works? > > Have you actually tried running routed(8) as base for real network with loops, > mix of p2p and ethernet-like int

Re: routed && route6d removal proposal

> Hey, > > I would like to propose removal of sbin/routed and usr.sbin/route6d. I disagree with removal, as your analysis is flawed. > routed(8) is the daemon implementing RIPv2 routing protocol. > route6d(8) is the daemon implementing RIPng routing protocol for IPv6. > > RIP [1] was one of

Re: ? ????? ??: vnc can't connect to socket

> > On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote: > > > > On 21. Jun 2020, at 14:28, Kostya Berger > > > > wrote: > > > > > > > > Ok, it turns out, it gives the previously mentioned error only if I > > > > use VNC server string 0.0.0.0:5900 (as I always did). in my VNC > > > >

Re: ? ????? ??: vnc can't connect to socket

> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote: > > > On 21. Jun 2020, at 14:28, Kostya Berger > > > wrote: > > > > > > Ok, it turns out, it gives the previously mentioned error only if I > > > use VNC server string 0.0.0.0:5900 (as I always did). in my VNC > > > client.But when

Re: CTF: UEFI HTTP boot support

st, there will be a review > request soon. :) You may want to look at /etc/rc.initdiskless, the /var and /etc population do have one existing solution. > > -Max > > On Wed, Jun 17, 2020 at 2:33 PM Miguel C wrote: > > > On Wed, Jun 17, 2020 at 9:28 PM Dave C

Re: CTF: UEFI HTTP boot support

> > > On Jun 17, 2020, at 12:12 PM, Warner Losh wrote: > > > > I missed the start of this thread, so maybe I'm missing a key detail. > > However, I thought UEFI didn't have a RAM-disk, per se, but that we could > > load memory areas and pass that into the kernel using freebsd-only methods. >

Re: CTF: UEFI HTTP boot support

> On Wed, Jun 17, 2020 at 11:53 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > Rodney W. Grimes wrote: > > > > > The "fake cd drive" is in the kernel, loader just copies the iso into > > > > > me

Re: CTF: UEFI HTTP boot support

> On Tue., Jun. 16, 2020, 8:35 a.m. Rodney W. Grimes, < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see > > > what the state of HTTP BOOT is in FreeBSD, so I bumped into this! > > >

Re: CTF: UEFI HTTP boot support

> Rodney W. Grimes wrote: > > > The "fake cd drive" is in the kernel, loader just copies the iso into > > > memory like any other module, and by the time that's done you just > > > reboot into the newly installed system, which again uses > > &g

Re: CTF: UEFI HTTP boot support

> On 6/16/20 5:17 AM, Miguel C wrote: > > > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see > > what the state of HTTP BOOT is in FreeBSD, so I bumped into this! > > > > I'm curious if it should be possible to point to a img/iso directly (I > > tried to use the img.xz

Re: CTF: UEFI HTTP boot support

> Rodney W. Grimes wrote: > > > Are you refering to something like: > > > > > > vfs.root.mountfrom="cd9660:/dev/md0.uzip" > > > > > > we boot that way all the time. > > > > What provides the cd9660 driver to FreeBSD?

Re: CTF: UEFI HTTP boot support

> On Tue, Jun 16, 2020, 17:53 Miguel C wrote: > > > On Tue, Jun 16, 2020 at 4:35 PM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see > > > >

Re: CTF: UEFI HTTP boot support

> Rodney W. Grimes wrote: > > > I'm curious if it should be possible to point to a img/iso directly (I > > > tried to use the img.xz unpacked it and make it available on a local web > > > server and that didn't seem to work for me) but maybe thats cause those &

Re: CTF: UEFI HTTP boot support

> I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see > what the state of HTTP BOOT is in FreeBSD, so I bumped into this! > > I'm curious if it should be possible to point to a img/iso directly (I > tried to use the img.xz unpacked it and make it available on a local web >

Re: nightly snapshot for CURRENT ?

> On Tue, 9 Jun 2020 19:56:30 + > Glen Barber wrote: > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > > > Hello all, > > > > > > I've just hit again something that I've hit (and probably others too) > > > often. > > > If a change in base break some ports and

Re: Office Hours today @ 18:00 UTC - Core Candidates

-- Start of PGP signed section. > On 2020-05-27 22:01, Philip Paeps wrote: > > On 2020-05-27 22:35:14 (+0800), Allan Jude wrote: > >> Sorry for the late notice, I thought I sent this last week. > >> > >> After the slate of candidates was finalized last week, I invited all of > >> them to join a

Re: Move from termcap(5) to terminfo(5)

> Hello everyone, > > I can't find any proper rationale in our history (maybe I missed it) which > explains why our ncurses is stuck on using termcap(5) instead of terminfo(5) > Except an argument in the Makefile that builds ncurses: > "Used instead of the hideous read_termcap.c abomination." >

Re: sysutils/screen-ncurses port

> On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote: > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste > > Daroussin wr > > ites: > > > > > > > > > --vwrr5drfobpkyvop > > > Content-Type: text/plain; charset=us-ascii > > > Content-Disposition: inline > > >

Re: How to enable tcp bbr in FreeBSD???

> On Fri, Apr 24, 2020 at 01:31:35PM +0200, Kurt Jaeger wrote: > > > > Thanks. Is BBR active automatically or is there a sysctl or > > socket option to activate it ? > > net.inet.tcp.cc.available: List available congestion control algorithms > net.inet.tcp.cc.algorithm: Default congestion

Re: OpenZFS port updated

> FreeBSD support has been merged into the master branch of the openzfs/zfs > repository, and the FreeBSD ports have been switched to this branch. > > OpenZFS brings many exciting features to FreeBSD, including: > * native encryption > * improved TRIM implementation > * most recently,

Re: sort.core error doing installworld on Current.

> > > > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes: > > >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman > > >> wrote: > > >> > > >>> So you some how had a sort core dump sitting in > > >>> /usr/obj/usr/src/amd6

Re: sort.core error doing installworld on Current.

> > Op 17-04-2020 om 03:31 schreef Rodney W. Grimes: > >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: > >> > >>> So you some how had a sort core dump sitting in > >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The que

Re: sort.core error doing installworld on Current.

> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: > > > So you some how had a sort core dump sitting in > > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how > > did get there? I'd take a look at the date on the file and, it it is older > > than the buildworld, just

Re: Working on Zoom port

> All, > > Given how Zoom is getting used a lot more these days, I've started > working on a port that installs the Zoom linux client. > > Here is a link to my github if anyone wants to help: > > https://github.com/emc2/freebsd-ports/tree/zoom > > > I'm not done yet. The zoom linux client

Re: buildkernel failure because ctfconvert not installed

> On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri > > Pankov writes: > > > >Trond Endrest?l wrote: >

Re: buildkernel failure because ctfconvert not installed

> > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov > writes: > >Trond Endrest?l wrote: > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > >> > >>> OK, I figured it out. > >>> > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to >

Re: ZFS: OpenZFS: lost the ability to boot a BE

> To temporarily mount a ZFS filesystem: > > mount -t zfs poolname/data/set /path/here Is there anyway to get the zfs command to add mountpoint as a temporary value like it does some of the others so that zfs mount -o mountpoint=/mnt poolname/data/set would just do the right thing? > > > On

  1   2   3   4   5   >