en solved with git:
2be8b121bf82 - main - mtw(4) remove misplaced DEBUG_FLAGS
>
>
>
> Van: A FreeBSD User
> Datum: 7 februari 2025 17:12
> Aan: Ronald Klop
> CC: FreeBSD CURRENT
> Onderwerp: Re: make installkernel: failure: install:
> /usr/lib/d
ng most recent
CURRENT, but
updated (buildworld/buildkernel) within the past two weeks more often does not
show this nasty
problem, althoug having the very same setup scheme - except the kernel name is
different
(hardware quite the same ancient crap, brand, model ...).
This drives me nuts ...
&g
Am Fri, 7 Feb 2025 16:47:14 +0100
A FreeBSD User schrieb:
> Am Fri, 7 Feb 2025 14:45:04 +0100
> A FreeBSD User schrieb:
>
> > Am Fri, 7 Feb 2025 14:08:24 +0100 (CET)
> > Ronald Klop schrieb:
> >
> > > Does it work if you just do
> > >
> >
ES
#PXEBOOT_DEFAULT_INTERP=4th
LOADERSIZE?=525000
#
WITH_BHYVE_SNAPSHOT=YES
#
NOINSTALL_DEBUG=YES
KERNCONF= WALHALL
KERNCONFDIR=/etc/config/amd64/kernel_conf/
>
>
> Van: A FreeBSD User
>
Am Fri, 7 Feb 2025 14:45:04 +0100
A FreeBSD User schrieb:
> Am Fri, 7 Feb 2025 14:08:24 +0100 (CET)
> Ronald Klop schrieb:
>
> > Does it work if you just do
> >
> > mkdir -p /usr/lib/debug/boot/kernel/
> >
> > and restart the make installkernel?
> &
hour on my 12 years old hardware ;-)
Will report in when finished/failes again ...
Kind regards,
Oliver
>
>
> Van: A FreeBSD User
> Datum: vrijdag, 7 februari 2025 13:56
> Aan: FreeBSD CURRENT
> Onderwerp: make installkernel: failure: install: /usr/lib/debug/boot/kernel:
> N
;make
installworld", but I do not know wether the failure shown is a typical/well
known symptome.
Any tips and tricks to fix this nasty failure?
Thanks in advance
o.h.
--
A FreeBSD user
pgp9f_MZ7GWGm.pgp
Description: OpenPGP digital signature
Am Tue, 4 Feb 2025 12:18:06 +0200
Andriy Gapon schrieb:
> On 01/02/2025 10:57, A FreeBSD User wrote:
> > Hello, this exactly happens when trying to import the pool. Prior to the
> > loss, device da1p1
> > has been faulted with numbers in the colum/columns "corrupted d
e to have. In
> any case, it really does look like you have _more_ than one failure in
> there somewhere and only dmesg and some separate tests on each device
> would reveal the truth.
>
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
>
>
Hello all!
Thank you for your tips!
Luckily, "zpool import -FX" as suggested herein did after a while (60-80
minutes) the trick!
There might be some data losses - but compared to the alternative bareable.
Thank you very much!
Kind regards,
Oliver
--
A FreeBSD user
pgpjJNJcj6hIz.pgp
Description: OpenPGP digital signature
Am Thu, 30 Jan 2025 16:13:56 -0500
Allan Jude schrieb:
> On 1/30/2025 6:35 AM, A FreeBSD User wrote:
> > Am Wed, 29 Jan 2025 03:45:25 -0800
> > David Wolfskill schrieb:
> >
> > Hello, thanks for responding.
> >
> >> On Wed, Jan 29, 2025 at 11:27:01A
Am Wed, 29 Jan 2025 03:45:25 -0800
David Wolfskill schrieb:
Hello, thanks for responding.
> On Wed, Jan 29, 2025 at 11:27:01AM +0100, FreeBSD User wrote:
> > Hello,
> >
> > a ZFS pool (RAINDZ(1)) has been faulted. The pool is not importable
> > anymore. neither with
ry to "de-fault" such a pool.
The pool is comprised from 7 drives as a RAIDZ1, one of the SSDs
faulted but I pulled the wrong one, so the pool ran into suspended
state.
The host is running the lates Xigmanas BETA, which is effectively
FreeBSD 14.1-p2, just for the record.
I do not want to g
Am Wed, 11 Dec 2024 14:25:02 +0100
Ronald Klop schrieb:
> Op 09-12-2024 om 19:24 schreef Juraj Lutter:
> >
> >
> >> On 9 Dec 2024, at 19:19, FreeBSD User wrote:
> >>
> >> Am Tue, 10 Dec 2024 02:27:10 +0900
> >> Tomoaki AOKI schrieb:
> &
o...@freebsd.org
>
> I think would usually work for clients with some limited services
> exposed to outside. IIUC, it basically allow all sessions from inside
> and allows limited serivices configured with variables
> via /etc/rc.conf[.local].
>
> Some notes.
> *L
c/sysctl.conf.local ]
security.mac.bsdextended.enabled=0
security.mac.mls.enabled=0
security.mac.portacl.enabled=0
security.mac.do.enabled=0
security.mac.ipacl.ipv6=0
security.mac.ipacl.ipv4=0
#
net.bpf.optimize_writers=1
#
net.inet.ip.fw.verbose=1
#net.inet.ip.fw.verbose_limit=10
net.inet.ip.fw.
On Thu, 5 Dec 2024 16:55:00 +0100
Daniel Tameling wrote:
> On Thu, Dec 05, 2024 at 11:51:03AM +0100, FreeBSD User wrote:
> > On Wed, 04 Dec 2024 17:20:39 +
> > "Dave Cottlehuber" wrote:
> >
> > Thank you very much for responding!
> >
>
On Wed, 04 Dec 2024 17:20:39 +
"Dave Cottlehuber" wrote:
Thank you very much for responding!
> On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote:
> > On most recent CURRENT (on some boxes of ours, not all) fetch/git seem
> > to be stuck
> > forever fetchin
On most recent CURRENT (on some boxes of ours, not all) fetch/git seem to be
stuck
forever fetching tarballs from ports, fetching Emails via claws-mail (TLS),
opening
websites via librewolf and firefox or pulling repositories via git.
CURRENT: FreeBSD 15.0-CURRENT #1 main-n273978-b5a8abe9502e
ppens on stable/14:
> > > >
> > > > ===> stand/i386/pxeldr (all)
> > > > -22344 bytes available
> > > > ===> share/misc (all)
> > > > --- loader ---
> > > > *** [loader] Error code 1
> > > >
ppens on stable/14:
> > > >
> > > > ===> stand/i386/pxeldr (all)
> > > > -22344 bytes available
> > > > ===> share/misc (all)
> > > > --- loader ---
> > > > *** [loader] Error code 1
> > > >
mpi3mr_dprint(sc, MPI3MR_ERROR, "[%2d] outstanding IOs
> present on
> target: %d "
> + "despite poll\n", target_outstanding,
> target->per_id);
> + }
>
> if (target->exposed_to_os && !sc-
Am Tue, 04 Jun 2024 09:36:38 +0200
Alexander Leidinger schrieb:
> Am 2024-06-03 21:02, schrieb FreeBSD User:
> > Hello,
> >
> > I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running
> > several jails. Jails are
> > attached to a bridge de
Hello,
I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running several
jails. Jails are
attached to a bridge device (bridge1), the physical device on that bridge is
igb1 (i350 based
NIC). The bridge is created via host's rc scripts, adding and/or deleting epair
members of the
brid
Hello,
for customising my world and kernel, I try to "overlay" GENERIC via included
files containing
"nodevice" and "nooptions" tags starting from a top level config file like
include GENERIC
include NODEVICE-GENERIC
include SPECIAL
Within "NODEVICE-GENERIC" I utilize
[...]
# Debugging support.
Am Sun, 26 May 2024 09:29:08 +0200
Bojan Novković schrieb:
> Hi,
>
> da76d349b6b1 replaced a UMA-related symbol but missed three instances
> where the old one was used, ultimately causing the wrong UMA page
> allocator to get selected and crashing the machine.
>
> I tested this patch as a par
Am Sun, 26 May 2024 14:45:37 +0200
"Herbert J. Skuhra" schrieb:
> On Sun, May 26, 2024 at 02:35:16PM +0200, FreeBSD User wrote:
> > Hello,
> >
> > boxes running CURRENT are last good with FreeBSD 15.0-CURRENT #44
> > main-n270400-02d15215cef2: Sat May 25
Am Sat, 27 Apr 2024 11:28:55 +0200
FreeBSD User schrieb:
Just for the record: running a small "victim NAS" based on an HP EliteDesk 800
G2 mini,
XigmaNAS (latest official version, kernel see below), installing packages from
an official
FreeBSD site for FBSD 13.2-RELEASE, gives me o
uple of
months ago.
AGAIN: ALL chips do not communicate with my private hosts (dmesg: CPU
microcode: updated from
0x1f to 0x21 CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.18-MHz K8-class
CPU)), OS:
FreeBSD 15.0-CURRENT #39 main-n269723-4ba444de708b: Sat Apr 27 06:42:44 CEST
2024 amd64,
Hello,
Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: Thu Apr
25 18:48:56
CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at hand).
Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 notebook,
Fujitsu Esprimo Q5XX
(simple desktop, Pentium
ame 0xfe048c204c90
> D> sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfe048c204e00
> D> amd64_syscall() at amd64_syscall+0x158/frame 0xfe048c204f30
> D> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe048c204f30
> D> --- syscall (154, FreeBS
Am Tue, 9 Apr 2024 17:10:52 +0200
Rainer Hurling schrieb:
> Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:
> > On Sat 06 Apr 09:23, Rainer Hurling wrote:
> >> Am 06.04.24 um 09:05 schrieb FreeBSD User:
> >>> Hello,
> >>>
> >>> afte
Am Sat, 6 Apr 2024 09:05:00 +0200
FreeBSD User schrieb:
> Hello,
>
> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
> on CURRENT and
> 14-STABLE, I can't update several ports:
>
> www/apache24
> databases/redis
>
> pkg co
Am Thu, 4 Apr 2024 01:14:52 -0500
Kyle Evans schrieb:
> On 4/4/24 00:49, FreeBSD User wrote:
> > Hello,
> >
> > I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
> >
> >
4-STABLE and CURRENT boxes (both OS variants latest
builds, i.e. FreeBSD
15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr 5 20:30:39 CEST 2024
amd64).
After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG jail
with poudriere)
building packages for 14.0-RELENG, I observed
Am Thu, 04 Apr 2024 08:06:26 +0200 (CEST)
sth...@nethelp.no schrieb:
> >> I have to report to my superiors (we're using 14-STABLE and CURRENT
> >> and I do so in private),
> >> so I would like to welcome any comment on that.
> >
> > No it does not
ks. I am using NFSv3
> >>>
> >>> Peter
> >>>
> >>>
> >>>
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 2; apic id = 04
> >>> fault virtual address = 0x89
> >
b7e
> > #7 0x804b9d90 at nfs_readdir+0x1f0
> > #8 0x8069c61a at vop_sigdefer+0x2a
> > #9 0x809f8ae0 at VOP_READDIR_APV+0x20
> > #10 0x81ce75de at autofs_readdir+0x2ce
> > #11 0x809f8ae0 at VOP_READDIR_APV+0x20
> > #12 0
Am Sun, 14 Jan 2024 20:34:12 -0800
Cy Schubert schrieb:
> In message om>
> , Rick Macklem writes:
> > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop =
> > wrote:
> > >
> > >
> > > Van: FreeBSD User
> > > Datum: 13 januari 2024
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET)
Felix Reichenberger schrieb:
> > Hello,
> >
> > I've got a problem with recent CURRENT, running vnet JAILs.
> > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> > 2024 amd64
> >
> >
Am Sat, 13 Jan 2024 19:41:30 -0800
Rick Macklem schrieb:
> On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote:
> >
> >
> > Van: FreeBSD User
> > Datum: 13 januari 2024 19:34
> > Aan: FreeBSD CURRENT
> > Onderwerp: NFSv4 crash of CURRENT
> >
>
Hello,
I've got a problem with recent CURRENT, running vnet JAILs.
FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024
amd64
Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP
and ICMP
(ipfw is configured via rc.conf in this case,
Am Thu, 23 Nov 2023 20:37:26 +0100
FreeBSD User schrieb:
> Hello,
>
> I'm facing some strange behaviour when connecting to a CP2102 USB-UART bridge
> built-in into
> a I2C-USB device (I2C is handled by an Amtel88, USB-UART is handled by an
> CP2102, see here:
>
&
Hello,
at first: observation is below, marked [OBSERVATION].
Running recent CURRENT (FreeBSD 15.0-CURRENT #26 main-n265831-3523f0677ef: Mon
Oct 9 14:00:42
CEST 2023 amd64), I've configured a bridge (bridge0), the hosts's interface
igb0 (I350-T2 two
port Gigabit Network Connection )
Am Fri, 30 Jun 2023 16:45:52 +0200
Pierre Pronchery schrieb:
My apology for the delay.
Shortly after the post here and several patches the problem vanished into thin
air - alos by
using tigervnc as the client and not, as proposed on the FreeBSD Wiki page,
xfreerdp.
Thank you very much for
Am Thu, 29 Jun 2023 16:41:51 +0200
Guido Falsi schrieb:
> On 29/06/23 16:35, FreeBSD User wrote:
> > Hello,
> >
> > running a recent CURRENT, 14.0-CURRENT #10 main-n263871-fd774e065c5d: Thu
> > Jun 29 05:26:55
> > CEST 2023 amd64, xfreerdp (net/freerdp) d
C is not an option in any way.
Is there any way to access the bhyve guest's native graphical interface? As in
the PR shown
above already documented (setup taken from the FreeBSD Wiki/bhyve), a
framebuffer is already
configured.
It would be nice if someone could give a hint.
Thanks in advance,
oh
--
O. Hartmann
On Sun, Jun 25, 2023 at 5:10 PM Kyle Evans wrote:
Hi Kyle,
Thanks for the response.
On 6/24/23 04:06, parv/FreeBSD wrote:
> > On Thu, Jun 15, 2023 at 1:14 AM parv/FreeBSD wrote:
> >
> > Hi there,
> >
> > I am stuck in "installworld" step due
On Thu, Jun 15, 2023 at 1:14 AM parv/FreeBSD wrote:
> Hi there,
>
> I am stuck in "installworld" step due to
> ERROR-tried-to-rebuild-during-make-install when going
> from 1cebc9298cf to b98fbf3781 on one host, or from
> 9fbeeb6e3831 to dfa1982352ee on another host.
*sigh* Attachments did not seem to make the list archive ...
On Thu, Jun 15, 2023 at 1:14 AM parv/FreeBSD wrote:
> I am stuck in "installworld" step due to
> ERROR-tried-to-rebuild-during-make-install when going
> from 1cebc9298cf to b98fbf3781 on one host, or from
> 9fbeeb
-m 0755 -o root -g wheel /boot
install -o root -g wheel -m 444 loader.help.efi /boot/loader.help.efi
cc -target x86_64-unknown-freebsd14.0
--sysroot=/build/world/freebsd/src/amd64.amd64/tmp
-B/build/world/freebsd/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common
-Wformat -fshort-wchar -mn
Am Wed, 31 May 2023 12:15:12 -0600
Warner Losh schrieb:
Sorry for the late response.
> On Mon, May 29, 2023 at 2:59 AM FreeBSD User wrote:
>
> > Hello,
> >
> > on CURRENT, enabling in /etc/src.conf
> >
> > WITH_BEARSSL=
> >
> > seems to re
Wrote Dimitry Andric on Fri, 21 Apr 2023 10:38:05 UTC
(via
https://lists.freebsd.org/archives/freebsd-current/2023-April/003556.html )
>
> ... However, I have read that with unicode, you should *never*
> use [A-Z] or [0-9], but character classes instead. That seems to give
> both fi
Am Sat, 15 Apr 2023 07:36:25 -0700
Cy Schubert schrieb:
> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
> FreeBSD Us
> er writes:
> > Am Thu, 13 Apr 2023 22:18:04 -0700
> > Mark Millard schrieb:
> >
> > > On
Am Thu, 13 Apr 2023 22:18:04 -0700
Mark Millard schrieb:
> On Apr 13, 2023, at 21:44, Charlie Li wrote:
>
> > Mark Millard wrote:
> >> FYI: in my original report for a context that has never had
> >> block_cloning enabled, I reported BOTH missing files and
> >> file content corruption in the
Am Sun, 9 Apr 2023 14:37:03 +0200
Mateusz Guzik schrieb:
> On 4/9/23, FreeBSD User wrote:
> > Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b:
> > Sun Apr 9
> > 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via
> >
> > zpool up
Am Thu, 30 Mar 2023 17:27:31 +0200
Dag-Erling Smørgrav schrieb:
> FreeBSD User writes:
> > I tried to put the option
> >
> > WITHOUT_MODULE="an"
>
> it's spelled WITHOUT_MODULES, cf. make.conf(5).
>
> DES
Correct, and so I use it ... ;-)
Am Thu, 30 Mar 2023 15:53:19 +0200
Mateusz Guzik schrieb:
> On 3/30/23, FreeBSD User wrote:
> > Hello folks,
> >
> > some strange misbehaviour in a NanoBSD compilation is driving me nuts.
> > Recently I posted some
> > error messages regarding
> >
> &g
Am Thu, 30 Mar 2023 16:56:09 +0200
Mateusz Guzik schrieb:
> On 3/30/23, Mateusz Guzik wrote:
> > On 3/30/23, FreeBSD User wrote:
> >> Hello folks,
> >>
> >> some strange misbehaviour in a NanoBSD compilation is driving me nuts.
> >> Recentl
,-Wdeprecated-non-prototype]
[...]
but being able compiling the kernel was "a lucky shot/mistake" and in the vain
of discussion
it has been revealed that my nanoBSD specific "make.conf/src.conf"
configurations were wrong.
So, again:
The builder host is a recent CURRENT (Fre
Am Wed, 8 Mar 2023 12:13:49 +0100
tue...@freebsd.org schrieb:
> > On 8. Mar 2023, at 11:42, FreeBSD User wrote:
> >
> > Am Wed, 8 Mar 2023 11:28:11 +0100
> > Dimitry Andric schrieb:
> >
> >> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> >>
Am Wed, 8 Mar 2023 11:28:11 +0100
Dimitry Andric schrieb:
> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> ...
> > But I don't understand why the make environment is trying to compile a
> > piece of code that
> > is disabled via "nodevice&quo
Am Thu, 2 Mar 2023 11:13:51 +0100
Dimitry Andric schrieb:
> On 2 Mar 2023, at 06:41, FreeBSD User wrote:
> >
> > Am Mon, 27 Feb 2023 23:46:21 +0100
> > Dimitry Andric schrieb:
> ...
> >
> > I tried to find some documentation on my CURRENT host r
Am Thu, 2 Mar 2023 11:13:51 +0100
Dimitry Andric schrieb:
> On 2 Mar 2023, at 06:41, FreeBSD User wrote:
> >
> > Am Mon, 27 Feb 2023 23:46:21 +0100
> > Dimitry Andric schrieb:
> ...
> >
> > I tried to find some documentation on my CURRENT host r
Am Mon, 27 Feb 2023 23:46:21 +0100
Dimitry Andric schrieb:
> On 27 Feb 2023, at 22:23, Paul Mather wrote:
> >
> > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote:
> >
> >> On 27 Feb 2023, at 19:19, FreeBSD User wrote:
> >>>
> >>>
Am Mon, 27 Feb 2023 20:57:19 +0100
Dimitry Andric schrieb:
> On 27 Feb 2023, at 19:19, FreeBSD User wrote:
> >
> > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23
> > main-n261147-b8bb73ab724b: Sun
> > Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13
Hallo everybody,
a week ago I compiled a new 13-STABLE (FreeBSD 13.2-STABLE #77
stable/13-n254681-44a6088278ea:
Sat Feb 25 07:44:36 CET 2023 amd64, custom kernel, same happens with the recent
regular
GENERIC kernel). ZFS root installation.
Graphics driver:
drm-510-kmod-5.10.163_2
g as I finish my work. The I hope I can provide
you with a
backtrace. cpu-data has been updated recently, I use this on these two
IvyBridge methusalem
riggs, I may disable this first and see what happens ...
Regards
oh
>
> rick
>
> On Sun, Feb 19, 2023 at 1:38 AM FreeBSD User wrote
Am Sun, 19 Feb 2023 13:30:13 +0300
"Andrey V. Elsukov" schrieb:
> 18.02.2023 18:42, FreeBSD User пишет:
> > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN
> > interface. We use NPTv6 to translate ULA addresses for the inner
> > IPv6 networks.
Hello,
most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode,
used after
repairing failed FFS filesystems, is all right). The crashes go on since
roughly a 1/2 week
from now. The boxes involved are all cumtomized kernels (in most cases hard
linked modules
into kernel). Is
Hello,
running a small nanoBSD firewall/router appliance, the WAN interface (tun0) is
confugred via
SLAAC when it comes to IPv6. The allpliance is running in-kernel compiled IPFW.
The OS is
FreeBSD 13-STABLE, compiled on a recuurant weekly basis.
On a 24 hour basis, the ISP changes the IPv4
I should have requested in OP to CC to me as I have subscribed to
-current@ list without receiving email.
So here is my attempt to craft a reponse from the web page ...
https://lists.freebsd.org/archives/freebsd-current/2023-January/003142.html
> Oleksandr Kryvulia wrote on 20230131-092
Hi there,
Since around 2022-11, I am unable to change display brightness
of the display of a Framework laptop (Intel i5-1135G7, Iris
Xe iGPU) with "i915kms" module (from "drm-510-kmod" package/port)
& "acpi_video" (FreeBSD) kernel module.
Earlier I
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 NAS drives since one
got a permanent
SMART error. So all HDDs have been replaced
Hello folks,
I ran today into a problem, that the reolveer option "edns0" isn't documented
(as well as some
others). Searching the net reveals, that there is a PR open with exactly that
issue since
January 2016, since then, code has changed I presume.
Could someone please take care of that issu
it out if they want. If there's enough interest I'd be
> willing to commit it.
>
> We have a few options on the table and probably more. The ports
> infrastructure option is probably the most work. Adding functionality to
> all the ports that use /var/run is also a lot of work and if relying on
> individual porters, will likely take some time and be varied in
> implementation and robustness.
>
>
I'd like to add a sidenote here, if one may please.
Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var
reside on a memory
disk and the way NanoBSD handles /var, contradicts some claims that is is
'unsupported' to put
/var on a volatile memory infrastructure.
On the other hand, there are only few ports which create subfolders to, i.e.,
/var/run not
congruent what the specific metree sketch implies, the port security/clamav is
one of those
few.
The question that bothers me most and this is just from the pratical point of
view as stated
initially and from a second view, just out of curiosity:
what (fatal?) implications does it have to create some folders by port's
rc-script in /var/run
or whatever folder is needed to be on a volatile memory device for FreeBSD base
system's mtree
infrastructure?
--
O. Hartmann
Am Sat, 27 Aug 2022 13:16:43 +0200
tue...@freebsd.org schrieb:
> > On 27. Aug 2022, at 08:30, FreeBSD User wrote:
> >
> > Hello,
> >
> > I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> >
> > Port security/clamav is without doubt for m
Am Sat, 27 Aug 2022 11:21:40 +0200
Michael Gmelin schrieb:
> > On 27. Aug 2022, at 08:31, FreeBSD User wrote:
> >
> > Hello,
> >
> > I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> >
> > Port security/clamav is without doubt for m
Hello,
I'm referencing to Bug 259699 [2] and Bug 259585 [1].
Port security/clamav is without doubt for many of FreeBSD users an important
piece of security
software so I assume a widespread usage.
It is also a not uncommon use case to use NanoBSD or any kind of
low-memory-foot
Hello,
I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox
4.1.24/26 (do not know
exactly). The host is a special system based on Linux und VirtualBox and I have
no chances to
configure the VBox.
Somehow the VBox crashed and hung up the complete computer, so I had to
Am Sun, 3 Jul 2022 11:57:33 +0200
FreeBSD User schrieb:
Sorry for the noise, the learning process is still in progress and I learned
about the
until-now-not-fully-understood V4: entry in /etc/exports.
Thanks for reading and patience.
regards,
oh
> Hello folks,
>
>
> Trying to
Hello folks,
Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from a
recent CURRENT
(FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul 2 23:31:53 CEST
2022 amd64) via
:/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt
results in
mount_nfs
Hello,
the problem I'm about to report is not specific to CURRENT, I report this to
CURRENT
because I'm list member. The problem occurs on FreeBSD 12.3-RELEASE-p5.
Setup: connecting to vnet jails bound to a dedicated NIC via if_bridge results
in an
erratic behaviour (from my poi
On Thu, 28 Apr 2022 13:36:21 -0600
Alan Somers wrote:
> On Thu, Apr 28, 2022 at 1:29 PM Marek Zarychta
> wrote:
> >
> > W dniu 28.04.2022 o 21:21, FreeBSD User pisze:
> > > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to
> > > res
Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue
them and
store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3
obviously
lack in some etx2 features, namely "needs_recovery". The kernel reports:
WARNING: mount of da4p
On Tue, 19 Apr 2022 06:48:04 -0600
Warner Losh wrote:
Hello again,
I'm on 13-STABLE, version FreeBSD 13.1-STABLE #30
stable/13-n250552-364a69a529b: Tue Apr 26 07:32:42 CEST 2022 amd64 (builder
host). Sources for a NanoBSD of 13.0-RELENG (latest as of today) doesn't build,
still th
On Fri, 1 Apr 2022 12:09:21 -0400
Ed Maste wrote:
> On Fri, 1 Apr 2022 at 12:04, FreeBSD User wrote:
> >
> > I tried the patch given at the URL above (Phabricator). Patch applied on
> > recent CURRENT and trying to "make installworld" leaves me with this error
-RELENG on a
CURRENT host (recent 14-CURRENT!) works without problems.
On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu Apr 14
10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails!
On building from sources 13.0-RELENG I receive while in installworld
ething, pam_env isn't available on FreeBSD)?
If this is a trivial issue and caused by lack of my personell knowledge, please
excuse.
Kind regards,
O. Hartmann
Am Fri, 1 Apr 2022 10:08:11 -0400
Ed Maste schrieb:
> On Fri, 1 Apr 2022 at 10:00, Jens Schweikhardt
> wrote:
> >
> > Hello *,
> > Looks like a semicolon is missing after the "fi".
>
> Indeed, and there was a close bracket missing as well. I've put a
> (hopefully) fixed version in review at
>
Am Fri, 1 Apr 2022 16:00:10 +0200 (CEST)
Jens Schweikhardt schrieb:
> Hello *,
> Looks like a semicolon is missing after the "fi".
> Jens
>
> - Ursprüngliche Mail -
> Von: "Ed Maste"
> An: "FreeBSD User"
> CC: "freebsd-curr
On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022
amd64, it is without any problem possible to build most recent 13-STABLE
sources as of today (stable/13-n250195-26e8bb3a4e1).
On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 2022
amd64 this is not po
On Mon, 28 Feb 2022 17:11:27 +0100
Michael Gmelin wrote:
[...]
schnipp
[...]
> >
> > poudriere jail -l:
> >
> > # poudriere jail -l
> > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> > 123-amd64 12.3-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> > 14:1
d on the native CURRENT "jailed poudriere" builder
and also
following this reference (for those who want to check on this)
https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
which seems quite recent and with the exception, that we use "vnet" o
With mergin a recent commit today involving /usr/src/sys/x86/x86/tsc.c of
FreeBSD
13-STABLE, compiling the kernel results in the error shown below:
[...]
cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O3 -pipe
changing the defaults, but you need to ensure
that reasonable scenarios, like the changed FreeBSD client mounting
from v3-only server, still work correctly. The change should be made in a
way that only affects client that connects to the server that has both
v4 and v3.
A particular test case that needs
; @(#)mount_nfs.8 8.3 (Berkeley) 3/29/95
.\" $FreeBSD$
.\"
-.Dd July 10, 2021
+.Dd January 10, 2022
.Dt MOUNT_NFS 8
.Os
.Sh NAME
@@ -216,8 +216,8 @@ This option requires the
.Cm nfsv4
option.
.It Cm nfsv2
-Use the NFS Version 2 protocol (the default is to try version 3 first
-then
gt;>> binary.
>>> The resulting binary has the associated paths (/lib/libc++.so.1 and
>>> /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so to be
>>> in /usr/lib. This is the same with /usr/lib/libc.so vs /lib/libc.so.7.
>>>
>>>
b/libc.so.7.
>>
>> However, your point about libcxxrt.so.1 is valid. It needs to also be moved
>> to /lib if libc++.so.1 is moved to /lib. Doing so will also require yet
>> another
>> depend-clean.sh fixup (well, probably just adjusting the one I added to
>>
to be
> in /usr/lib. This is the same with /usr/lib/libc.so vs /lib/libc.so.7.
>
> However, your point about libcxxrt.so.1 is valid. It needs to also be moved
> to /lib if libc++.so.1 is moved to /lib. Doing so will also require yet
> another
> depend-clean.sh fixup (well, pro
t what specific, detailed
issue(s) the move to /lib/libc++.so.1 covers vs. not,
given the /usr/lib/libc++.so and /usr/lib/libcxxrt.so
paths.
I'm not using anything with /usr/lib/ being on a different
file system than /lib so I'll definitely not observe any
problems. And it might be a waste
1 - 100 of 5970 matches
Mail list logo
