Bug 206165 - resolv.conf(5) is missing documentation on options (i.e. EDNS0)

[FreeBSD User]

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 issue? "man 5 resolver" does not cover 
all options one
can provide via /etc/resolv.conf, see 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165

Thank you very much in advance,

O. Hartmann


-- 
O. Hartmann

CAM: extract HDD informations about failure/to fail?

[FreeBSD User]

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 by now with four times Seagte 
IronWolfe Pro 4TB
drives. So far, so good.
Now I face a weird sound sourcing at one of the new HDDs. The box is supposed 
to be a heavy
duty poudriere build facility, so the drives are up 24/7. It seems that one (or 
even more)
drives emitt a weird sound like the spindle motor is loosing for a fraction of 
a second power
and spiining up the the drive again. Searching the net reveals that at least 
one Seagate
customer did have the same issue and he provided an audio file of that very 
weird sound, to be
found here:

Post at reddit:
 
https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/

and herin the post of the audio file:

 https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file

I checked S.M.A.R.T for any unusual data, but everything is fine. The values 
for 

Power_Cycle_Count
Power-Off_Retract_Count
Start_Stop_Count

seem all within a reasonable range compared to the life time in hours (did some 
simple
statistsics ), nothing looks unusual.

Also, the advanced view onto each drive via 

smartctl -x

doesn't give me any hint of a power failure as a source for the noise.

So, big question here is: the drives are attached to a HBA, LSI3008 based 
SAS9300-8i. Is it
possible to retrieve via CAM more health paramteres than those gathered by 
SMART/smartmontools
and if the answer is yes, how can this be achieved?
It close to impossible to isolate the drive making the noise. My guts tell me 
to RMA the
supposed to be faulty drive and not to wait until it dies from "spindle motor 
desease" or
something that is the source for the noises.

Thanks in advance,

oh


-- 
O. Hartmann

IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW

[FreeBSD User]

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 and IPv6 on the WAN interface. We 
use NPTv6 to
translate  ULA addresses for the inner IPv6 networks. We use IPv6 privacy on 
the tun0
interface.
The router/firewall is operating after a reboot or restart of mpd5 correctly, 
IPv6 and IPv4
networks have conection to the internet. When the ISP rotates it IPs, the IPv6 
address is
configured using SLAAC and mpd5 seems to act weird:

- the IPv4 address is always set correct, IPFW and in-kernel NAT route/filter 
traffic correctly
- sometimes old IPv6 address is dumped and only a new IPv6 address - in such a 
case, the old
IPv6 is gone, the new pair (temporary and MACified address are the only IPv6 
addresses
attached to the interface.
- sometimes the old IPv6 address set (= temporary) are marked "deprecated" 
and/or "detached"
and a new set is attached to the interface tun0, in some rare occassion also an 
IPv6 address
WITHOUT its "temoprary" sibbling is attached.

In any of the cases above, IPFW's NPTv6 gets confused, routing isn't working 
properly anymore.

In any cases of a change of the IPv6 address, IPFW has to be restartet! 

In cases with marked deprecated and/or detached addresses, IPFW has to be 
restarted, AND the
deprecated and/or detached IPv6 addresses has to be deleted manually. Otherwise 
- so it seems
to me - NPTv6 takes the wrong (outdated) prefix. NPTv6 should not take any 
deprecated,
detached prefix if a valid prefix is available. Even deleting the deprecated 
IPv6 requires a
restart of IPFW. No matter how long I wait, NPTv6 never gets the changed prefix 
by itself.

Kind regards,

Oliver 


-- 
O. Hartmann

CURRENT: Crash in multiuser mode while shutdown

[FreeBSD User]

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 there a known issue?

Otherwise I have to reconfigure all systems for debugging an d will report 
aftwards more.


Regards and thanks in advance
Oliver
-- 
O. Hartmann

Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW

[FreeBSD User]

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. We use IPv6 privacy on the tun0 interface. The
> > router/firewall is operating after a reboot or restart of mpd5
> > correctly, IPv6 and IPv4 networks have conection to the internet.
> > When the ISP rotates it IPs, the IPv6 address is configured using
> > SLAAC and mpd5 seems to act weird:
> > 
> > - the IPv4 address is always set correct, IPFW and in-kernel NAT
> > route/filter traffic correctly - sometimes old IPv6 address is dumped
> > and only a new IPv6 address - in such a case, the old IPv6 is gone,
> > the new pair (temporary and MACified address are the only IPv6
> > addresses attached to the interface. - sometimes the old IPv6 address
> > set (= temporary) are marked "deprecated" and/or "detached" and a new
> > set is attached to the interface tun0, in some rare occassion also an
> > IPv6 address WITHOUT its "temoprary" sibbling is attached.
> > 
> > In any of the cases above, IPFW's NPTv6 gets confused, routing isn't
> > working properly anymore.
> > 
> > In any cases of a change of the IPv6 address, IPFW has to be
> > restartet!  
> 
> Hi,
> 
> I assume you are using ext_if option in your NPTv6 instance configuration.

That is correct.

> 
> I think there might be several problems that lead to your situation:
> 
> 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address 
> that was used as external prefix  kept on the interface, it ignores 
> appearance of new IPv6 address.
> 
> 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to 
> peak another one until there won't appear new address.
> 
> 3. There should be some logic that takes into account presence of 
> temporary and deprecated addresses on the interface.
> 



-- 
O. Hartmann


pgpGnCla7RwGj.pgp
Description: OpenPGP digital signature

Re: CURRENT: Crash in multiuser mode while shutdown

[FreeBSD User]

Am Sun, 19 Feb 2023 06:19:04 -0800
Rick Macklem  schrieb:

> I committed a patch that would cause crashes if
> the system was using jails on Feb. 11, but it was
> fixed the next day. It bogusly had a prison_cleanup()
> method in it.
> 
> But if you kernel wasn't from main on about Feb. 11
> or you aren't running jails, I don't think this is it.

Sources are most recent. 

> 
> It is too bad you don't have a backtrace?

I need the box today, the other one is a poudriere host and can't be 
interrupted on short
notice, I will enable debugging 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:
> >
> > 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 there a known issue?
> >
> > Otherwise I have to reconfigure all systems for debugging an d will report 
> > aftwards more.
> >
> >
> > Regards and thanks in advance
> > Oliver
> > --
> > O. Hartmann
> >  



-- 
O. Hartmann

13-STABLE: crashing on graphical clients (Firefox, Librewolf, GIMP et cetera)

[FreeBSD User]

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_2graphics/drm-510-kmod
libdrm-2.4.115,1   graphics/libdrm
xf86-video-intel-2.99.917.916_3,1 x11-drivers/xf86-video-intel


Hardware:
Lenovo T560, 16 GB RAM, :

[...]
CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (2800.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
  
Features=0xbfebfbff
  
Features2=0x7ffafbff
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x29c6fbf
  Structured Extended
Features3=0xbc002e00
  XSAVE Features=0xf
  IA32_ARCH_CAPS=0xc04
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16462184448 (15699 MB)
CPU microcode: no matching update found
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0  irqs 0-119
Launching APs: 1 3 2
random: entropy device external interface
kbd1 at kbdmux0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.00s
smbios0:  at iomem 0xd7064000-0xd706401e
smbios0: Version: 2.8, BCD Revision: 2.8
aesni0: 
acpi0: 
[...]

GPU:
[...]
drmn0:  on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be 
disabled(-19).
[drm] Got stolen memory base 0xda80, size 0x200
drmn0: could not load firmware image 'i915/skl_dmc_ver1_27.bin'
drmn0: [drm] Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling 
runtime power
management.
drmn0: [drm] DMC firmware homepage:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915lkpi_iic0:
 on drmn0
iicbus0:  on lkpi_iic0
iic0:  on iicbus0
lkpi_iic1:  on drmn0
iicbus1:  on lkpi_iic1
iic1:  on iicbus1
lkpi_iic2:  on drmn0
iicbus2:  on lkpi_iic2
iic2:  on iicbus2
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
lkpi_iic3:  on drm1
iicbus3:  on lkpi_iic3
iic3:  on iicbus3
lkpi_iic4:  on drm2
iicbus4:  on lkpi_iic4
iic4:  on iicbus4
lkpi_iic5:  on drm4
iicbus5:  on lkpi_iic5
iic5:  on iicbus5
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1080 width=1920 depth=32
pbase=0xe000 vbase=0xf800e000
name=drmn0 flags=0x0 stride=7680 bpp=32
end FB_INFO

[...]


Phenomena: 
- WindowMaker (wmaker) crashes on startup
- while using blackbox or twm working, windowmanager starts, but: running 
any(!) larger X11
client
- singleuser mode or console mode without graphics is all right

There is NO coredump, nor does the kernel jump into kernel debugging although I 
tried to
configure that.


Regards and thanks in advance,

oh



-- 
O. Hartmann

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[FreeBSD User]

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-STABLE, git 
> > stable/13).
> > 
> > Building an appliance based on 13-STABLE sources, a customized kernel via 
> > nanoBSD, since a
> > couple of weeks for now building the sources fails in kernel sources:
> > 
> > [...]
> > --- modules-all ---
> > --- all_subdir_an ---
> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1:
> > error: a function definition without a prototype is deprecated in all 
> > versions of C and is
> > not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> > [..]
> > 
> > Disabling all wireless options in the kernel config starts dropping errors 
> > of a similar
> > kind on other kernel places.
> > 
> > Compiling on FBSD 13-STABLE seems to be all right.
> > 
> > Can this be fixed. please? What causes the error and how can this be 
> > resolved if the
> > subtree of FreeBSD's sources is a submodule?  
> 
> Not sure what you mean with "subtree is a submodule", but this is likely
> caused by skipping the cross-tools stage somehow. Do you have any
> specific make.conf or src.conf settings for that?
> 
> -Dimitry
> 

Using a subtree "./src" withing the tree of our own repository for FreeBSD's 
sources, it is a
git submodule.

According to your question about specific src.conf and make.conf - Sometimes I 
really do not
know what NanoBSD or any cross compiling tool is picking up which one: the 
host's one or the
one supposed to control NanoBSD's build.

So, the host itself does have a specific /etc/src.conf, make.conf is only about 
some ports
options to apply for the host.
For the NanoBSD sources, it is considered one file, a merger of make.conf, 
src.conf, and yes,
those ones or in that case this one is highly customized due to spefici 
requirements for space
reduction. Since that has been in the past a source of evil, I tried also with 
a "vanilla"
setup of this sepcific NanoBSD driven config (the host's src.conf/make.conf has 
been left
untouched) - in other words, deleting it, making a full fledged kernel/base 
system with all
the compiler settings at FreeBSD's default - with the same result as shown 
above.

Can you hint me towards what to look after in specific?

Kind regards,

Oliver

-- 
O. Hartmann


pgpEGWMl2A7GD.pgp
Description: OpenPGP digital signature

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[FreeBSD User]

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:  
> >>> 
> >>> 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-STABLE, git 
> >>> stable/13).
> >>> 
> >>> Building an appliance based on 13-STABLE sources, a customized kernel via 
> >>> nanoBSD, since
> >>> a couple of weeks for now building the sources fails in kernel sources:
> >>> 
> >>> [...]
> >>> --- modules-all ---
> >>> --- all_subdir_an ---
> >>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1:
> >>> error: a function definition without a prototype is deprecated in all 
> >>> versions of C and
> >>> is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> >>> [..]
> >>> 
> >>> Disabling all wireless options in the kernel config starts dropping 
> >>> errors of a similar
> >>> kind on other kernel places.
> >>> 
> >>> Compiling on FBSD 13-STABLE seems to be all right.
> >>> 
> >>> Can this be fixed. please? What causes the error and how can this be 
> >>> resolved if the
> >>> subtree of FreeBSD's sources is a submodule?  
> >> 
> >> Not sure what you mean with "subtree is a submodule", but this is likely
> >> caused by skipping the cross-tools stage somehow. Do you have any
> >> specific make.conf or src.conf settings for that?  
> > 
> > 
> > I got bitten by this recently.  In my case, it was Poudriere (running on 
> > 14-CURRENT)
> > trying to build a 13-STABLE jail.  The Poudriere jail's "src.conf" was 
> > taken from the
> > actual system for which Poudriere builds packages.  It had (amongst others) 
> > these two
> > options:
> > 
> > WITH_SYSTEM_COMPILER=yes
> > WITHOUT_CROSS_COMPILER=yes
> > 
> > 
> > When I commented these out in the jail-src.conf Poudriere file the jail 
> > built correctly.
> > 
> > I figure the system built fine because its system compiler is LLVM 14.x.  
> > The Poudriere
> > system compiler is LLVM 15.x, which has the breaking change wrt. old-style 
> > prototypes. 

Hello,

I tried to find some documentation on my CURRENT host regarding  
"WITH_SYSTEM_COMPILER". None
found via man src.conf, nor via make make.conf. Please delegate me to some 
place where I can
find such infos.

> 
> Yes, that is what I suspected in Oliver's case: if you skip the
> cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by
> setting WITH_SYSTEM_COMPILER, you are bound to run into compilation
> errors that have been fixed in 14-CURRENT, but not yet MFC'd.

From nanoBSD's perspective, all relevant build config files are merged into a 
huge file
containing three elementary sections,

CONF_BUILD
CONF_INSTALL
CONF_WORLD

in neither of them I had defined "WITH_SYSTEM_COMPILER=YES" in any way, but I 
had configured
in both CONF_INSTALL and CONF_WORLD "WITHOUT_CROSS_COMPILER=YES". I deleted 
that knob for now
from "CONF_WORLD" and left it in CONF_INSTALL ("... Options to put in make.conf 
during
installworld only ...").

> 
> The safest solution is to let cross-tools do its thing, which will check
> the host compiler, and automatically build an appropriate version of the
> compiler and linker for the stable branch, if required.

I had a misunderstanding in the terminus "cross compiling", I check now the 
build with this
option set to be enabled.

> 
> That said, I will be merging clang 15.0.7 and a bunch of other things
> that should solve all these errors to stable/13 at some point, but not
> before the 13.2-RELEASE is out. This is to avoid making life more
> difficult for our release engineering team.


> 
> -Dimitry
> 
Thank you for the efforts,

Oliver


-- 
O. Hartmann


pgpw_vAxYhaNd.pgp
Description: OpenPGP digital signature

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[FreeBSD User]

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 regarding  
> > "WITH_SYSTEM_COMPILER".
> > None found via man src.conf, nor via make make.conf. Please delegate me to 
> > some place
> > where I can find such infos.  
> 
> Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it
> means that you want to skip building the bootstrap compiler, and just
> use the host compiler. The src.conf(5) man page documents the inverse
> settings instead:
> 
>  WITHOUT_SYSTEM_COMPILER
>  Do not opportunistically skip building a cross-compiler during
>  the bootstrap phase of the build.  Normally, if the currently
>  installed compiler matches the planned bootstrap compiler type
>  and revision, then it will not be built.  This does not prevent a
>  compiler from being built for installation though, only for
>  building one for the build itself.  The WITHOUT_CLANG option
>  controls that.
> 
>  WITHOUT_SYSTEM_LINKER
>  Do not opportunistically skip building a cross-linker during the
>  bootstrap phase of the build.  Normally, if the currently
>  installed linker matches the planned bootstrap linker type and
>  revision, then it will not be built.  This does not prevent a
>  linker from being built for installation though, only for
>  building one for the build itself.  The WITHOUT_LLD option
>  controls that.
> 
>  This option is only relevant when WITH_LLD_BOOTSTRAP is set.
> 
> I find the double negative phrasing "do not skip" always confusing. But
> the logic is normally:
> 
> * The early phase of buildworld retrieves the versions of your host's
>   compiler and linker
> * It compares it against the versions in the source tree
> * If the host compiler and linker are deemed "good enough", they are
>   used as-is
> * If the host compiler or linker are not suitable, the compiler or
>   linker are bootstrapped from the source tree
> 
> But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use
> the host compiler, which might or might not work, depending on the
> circumstances. You may have to use NO_WERROR or other tricks.

Thank you for the explanation. I read the man page of src.conf in a haste 
solving my problem
and did not spend much time in reading carefully. I'd appreciate to see YOUR 
explanation in
the official man page, or at least a more non-logical-twisted version. ;-)

oh
> 
> 
> ...
> >> The safest solution is to let cross-tools do its thing, which will check
> >> the host compiler, and automatically build an appropriate version of the
> >> compiler and linker for the stable branch, if required.  
> > 
> > I had a misunderstanding in the terminus "cross compiling", I check now the 
> > build with this
> > option set to be enabled.  
> 
> Yes, this is a bit confusing, but in fact it *can* be a real cross
> compiler, if you are targeting another architecture, for example doing
> "make buildworld TARGET=arm64" from an x86_64 host.
> 
> And of course if you are building natively, it is 'just' a regular
> bootstrap compiler.
> 
> -Dimitry
> 



-- 
O. Hartmann


pgpo5n59s79UP.pgp
Description: OpenPGP digital signature

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[FreeBSD User]

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 regarding  
> > "WITH_SYSTEM_COMPILER".
> > None found via man src.conf, nor via make make.conf. Please delegate me to 
> > some place
> > where I can find such infos.  
> 
> Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it
> means that you want to skip building the bootstrap compiler, and just
> use the host compiler. The src.conf(5) man page documents the inverse
> settings instead:
> 
>  WITHOUT_SYSTEM_COMPILER
>  Do not opportunistically skip building a cross-compiler during
>  the bootstrap phase of the build.  Normally, if the currently
>  installed compiler matches the planned bootstrap compiler type
>  and revision, then it will not be built.  This does not prevent a
>  compiler from being built for installation though, only for
>  building one for the build itself.  The WITHOUT_CLANG option
>  controls that.
> 
>  WITHOUT_SYSTEM_LINKER
>  Do not opportunistically skip building a cross-linker during the
>  bootstrap phase of the build.  Normally, if the currently
>  installed linker matches the planned bootstrap linker type and
>  revision, then it will not be built.  This does not prevent a
>  linker from being built for installation though, only for
>  building one for the build itself.  The WITHOUT_LLD option
>  controls that.
> 
>  This option is only relevant when WITH_LLD_BOOTSTRAP is set.
> 
> I find the double negative phrasing "do not skip" always confusing. But
> the logic is normally:
> 
> * The early phase of buildworld retrieves the versions of your host's
>   compiler and linker
> * It compares it against the versions in the source tree
> * If the host compiler and linker are deemed "good enough", they are
>   used as-is
> * If the host compiler or linker are not suitable, the compiler or
>   linker are bootstrapped from the source tree
> 
> But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use
> the host compiler, which might or might not work, depending on the
> circumstances. You may have to use NO_WERROR or other tricks.
> 
> 
> ...
> >> The safest solution is to let cross-tools do its thing, which will check
> >> the host compiler, and automatically build an appropriate version of the
> >> compiler and linker for the stable branch, if required.  
> > 
> > I had a misunderstanding in the terminus "cross compiling", I check now the 
> > build with this
> > option set to be enabled.  
> 
> Yes, this is a bit confusing, but in fact it *can* be a real cross
> compiler, if you are targeting another architecture, for example doing
> "make buildworld TARGET=arm64" from an x86_64 host.
> 
> And of course if you are building natively, it is 'just' a regular
> bootstrap compiler.
> 
> -Dimitry
> 

As it turns out, I already used in both sections

CONF_BUILD=
CONF_WORLD=

of nanoBSD's configuration WITHOUT_SYSTEM_COMPILER and added also 
WITHOUT_SYSTEM_LINKER to be
safe.

But I don't understand why the make environment is trying to compile a piece of 
code that is
disabled via "nodevice" as shown in my initial report herein:

[...]
src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a 
prototype is
deprecated in all versions of C and is not supported in C2x
[-Werror,-Wdeprecated-non-prototype]
[...]

From my point of view neither compiler suite, LLVM14 or LLVM15, should have 
picked up the
if_an driver so far. Or do I miss something here? If so, my apologys.

Kind regards

Oliver

-- 
O. Hartmann


pgpqQrUscz3_U.pgp
Description: OpenPGP digital signature

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[FreeBSD User]

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" as shown in my initial report herein:
> > 
> > [...]
> > src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a 
> > prototype is
> > deprecated in all versions of C and is not supported in C2x
> > [-Werror,-Wdeprecated-non-prototype]
> > [...]  
> 
> The "nodevice" is for your custom kernel configuration, but as far as I
> can see an(4) is still built as a module, see sys/modules/Makefile:
> 
> ...
> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> _agp=   agp
> _an=an
> 
> -Dimitry
> 

Oh, I'm sorry,
my fault in logic!

Is there a "knob" to explicitely disable that specific module from being built 
from a point of
view of a user like me (not touching the base build system)?

-- 
O. Hartmann


pgpoewHqtwo_9.pgp
Description: OpenPGP digital signature

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[FreeBSD User]

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:
> >> ...  
> >>> But I don't understand why the make environment is trying to compile a 
> >>> piece of code that
> >>> is disabled via "nodevice" as shown in my initial report herein:
> >>> 
> >>> [...]
> >>> src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a 
> >>> prototype is
> >>> deprecated in all versions of C and is not supported in C2x
> >>> [-Werror,-Wdeprecated-non-prototype]
> >>> [...]
> >> 
> >> The "nodevice" is for your custom kernel configuration, but as far as I
> >> can see an(4) is still built as a module, see sys/modules/Makefile:
> >> 
> >> ...
> >> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> >> _agp=   agp
> >> _an=an
> >> 
> >> -Dimitry
> >>   
> > 
> > Oh, I'm sorry,
> > my fault in logic!
> > 
> > Is there a "knob" to explicitely disable that specific module from being 
> > built from a
> > point of view of a user like me (not touching the base build system)?  
> Use
> WITHOUT_MODULES=an
> in
> /etc/make.conf
> 
> Best regards
> Michael
> > 
> > -- 
> > O. Hartmann  
> 
> 

With setting 

WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES

in CONF_BUILD and CONF_WORLD and WITHOUT_CROSS_COMPILER=YES commented out (not 
building/not
cross compile?) and a fresh and clean start of the build, I run into

[...]
ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode 
(Producer:
'LLVM15.0.7' Reader: 'LLVM 14.0.5') cc: error: linker command failed with exit 
code 1 (use -v
to see invocation) *** [gh-bc] Error code 1
[...]

That seems to be the issue mostly discussed herein regarding LLVM14 and LLVM15.

Having set

WITHOUT_CROSS_COMPILER=YES
WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES
WITHOUT_MODULES=an


in both CONF_BUILD and CONF_WORLD (I do so because I do not know which one is 
really affecting
the build), I receive the reported compiling error problem in if_an.c.

Setting WITHOUT_MODULES=an in both CONF_BUILD and CONF_WORLD (nanoBSD!) doesn't 
seem to have
any effect.

Regardfs,

oh


-- 
O. Hartmann

NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')

[FreeBSD User]

Hello folks,

some strange misbehaviour in a NanoBSD compilation is driving me nuts. Recently 
I posted some
error messages regarding 

[...]
src/sys/dev/an/if_an_pci.c:143:1: error: a
function definition without a prototype is deprecated in all versions of C and 
is not
supported in C2x [-Werror,-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 (FreeBSD 14.0-CURRENT #2 
main-n261876-f5a365e51fee: Thu
Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git 
pull on a
daily/hourly/most recentl basis when trying to build).

As I understand the src/buildworld config, it seems crucial to have CURRENT and 
13-STABLE
somehow separated due to their divergende in used LLVM/CLANG (CURRENT has LLVM 
15, 13-STABLE
is with LLVM 14).

Putting 

WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES

into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the 
usage of
CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 
compiler and linker
should be used to buildworld.

But this doesn't seem to happen (at least in my case), since buildworld fails 
to build with:

[...]
cc -target x86_64-unknown-freebsd13.2
--sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp
-B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin
-O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat 
-DBUILD_TYPE=A
-DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET 
-DBC_DEFAULT_TTY_MODE
-DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH -DBC_ENABLE_LIBRARY=0
-DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT -DBC_ENABLE_RAND
-DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 
-DDC_ENABLED -DNDEBUG
-I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include 
-DBC_ENABLE_NLS=1
-flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 
-std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall 
-Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int
-Wno-unused-const-variable -Wno-error=unused-but-set-variable 
-Qunused-arguments  -Wl,-zrelro
-pie -Wl,-zretpolineplt   -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o dc.o 
dc_lex.o
dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o program.o 
rand.o read.o
vector.o vm.o bc_help.o dc_help.o lib.o lib2.o   -ledit ld: error: args.o: 
Opaque pointers are
only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 
14.0.5') cc:
error: linker command failed with exit code 1 (use -v to see invocation) *** 
[gh-bc] Error
code 1

make[5]: stopped in 
/pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc
[...]


I'm now out of options here :-(

Thanks in advance,

Oliver



-- 
O. Hartmann

Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')

[FreeBSD User]

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.
> >> Recently I posted some
> >> error messages regarding
> >>
> >> [...]
> >> src/sys/dev/an/if_an_pci.c:143:1: error: a
> >> function definition without a prototype is deprecated in all versions of
> >> C
> >> and is not
> >> supported in C2x [-Werror,-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 (FreeBSD 14.0-CURRENT #2
> >> main-n261876-f5a365e51fee: Thu
> >> Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE
> >> (git
> >> pull on a
> >> daily/hourly/most recentl basis when trying to build).
> >>
> >> As I understand the src/buildworld config, it seems crucial to have
> >> CURRENT
> >> and 13-STABLE
> >> somehow separated due to their divergende in used LLVM/CLANG (CURRENT has
> >> LLVM 15, 13-STABLE
> >> is with LLVM 14).
> >>
> >> Putting
> >>
> >> WITHOUT_SYSTEM_COMPILER=YES
> >> WITHOUT_SYSTEM_LINKER=YES
> >>
> >> into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent
> >> the
> >> usage of
> >> CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14
> >> compiler and linker
> >> should be used to buildworld.
> >>
> >> But this doesn't seem to happen (at least in my case), since buildworld
> >> fails to build with:
> >>
> >> [...]
> >> cc -target x86_64-unknown-freebsd13.2
> >> --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp
> >> -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin
> >> -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat
> >> -DBUILD_TYPE=A
> >> -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET
> >> -DBC_DEFAULT_TTY_MODE
> >> -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH
> >> -DBC_ENABLE_LIBRARY=0
> >> -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT
> >> -DBC_ENABLE_RAND
> >> -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0
> >> -DDC_ENABLED -DNDEBUG
> >> -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include
> >> -DBC_ENABLE_NLS=1
> >> -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero
> >> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> >> -std=gnu99
> >> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall
> >> -Wno-format-y2k -W
> >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> >> -Wpointer-arith -Wreturn-type
> >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
> >> -Wcast-align
> >> -Wchar-subscripts -Wnested-externs -Wold-style-definition
> >> -Wno-pointer-sign
> >> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> >> -Wno-string-plus-int
> >> -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> >> -Qunused-arguments  -Wl,-zrelro
> >> -pie -Wl,-zretpolineplt   -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o
> >> dc.o dc_lex.o
> >> dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o
> >> program.o rand.o read.o
> >> vector.o vm.o bc_help.o dc_help.o lib.o lib2.o   -ledit ld: error:
> >> args.o:
> >> Opaque pointers are
> >> only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader:
> >> 'LLVM 14.0.5') cc:
> >> error: linker command failed with exit code 1 (use -v to see invocation)
> >> ***
> >> [gh-bc] Error
> >> code 1
> >>
> >> make[5]: stopped in
> >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/

Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')

[FreeBSD User]

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
> >
> > [...]
> > src/sys/dev/an/if_an_pci.c:143:1: error: a
> > function definition without a prototype is deprecated in all versions of C
> > and is not
> > supported in C2x [-Werror,-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 (FreeBSD 14.0-CURRENT #2
> > main-n261876-f5a365e51fee: Thu
> > Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git
> > pull on a
> > daily/hourly/most recentl basis when trying to build).
> >
> > As I understand the src/buildworld config, it seems crucial to have CURRENT
> > and 13-STABLE
> > somehow separated due to their divergende in used LLVM/CLANG (CURRENT has
> > LLVM 15, 13-STABLE
> > is with LLVM 14).
> >
> > Putting
> >
> > WITHOUT_SYSTEM_COMPILER=YES
> > WITHOUT_SYSTEM_LINKER=YES
> >
> > into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the
> > usage of
> > CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14
> > compiler and linker
> > should be used to buildworld.
> >
> > But this doesn't seem to happen (at least in my case), since buildworld
> > fails to build with:
> >
> > [...]
> > cc -target x86_64-unknown-freebsd13.2
> > --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp
> > -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin
> > -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat
> > -DBUILD_TYPE=A
> > -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET
> > -DBC_DEFAULT_TTY_MODE
> > -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH
> > -DBC_ENABLE_LIBRARY=0
> > -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT
> > -DBC_ENABLE_RAND
> > -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0
> > -DDC_ENABLED -DNDEBUG
> > -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include
> > -DBC_ENABLE_NLS=1
> > -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero
> > -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> > -std=gnu99
> > -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall
> > -Wno-format-y2k -W
> > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith -Wreturn-type
> > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
> > -Wcast-align
> > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign
> > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> > -Wno-string-plus-int
> > -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> > -Qunused-arguments  -Wl,-zrelro
> > -pie -Wl,-zretpolineplt   -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o
> > dc.o dc_lex.o
> > dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o
> > program.o rand.o read.o
> > vector.o vm.o bc_help.o dc_help.o lib.o lib2.o   -ledit ld: error: args.o:
> > Opaque pointers are
> > only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader:
> > 'LLVM 14.0.5') cc:
> > error: linker command failed with exit code 1 (use -v to see invocation) ***
> > [gh-bc] Error
> > code 1
> >
> > make[5]: stopped in
> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc
> > [...]
> >
> >
> > I'm now out of options here :-(
> >  
> 
> are you even using the dev/an driver?

No, it is commented out in the kernel config file. That error occurs when using 
the CURRENT
system's compiler building the nanoBSD binaries.

> 
> you should probably just remove it from the kernel (and any other
> driver of the sort)

I tried to put the option 

WITHOUT_MODULE="an"

into the nanoBSD sections building 

Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')

[FreeBSD User]

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

[...]
# BUILD and INSTALL!
# Options to put in make.conf during both build- & installworld.
# See man src.conf(5) for more details on WITHOUT_ tags.
CONF_WORLD='
WITHOUT_MODULES="an"
WITHOUT_AMD=YES
WITHOUT_APM=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_AT=YES
WITHOUT_BHYVE=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BOOTPARAMD=YES
WITHOUT_BOOTPD=YES
WITHOUT_CALENDAR=YES
WITHOUT_CCD=YES
WITHOUT_CDDL=YES
WITHOUT_CTM=YES
WITHOUT_DEBUG_FILES=YES
WITHOUT_DICT=YES
WITHOUT_DIALOG=YES
WITHOUT_EXAMPLES=YES
WITHOUT_EE=YES
WITHOUT_FINGER=YES
WITHOUT_FLOPPY=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_FDT=YES
WITHOUT_GAMES=YES
WITHOUT_GCOV=YES
WITHOUT_GOOGLETEST=YES
WITHOUT_HAST=YES
WITHOUT_HTML=YES
WITHOUT_HYPERV=YES
WITHOUT_INETD=YES
WITHOUT_IPFILTER=YES
[...]

-- 
O. Hartmann

Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing)

[FreeBSD User]

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 upgrade POOLNAME
> >
> > some boxes keep crashing when starting compiler runs (the trigger is
> > different on boxes).
> >
> > ZFS module is statically compiled into the kernel (if this is of
> > importance)
> >
> > Last known good was:
> >
> > [...]
> > Apr  9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7
> > main-n262051-75379ea2e461: Sun Apr
> > 9 00:12:57 CEST 2023 Apr  9 07:10:04 <0.2> thor kernel:
> > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr  9 07:10:04 <0.2>
> > thor kernel:
> > FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git
> > llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr  9 07:10:04 <0.2> thor kernel:
> > VT(efifb): resolution
> > 2560x1440 Apr  9 07:10:04 <0.2> thor kernel: module zfsctrl already
> > present!
> > [...]
> >
> > The file /var/crash/info.X
> >
> > contains:
> >
> > [...]
> >
> > root@thor:/var/crash # more info.2
> > Dump header from device: /dev/gpt/swap
> >   Architecture: amd64
> >   Architecture Version: 2
> >   Dump Length: 1095192576
> >   Blocksize: 512
> >   Compression: none
> >   Dumptime: 2023-04-09 11:43:41 +
> >   Hostname: thor.local
> >   Magic: FreeBSD Kernel Dump
> >   Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun Apr
> >  9 12:01:02 CEST
> > 2023
> > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR
> >   Panic String: VERIFY(!zil_replaying(zilog, tx)) failed
> >
> >   Dump Parity: 2961465682
> >   Bounds: 2
> >   Dump Status: good
> >
> > Until reconfigured for more debug stuff I do not have more to present.
> >
> > I rememeber now really scraed that there was a HEADSUP in the list regarding
> > some serious ZFS
> > problems - I didn't find it right now.
> >
> > Thanks in advance,
> >  
> 
> That's fallout from the new block cloning feature, adding the author
> 

Thanks.

As of this moment, all systems with the newest kernel and the new ZFS option 
enabled, crash -
the reason is mostly in  different ZFS datasets. I guess there is no way back 
once this faulty
option is enabled?

Regards,

oh

-- 
O. Hartmann

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[FreeBSD User]

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 poudriere-devel bulk build
> >> testing. This predates:
> >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> >> but had the changes from:
> >> https://github.com/openzfs/zfs/pull/14739/files
> >> The files were missing from packages installed to be used
> >> during a port's build. No other types of examples of missing
> >> files happened. (But only 11 ports failed.)  
> > I also don't have block_cloning enabled. "Missing files" prior to 
> > brt_revert may actually
> > be present, but as the corruption also messes with the file(1) signature, 
> > some tools like
> > ldconfig report them as missing.  
> 
> For reference, the specific messages that were not explicit
> null-byte complaints were (some shown with a little context):
> 
> 
> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not found
> ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg  
> [CA72_ZFS] Installing libxml2-2.10.3_1...
> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
> (/usr/local/lib/libxml2.so) . . .
> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
> ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
> (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.2  
> . . .
> ===>  Configuring for py39-lxml-4.9.2  
> Building lxml version 4.9.2.
> Building with Cython 0.29.33.
> Error: Please make sure the libxml2 and libxslt development packages are 
> installed.
> 
> 
> [CA72_ZFS] Extracting libunistring-1.1: .. done
> ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not found  
> 
> 
> [CA72_ZFS] Extracting gmp-6.2.1: .. done
> ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found  
> 
> 
> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> ===>   Installing existing package /packages/All/gmp-6.2.1.pkg  
> [CA72_ZFS] Installing gmp-6.2.1...
> the most recent version of gmp-6.2.1 is already installed
> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found  
> *** Error code 1
> 
> 
> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> 
> 
> checking for GNU 
> M4 that supports accurate traces... configure: error: no acceptable m4 could 
> be found in
> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> 
> 
> ld: error: /usr/local/lib/libblkid.a: unknown file type
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

Hello 

whar is the recent status of fixing/mitigate this desatrous bug? Especially for 
those with the
new option enabled on ZFS pools. Any advice?

In an act of precausion (or call it panic) I shutdown several servers to 
prevent irreversible
damages to databases and data storages. We face on one host with /usr/ports 
residing on ZFS
always errors on the same files created while staging (using portmaster, leaves 
the system
with noninstalled software, i.e. www/apache24 in our case). Deleting the work 
folder doesn't
seem to change anything, even when starting a scrubbing of the entire pool 
(RAIDZ1 pool) -
cause unknown, why it affects always the same files to be corrupted. Same with 
deve/ruby-gems.

Poudriere has been shutdown for the time being to avoid further issues. 

Are there any advies to proceed apart from conserving the boxes via shutdown?

Thank you ;-)
oh



-- 
O. Hartmann

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[FreeBSD User]

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 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 poudriere-devel bulk build
> > > >> testing. This predates:
> > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> > > >> but had the changes from:
> > > >> https://github.com/openzfs/zfs/pull/14739/files
> > > >> The files were missing from packages installed to be used
> > > >> during a port's build. No other types of examples of missing
> > > >> files happened. (But only 11 ports failed.)
> > > > I also don't have block_cloning enabled. "Missing files" prior to 
> > > > brt_rev  
> > ert may actually  
> > > > be present, but as the corruption also messes with the file(1) 
> > > > signature,  
> >  some tools like  
> > > > ldconfig report them as missing.
> > > 
> > > For reference, the specific messages that were not explicit
> > > null-byte complaints were (some shown with a little context):
> > > 
> > >   
> > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not found
> > > ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg
> > > [CA72_ZFS] Installing libxml2-2.10.3_1...
> > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done  
> > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found  
> > > (/usr/local/lib/libxml2.so) . . .
> > > [CA72_ZFS] Extracting libxslt-1.1.37: .. done  
> > > ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found  
> > > (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.2  
> > > . . .  
> > > ===>  Configuring for py39-lxml-4.9.2
> > > Building lxml version 4.9.2.
> > > Building with Cython 0.29.33.
> > > Error: Please make sure the libxml2 and libxslt development packages are 
> > > in  
> > stalled.  
> > > 
> > > 
> > > [CA72_ZFS] Extracting libunistring-1.1: .. done  
> > > ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not 
> > > found  
> > 
> > > 
> > > 
> > > [CA72_ZFS] Extracting gmp-6.2.1: .. done  
> > > ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found
> > > 
> > >   
> > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> > > ===>   Installing existing package /packages/All/gmp-6.2.1.pkg
> > > [CA72_ZFS] Installing gmp-6.2.1...
> > > the most recent version of gmp-6.2.1 is already installed  
> > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> > > *** Error code 1
> > > 
> > > 
> > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> > > 
> > > 
> > > checking for GNU 
> > > M4 that supports accurate traces... configure: error: no acceptable m4 
> > > coul  
> > d be found in  
> > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> > > 
> > > 
> > > ld: error: /usr/local/lib/libblkid.a: unknown file type
> > > 
> > > 
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > > 
> > >   
> >
> > Hello 
> >
> > whar is the recent status of fixing/mitigate this desatrous bug? Especially 
> > f
> > or those with the
> > new option enabled on ZFS pools. Any advice?
> >
> > In an act of precausion (or call it panic) I shutdown several servers to 
> > prev
> > ent irreversible
> > damages to databases and data storages. We face on one host with /usr/ports 
> > r
> > esiding on ZFS
> > always errors on the same files created while staging (using portmaster, 
> > leav
> > es the system
> > with noninstalled software, i.e. www/apache24 in our case). Deleting the 
> > work
> >  folder doesn't
> > seem to change anything, even when starting a scrubbing of the entire pool 
> > (R
> > AIDZ1 pool) -
> > cause unknown, why it affects always the same files to be corrupted. Same 
> > wit
> > h deve/ruby-gems.
> >
> > Poudriere has been shutdown for the time being to avoid further issues. 
> >
> > Are there any advies to proceed apart from conserving the boxes via 
> > shutdown?
> >
> > Thank you ;-)
> > oh
> >
> >
> >
> > -- 
> > O. Hartmann  
> 
> With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded 
> blocks. #14739" patch I didn't have any issues, except for email messages 
> with corruption in my sent directory, nowhere else. I'm still investigating 
> the email messages issue. IMO one is generally safe to run poudriere on the 
> latest ZFS with the additional patch.
> 
> My tests of the additional patch concluded that it resolved my last 
>

Re: WITH_BEARSSL: -8112 bytes available

[FreeBSD User]

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 result in a slightly enlarged loader binary, which seems to have
> > a fixed size
> > supposed on the error I get. See below.
> >
> > The system is amd64 (64 bit), for the record.
> >
> > Somewhere in the past developers mentioned this upcoming problem and
> > provided a knob to adjust
> > the used size - I forgot about that knob and I couldn't find it even in
> > the loader docs - or
> > looked at the wrong places.
> >
> > Can someone help me out here?
> >
> > The first error stops compileing world/kernel, but taking a second run,
> > the error goes away.
> >
> > Kind regards and thanks in advance,
> >
> > oh
> >
> >
> >
> > [...]
> > --- all_subdir_stand/efi ---
> > SOURCE_DATE_EPOCH=1451606400  objcopy -j .peheader -j .text -j .sdata -j
> > .data  -j .dynamic -j
> > .dynsym -j .rel.dyn  -j .rela.dyn -j .reloc -j .eh_frame -j
> > set_Xcommand_set  -j
> > set_Xficl_compile_set  --output-target=efi-app-x86_64 loader_4th.sym
> > loader_4th.efi ---
> > all_subdir_stand/i386 ---
> >
> > -8112 bytes available 7.71 real12.86 user 3.08 sys  
> 
> 
> bummer. I hate it when it's that close.
> 
> You can try setting LOADERSIZE=56 in your environment. We currently set
> the maximum to 550,000

I tried to find find anything related to LOADER or SIZE in the docs. I remember 
you mentioned
the existence of that variable months ago, but with no clue what to look after, 
it is almost
impossible yo figure out as a non developer what the right knob might be.

A grep -r on /usr/src shows up only in 

[...]
./stand/i386/loader/Makefile:LOADERSIZE?=   55  # Largest known 
safe size for
loader.bin
./stand/i386/loader/Makefile:   @set -- `ls -l ${.TARGET}` ; 
x=$$((${LOADERSIZE}-$$5)); \
[...]

There is no sign/trace of it in any man page related to loader and sibblings. I 
found the
variable rather quickly after knowing what to look after.



> bytes because that's the most conservative number due to variation in the
> available BIOS space available.
> This likely can be set even higher if you don't have add-in cards that are
> consuming space in the lower 640k
> of memory. 640k is the absolute limit, but you need 20-30k of stack for the
> loader so pushing this much past
> 625,000 or maybe 630,000 increases the risk of run-time crashes as the
> stack smashes through the top of
> the loader program. You may also have to disable the lua build, since it
> uses more stack and is just a smidge
> larger than the forth build. _simp will be the smallest of them all. On my
> system, without bearssl, I see:
> -r-xr-xr-x  3 root  wheel  503808 May 22 15:25 /boot/loader_lua
> -r-xr-xr-x  1 root  wheel  446464 May 22 15:25 /boot/loader_4th
> -r-xr-xr-x  1 root  wheel  385024 May 22 15:25 /boot/loader_simp

In my case, with supposedly blewn up loader size by BEARSSL enables, it is:

-r-xr-xr-x  1 root  wheel  - 503808  3 Juni 12:33 /boot/loader_4th*
-r-xr-xr-x  1 root  wheel  - 643584  3 Juni 12:33 /boot/loader_4th.efi*
-r-xr-xr-x  1 root  wheel  - 503808  3 Juni 07:45 /boot/loader_4th.old*
-r-xr-xr-x  3 root  wheel  - 569344  3 Juni 12:33 /boot/loader_lua*
-r-xr-xr-x  2 root  wheel  - 737280  3 Juni 12:33 /boot/loader_lua.efi*
-r-xr-xr-x  1 root  wheel  - 569344  3 Juni 07:45 /boot/loader_lua.old*
-r-xr-xr-x  1 root  wheel  - 446464  3 Juni 12:33 /boot/loader_simp*
-r-xr-xr-x  1 root  wheel  - 589312  3 Juni 12:33 /boot/loader_simp.efi*
-r-xr-xr-x  1 root  wheel  - 446464  3 Juni 07:45 /boot/loader_simp.old*

on FreeBSD 14.0-CURRENT #58 main-n263387-556b43492297: Fri Jun  2 20:19:55 CEST 
2023 amd64.
> which suggests a ~60k bump for adding forth and ~115k bump for lua. So the
> 560,000 may need to be 625,000
> which is living life on the edge for 4th, and simply too big for lua.
> 
> I'd be open to adding docs on this, since I don't think this option is
> currently documented since I added it
> to experiment around with a good value.

See above, personally I'd like to see some hints on that variable, even if I do 
not fiddle
around with it.

> 
> And no, I really do not want to support 'loadable modules'. BIOS booting is
> on the way out, and people
> that want to do complex stuff in the boot loader will simply have to do
> that in UEFI or maybe kboot/LinuxBoot.
> There's low RoI on adding this complexity, imho. We'd be better off, imho,
> making things like the gra

CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?

[FreeBSD User]

Hello,

running a recent CURRENT, 14.0-CURRENT #10 main-n263871-fd774e065c5d: Thu Jun 
29 05:26:55 CEST
2023 amd64, xfreerdp (net/freerdp) doesn't working anymore on Windows 10 guest 
in bhyve. It
seems OpenSSL 3 is the culprit (see the error message from xfreerdp below). I 
opened already a
PR (see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a very 
quick response I
was informed that recent FreeRDP doesn't support OpenSSL 3 yes
(https://github.com/FreeRDP/FreeRDP/pull/8920).

Checking for HowTo's setting up bhyve guests, I dodn't realise any setting for 
alternatives to
RDP. As I do not fully understand how bhyve passes through its guest's 
framebuffer device/ or
native GUI, I'm a bit helpless in searching for another solution to contact the 
Windows10
guest from the X11 desktop of the hosts.

Trying remmina turns out to be a fail, because in our installation libsoup2 and 
libsoup3 are
installed both and remmina complains about having both symbols, also I realised 
remmina seems
to utilize net/freerdb as the RDP backend.

Since I have no clue how to install "blindly" a VNCserver within the Windows10 
guest, I
presume VNC 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

Re: CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?

[FreeBSD User]

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) doesn't working anymore on Windows 
> > 10 guest in
> > bhyve. It seems OpenSSL 3 is the culprit (see the error message from 
> > xfreerdp below). I
> > opened already a PR (see: 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a
> > very quick response I was informed that recent FreeRDP doesn't support 
> > OpenSSL 3 yes
> > (https://github.com/FreeRDP/FreeRDP/pull/8920).
> > 
> > Checking for HowTo's setting up bhyve guests, I dodn't realise any setting 
> > for
> > alternatives to RDP. As I do not fully understand how bhyve passes through 
> > its guest's
> > framebuffer device/ or native GUI, I'm a bit helpless in searching for 
> > another solution to
> > contact the Windows10 guest from the X11 desktop of the hosts.
> > 
> > Trying remmina turns out to be a fail, because in our installation libsoup2 
> > and libsoup3
> > are installed both and remmina complains about having both symbols, also I 
> > realised
> > remmina seems to utilize net/freerdb as the RDP backend.
> > 
> > Since I have no clue how to install "blindly" a VNCserver within the 
> > Windows10 guest, I
> > presume VNC 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.
> >   
> 
> I had the same issue, with Windows 10 pro hosts, but the fault is in 
> windows, which, by default, tries to negotiate an ancient protocol (NTLM 
> using RC4 if I understand correctly).
> 
> With modern windows RDP servers there are better protocols available, 
> you can get them in remmina by forcing "TLS protocolo security" in the 
> advanced tab, security protocol negotiation (second row).
> 
> Doing this (after some experimentation with various options) solved the 
> issue for me.
> 

Thank you very much for the quick response.

net/remmina is not an option on most of my workstations, since some required 
ports install
libsoup3, and remmina complains about having found libsoup2 symbols as well as 
libsoup3
symbols when starting up - and quits.

Since remmina utilises net/freerdp, I was wondering if I could enforce TLS 
security by any
kind of a switch, and trying the following

 xfreerdp /v:192.168.0.128:5900 /u:ohartmann /sec:tls

resulting in

[...]
[17:58:18:972] [1702:bb812700] [WARN][com.winpr.utils.ssl] - OpenSSL LEGACY 
provider failed to
load, no md4 support available! 
[17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read 
returned an
error: error:12800067:DSO support routines::could not load the shared 
library
[17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read 
returned an
error: error:12800067:DSO support routines::could not load the shared 
library
[17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read 
returned an
error: error:07880025:common libcrypto routines::reason(524325) 
[17:58:18:973]
[1702:bb812700] [ERROR][com.freerdp.core] - 
transport_read_layer:freerdp_set_last_error_ex
ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] 
[17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read 
returned a
system error 35: Resource temporarily unavailable 
[17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] -
transport_read_layer:freerdp_set_last_error_ex 
ERRCONNECT_CONNECT_TRANSPORT_FAILED
[0x0002000D] [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] - 
freerdp_post_connect
failed


My setup is

bhyve -c 4 -m 4G -w -H \
-s 0,hostbridge \
-s 3,ahci-hd,/pool/home/ohartmann/bhyve/win10/disk_win10.img  \
-s 5,virtio-net,tap0 \
-s 29,fbuf,tcp=0.0.0.0:5900,w=1920,h=1200,vga=io \
-s 30,xhci,tablet \
-s 31,lpc \
-l com1,stdio \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
win10

and this is a working image setup a couple of weeks ago when VBox has been 
defective on
CURRENT - should say: it worked once.

I can not interpret the error above.

bhyve is novel to me and I have to admit that I make some capital mistakes here 
- but can't
find satisfying doucumentation ...

Kind reagrds,

Oliver

-- 
O. Hartmann

Re: CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?

[FreeBSD User]

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


Regards

oh


>   Hi everyone,
> 
> I believe I understand where the issue loading OpenSSL's
> legacy provider comes from (for MD4 support) and I am currently working 
> on a fix here:
> https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0-providers
> 
> Basically the OpenSSL provider module for legacy algorithms is not built 
> correctly, since the switch to OpenSSL 3.0.9 in base. The same goes with 
> the FIPS module, where finding an elegant solution is more difficult 
> than for the legacy one, but I'm getting there.
> 
> Anyway, I will keep updating this branch until it's ready for a pull-up 
> request, very likely with force-pushes in order to polish the commits 
> before submission.
> 
> Let me know how it goes!
> 
> Cheers,
> -- Pierre
> 
> On 6/29/23 23:56, Dustin Marquess wrote:
> > On Jun 29, 2023 at 11:36 AM -0500, FreeBSD User 
> > , wrote:
> > 
> > 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) doesn't working
> > anymore on Windows 10 guest in
> > bhyve. It seems OpenSSL 3 is the culprit (see the error
> > message from xfreerdp below). I
> > opened already a PR (see:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a
> > very quick response I was informed that recent FreeRDP
> > doesn't support OpenSSL 3 yes
> > (https://github.com/FreeRDP/FreeRDP/pull/8920).
> > 
> > Checking for HowTo's setting up bhyve guests, I dodn't
> > realise any setting for
> > alternatives to RDP. As I do not fully understand how bhyve
> > passes through its guest's
> > framebuffer device/ or native GUI, I'm a bit helpless in
> > searching for another solution to
> > contact the Windows10 guest from the X11 desktop of the hosts.
> > 
> > Trying remmina turns out to be a fail, because in our
> > installation libsoup2 and libsoup3
> > are installed both and remmina complains about having both
> > symbols, also I realised
> > remmina seems to utilize net/freerdb as the RDP backend.
> > 
> > Since I have no clue how to install "blindly" a VNCserver
> > within the Windows10 guest, I
> > presume VNC 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.
> > 
> > 
> > I had the same issue, with Windows 10 pro hosts, but the fault is in
> > windows, which, by default, tries to negotiate an ancient
> > protocol (NTLM
> > using RC4 if I understand correctly).
> > 
> > With modern windows RDP servers there are better protocols
> > available,
> > you can get them in remmina by forcing "TLS protocolo security"
> > in the
> > advanced tab, security protocol negotiation (second row).
> > 
> > Doing this (after some experimentation with various options)
> > solved the
> > issue for me.
> > 
> > 
> > Thank you very much for the quick response.
> > 
> > net/remmina is not an option on most of my workstations, since some
> > required ports install
> > libsoup3, and remmina complains about having found libsoup2 symbols
> > as well as libsoup3
> > symbols when starting up - and quits.
> > 
> > Since remmina utilises net/freerdp, I was wondering if I could
> > enforce TLS security by any
> > kind of a switch, 

epair/vbridge: no IPv6 traffic egress until first IPv6 packet flows in

[FreeBSD User]

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 ) is member of that bridge and so a couple of 
epair(4) devices
belonging to a couple of jails.

IP filter is ipfw, each jail does have profile "WORKSTATION" configured and 
enabled, so the
host itself. On those hosts I use the standard rc facility.

Additionally, following MIB knobs are set to the following values:

net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0


and

net.link.ether.inet.allow_multicast: 0
net.link.ether.inet.log_arp_permanent_modify: 1
net.link.ether.inet.log_arp_movements: 1
net.link.ether.inet.log_arp_wrong_iface: 1
net.link.ether.inet.garp_rexmit_count: 0
net.link.ether.inet.max_log_per_second: 1
net.link.ether.inet.maxhold: 16
net.link.ether.inet.wait: 20
net.link.ether.inet.proxyall: 0
net.link.ether.inet.maxtries: 5
net.link.ether.inet.max_age: 1200
net.link.ether.arp.log_level: 6
net.link.ether.ipfw: 0

On epairs as well as on the main hosts igb0 NIC, both IPv4 and IPv6 are 
configured, IPv6 uses
ULA and setup doesn't has anything fancy.

Pinging and connecting to hosts "outside" the box of the host in question (all 
FreeBSD
CURRENT/14-STABLE) is possible without ANY(!) restriction or something 
nonregular.

[OBSERVATION]

JAILs can ping any(!) IPv4 host in the net, the main-jail-bearing-host 
(main-host) itself or
any host on the configured bridge() (important: jail -> main-host).

JAILs can ping IPv6 any host on the bridge() or in the net or in the internet, 
BUT NOT the
main-host (igb0-owner). NO IPv6 related service FROM jail TOWARD main-host is 
possible, it is
all blocked (and I do not know what blocks or how ...).

Disbaling IPFW via "ipfw disable firewall" on all jails and main-host doesn't 
have any effect
in this state.

BUT: if the main-host IPv6 pings a jail on that bridge (packet flowing into 
(the) jail/ingress
from jail's perspective), the jail itself suddenly is then able to ping or do 
network traffic
in IPv6! Other jails remain dead that way for IPv6 until I ping them. I haven't 
or I'm
unable to check(ed) why ipv6-icmp is mysteriously "opening" the connection. 
SSH'ing via
IPv6/TCPv6 from the main-host into a jail (tcp/22) works also perfectly and 
works as the
"openener" - a stuck ping -6 towards the main-host then immediately starts 
flowing.

I remember that such a similar problem occured somewhere around FreeBSD 10/11 
and the problem
vanished somehow in the vain of development/patching.

Even disabling IPFW on all entities or switching to profile "open" doesn't help.

Some services, like LDAP, nslcd do not work from jails if the jail remains in 
the initial
state. That troubles me. Pinging via IPv6 icmp the jail seems to loosen all 
restraints, LDAP
works, ping works, everything on IPv6 is normal as expected. But the JAIL has 
to be pinged
from the outside first!

As stated, I'm out of ideas here and what troubles me most is the fact even 
LDAP doesn't work
until the jail is pinged via icmp6 first time.After this "init", everything is 
normal.

IPv4 seems to be unharmed ...

Thanks for your patience and reading,

Kind regards
oh

-- 
O. Hartmann

Re: uSB: uslcom: CP2102 weirdness when serial communication via cu/tip/cutecom

[FreeBSD User]

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:
> 
> https://de.elv.com/pc-usb-i2c-interface-200958 
> 
> for an sketch/overview. The device is recognised as
>  
> uslcom0 on uhub6
> uslcom0:  on usbus0
> 
> for more details via usbconfig see below.
> 
> Using FreeBSD CURRENT and 14-STABLE (both most recent) connecting to the 
> device via 
> 
> cu -l /dev/cuaUX -s 115200
> 
> results in most cases in a stuck connection. The LED of the device is 
> responding to every
> keystroke made in the terminal, but I never see any output (which should).
> In some rare cases disconneting and reconnecting the USB link and connecting 
> via "cu" gives
> the opportunity for a couple of seconds to enter "?" in the terminal which 
> provides some
> firmware data on the device - then the communications goes dark. This 
> behaviour is erratic
> and non predictable.
> 
> I tried several platforms (hardware), all USB 3, tried FreeBSD 14-STABLE and 
> CURRENT. On a
> notebook (Lenovo T560) running 14-STABLE the very same situation, but trying 
> the Lenovo with
> Xubuntu 23.10 gives me a working "cu" and I'm able reading environmental data 
> from the
> device.
> 
> Using the methusalem USB 2 port of a computer were available gives me a few 
> seconds more on
> FreeBSD, before the serial connection goes mute.
> 
> In cases were possible I tried the same hardware with FreeBSD and Linux 
> Xubuntu, FreeBSD
> fails, Xubuntu prevails the task. At this point I was quite sure that 
> FreeBSD's uslcom-driver
> might be the culprit.
> 
> Out of couriosity I tried a FSBD-13.2RELENG image for AARCH64 (PINE64 I have 
> at hand) and
> connected the same way, the same device acts as normal as I see under Linux 
> Xubuntu. I'm able
> to take environmental data as long as I please without a problem so far.
> 
> Can someone hint me how to debug such a situation? I'm unwilling to use Linux 
> since our
> infrastructure is based on FreeBSD and ... well, no further explanation on 
> that subject ;-)
> 
> Thanks in advance,
> 
> O. Hartmann

Forgot this one:

[...]

usbconfig -d 0.7 dump_all_desc
ugen0.7:  at usbus0, cfg=0 md=HOST spd=FULL 
(12Mbps)
pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x10c4 
  idProduct = 0xea60 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0003  
  bNumConfigurations = 0x0001 

 Configuration index 0

bLength = 0x0009 
bDescriptorType = 0x0002 
wTotalLength = 0x0020 
bNumInterfaces = 0x0001 
bConfigurationValue = 0x0001 
iConfiguration = 0x  
bmAttributes = 0x0080 
bMaxPower = 0x00fa 

Interface 0
  bLength = 0x0009 
  bDescriptorType = 0x0004 
  bInterfaceNumber = 0x 
  bAlternateSetting = 0x 
  bNumEndpoints = 0x0002 
  bInterfaceClass = 0x00ff  
  bInterfaceSubClass = 0x 
  bInterfaceProtocol = 0x 
  iInterface = 0x0002  

 Endpoint 0
bLength = 0x0007 
bDescriptorType = 0x0005 
bEndpointAddress = 0x0081  
bmAttributes = 0x0002  
wMaxPacketSize = 0x0040 
bInterval = 0x 
bRefresh = 0x 
bSynchAddress = 0x 

 Endpoint 1
bLength = 0x0007 
bDescriptorType = 0x0005 
bEndpointAddress = 0x0001  
bmAttributes = 0x0002  
wMaxPacketSize = 0x0040 
bInterval = 0x 
bRefresh = 0x 
bSynchAddress = 0x 


-- 
O. Hartmann

IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)

[FreeBSD User]

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, host is listening on both 
protocol families
IPv4 and IPv6). 

The host itself has openldap-server 2.6 as a service. The host's interface is 
igb0 with
assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces via 
a bridge with
the same physical device as the host (igb0). After a while (the time elapsed is 
unspecific)
the jail is unable to contact the host via IPv6: neither UDP, TCP nor ICMP sent 
from the JAIL
is reaching the host. IPv4 is working like a charme! No problems there.

When pinging the Jail from the main host via ping -6, the jail is responding! 
After the first
ping -6, the jail now is able to ping -6 the main host.

After a fresh reboot, the problem is not present and occurs after a while and 
it seems to
happen first to very active jails.

Kind regards,

oh


-- 
O. Hartmann

Re: NFSv4 crash of CURRENT

[FreeBSD User]

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,
> >
> > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: 
> > Sat Jan 13
> > 18:08:32 CET 2024 amd64). One NFSv4 server is same OS revision as the 
> > mentioned client,
> > other is FreeBSD 13.2-RELEASE-p8. Both offer NFSv4 filesystems, 
> > non-kerberized.
> >
> > I can crash the client reproducable by accessing the one or other NFSv4 FS 
> > (a simple ls
> > -la). The NFSv4 FS is backed by ZFS (if this matters). I do not have 
> > physicla access to
> > the client host, luckily the box recovers.  
> Did you rebuild both the nfscommon and nfscl modules from the same sources?

Yes, as requested, as soon as the commit occured. I recompiled the whole OS 
from a "make -j4
cleanworld cleandir" .

But I have a custom kernel with several custom options statically compiled in.

> I did a commit to main that changes the interface between these two
> modules and did bump the
> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
> (If you have "options NFSCL" in your kernel config, both should have
> been rebuilt as a part of
> the kernel build.)

Monday I will try to compile in several debug options whe I get hands on the 
machine again and
I can test Tuesday on several other boxes running CURRENT (after update) how 
they interact
with themselfes (CURRENT) and other (FBSD14, FBSD13) via NFSv4.

> 
> rick
> >
> > I have no idea what causes this problem ...
> >
> > Kind regards,
> >
> > O. Hartmann
> >
> >
> > --
> > O. Hartmann
> >
> > 
> >
> >
> >
> > Do you have something like a panic message, stack trace or core dump?
> >
> > Regards
> > Ronald  
> 



-- 
O. Hartmann

Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)

[FreeBSD User]

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
> >
> > 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, host is listening on both 
> > protocol families
> > IPv4 and IPv6). 
> >
> > The host itself has openldap-server 2.6 as a service. The host's interface 
> > is igb0 with
> > assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces 
> > via a bridge
> > with the same physical device as the host (igb0). After a while (the time 
> > elapsed is
> > unspecific) the jail is unable to contact the host via IPv6: neither UDP, 
> > TCP nor ICMP
> > sent from the JAIL is reaching the host. IPv4 is working like a charme! No 
> > problems there.
> >
> > When pinging the Jail from the main host via ping -6, the jail is 
> > responding! After the
> > first ping -6, the jail now is able to ping -6 the main host.
> >
> > After a fresh reboot, the problem is not present and occurs after a while 
> > and it seems to
> > happen first to very active jails.
> >
> > Kind regards,
> >
> > oh
> >
> >
> > -- 
> > O. Hartmann
> >  
> 
> Hello,
> 
> This behavior might be caused by IPFW blocking some IPv6 neighbor 
> discovery/advertisement 
> messages.
> After some time, the link layer addresses of the IPv6 neighbors in the NDP 
> cache may expire,
> making the associated IPv6 addresses inaccessible.
> Do your IPFW rules allow ICMPv6 messages to and from IPv6 multicast addresses?
> 
> Regards.
> 

Thank you for responding. Thank you for his valuable hint!

The jail(s) itself/themselfes as well as the host use the regular ipfw rc setup 
script as
provided with the base system, adding simply those ports open which provide 
services - a plain
and simple approach.

Checking the jails on the host in question (jails are contacting OpenLDAP 
server on host,
OpenLDAP server configured for test purposes to listen only on IPv6) leaves me 
with
inconclusive results.

Assuming a jail, called host-git, and a host, master.
Deleting the NDP entries aon hostgit via "ndp -c" leaves me with the initial 
reported issue
here, the solution is to ping the host-git first from host-master to "magically 
open" the IPv6
connection. After that, ldapsearch or any other IPv6 connections originating on 
the host-git
work again. That seems odd.

jails are vnet. Jails reside on a bridgeXX interface, sharing the physical NIC 
of the master
host. Just for the record.

I use a similar setup on a XigmaNAS host (13.2-RELEASE-p8), also with active 
IPFW on the
master host's side as well as IPFW enabled on the Jail's side. Difference to 
the above
mentioned setup: The jail is located on a different host, contacting 
master-host via a
switched network.

Regards,

oh

-- 
O. Hartmann

Re: NFSv4 crash of CURRENT

[FreeBSD User]

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 19:34
> > > Aan: FreeBSD CURRENT 
> > > Onderwerp: NFSv4 crash of CURRENT
> > >
> > > Hello,
> > >
> > > running CURRENT client (FreeBSD 15.0-CURRENT #4 
> > > main-n267556-69748e62e82a=  
> > : Sat Jan 13 18:08:32  
> > > CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned 
> > > cl=  
> > ient, other is FreeBSD  
> > > 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
> > >
> > > I can crash the client reproducable by accessing the one or other NFSv4 
> > > F=  
> > S (a simple ls -la).  
> > > The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla 
> > > a=  
> > ccess to the client  
> > > host, luckily the box recovers.  
> > Did you rebuild both the nfscommon and nfscl modules from the same sources?
> > I did a commit to main that changes the interface between these two
> > modules and did bump the
> > __FreeBSD_version to 1500010, which should cause both to be rebuilt.
> > (If you have "options NFSCL" in your kernel config, both should have
> > been rebuilt as a part of
> > the kernel build.)
> >  
> 
> Is anyone by chance seeing autofs in the backtrace too?
> 
> 

Hello Cy Shubert,

I forgot to mention that those crashes occur with autofs mounted filesystems. 
Good question,
by the way, I will check whether crashes also happen when mounting the 
tradidional way.

Kind regards,

oh

-- 
O. Hartmann

Re: NFSv4 crash of CURRENT

[FreeBSD User]

Am Mon, 15 Jan 2024 11:53:31 +0100
Peter Blok  schrieb:

> Hi,
> 
> Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
> automounted NFS
> is:
> 
> commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
> Author: Konstantin Belousov 
> Date:   Tue Jan 2 00:22:44 2024 +0200
> 
> nfsclient: limit situations when we do unlocked read-ahead by nfsiod
> 
> (cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)
> 
> When I remove the fix, the problem is gone. Add it back and the crash happens.
> 
> Peter
> 
> > On 15 Jan 2024, at 09:31, Peter Blok  wrote:
> > 
> > Hi,
> > 
> > I do have a crash on a NFS client with stable of today
> > (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. 
> > Maybe it is the
> > same problem.
> > 
> > I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
> > tab to
> > autocomplete it crashes with the below stack trace. If I plainly mount 
> > ports on /usr/ports
> > and do the same everything works. I am using NFSv3
> > 
> > Peter
> > 
> > 
> > 
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 04
> > fault virtual address   = 0x89
> > fault code  = supervisor read data, page not present
> > instruction pointer = 0x20:0x809645d4
> > stack pointer   = 0x28:0xfe00acadb830
> > frame pointer   = 0x28:0xfe00acadb830
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 6869 (csh)
> > trap number = 12
> > panic: page fault
> > cpuid = 2
> > time = 1705306940
> > KDB: stack backtrace:
> > #0 0x806232f5 at kdb_backtrace+0x65
> > #1 0x805d7a02 at vpanic+0x152
> > #2 0x805d78a3 at panic+0x43
> > #3 0x809d58ad at trap_fatal+0x38d
> > #4 0x809d58ff at trap_pfault+0x4f
> > #5 0x809af048 at calltrap+0x8
> > #6 0x804c7a7e at ncl_bioread+0xb7e
> > #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 0x806c3002 at kern_getdirentries+0x222
> > #13 0x806c33a9 at sys_getdirentries+0x29
> > #14 0x809d6180 at amd64_syscall+0x110
> > #15 0x809af95b at fast_syscall_common+0xf8
> > 
> > 
> >   
> >> On 15 Jan 2024, at 06:46, FreeBSD User  >> <mailto:free...@walstatt-de.de>> wrote:
> >> 
> >> Am Sun, 14 Jan 2024 20:34:12 -0800
> >> Cy Schubert mailto:cy.schub...@cschubert.com>> 
> >> schrieb:
> >>   
> >>> In message 
> >>>  >>> <mailto:CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c> 
> >>>  
> >>> om>
> >>> , Rick Macklem writes:  
> >>>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop 
> >>>>  >>>> <mailto:ronald-li...@klop.ws>>= wrote:
> >>>>> 
> >>>>> 
> >>>>> Van: FreeBSD User  >>>>> <mailto:free...@walstatt-de.de>>
> >>>>> Datum: 13 januari 2024 19:34
> >>>>> Aan: FreeBSD CURRENT  >>>>> <mailto:freebsd-current@freebsd.org>>
> >>>>> Onderwerp: NFSv4 crash of CURRENT
> >>>>> 
> >>>>> Hello,
> >>>>> 
> >>>>> running CURRENT client (FreeBSD 15.0-CURRENT #4 
> >>>>> main-n267556-69748e62e82a=
> >>>> : Sat Jan 13 18:08:32
> >>>>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned 
> >>>>> cl=
> >>>> ient, other is FreeBSD
> >>>>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
> >>>>> 
> >>>>> I can crash the client reproducable by accessing the one or other NFSv4 
> >>>>> F=
> >>>> S (a simple ls -la).
> >>>>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla 
> >>>>> a=
> >>>> ccess to the client
> >>>>> host, luckily the box recovers.
> >>>> Did you rebuild both the nfscommon and nfscl modules from the same 
> >>>> sources?
> >>>> I did a commit to main that changes the interface between these two
> >>>> modules and did bump the
> >>>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
> >>>> (If you have "options NFSCL" in your kernel config, both should have
> >>>> been rebuilt as a part of
> >>>> the kernel build.)
> >>>>   
> >>> 
> >>> Is anyone by chance seeing autofs in the backtrace too?
> >>> 
> >>>   
> >> 
> >> Hello Cy Shubert,
> >> 
> >> I forgot to mention that those crashes occur with autofs mounted 
> >> filesystems. Good
> >> question, by the way, I will check whether crashes also happen when 
> >> mounting the
> >> tradidional way.
> >> 
> >> Kind regards,
> >> 
> >> oh
> >> 
> >> -- 
> >> O. Hartmann  
> >   
> 

good catch!

-- 
O. Hartmann

Re: NFSv4 crash of CURRENT

[FreeBSD User]

ofs related 
> >>> Maybe it is the
> >>> same problem.
> >>> 
> >>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and 
> >>> type tab to
> >>> autocomplete it crashes with the below stack trace. If I plainly mount 
> >>> ports on
> >>> /usr/ports and do the same everything works. I am using NFSv3
> >>> 
> >>> Peter
> >>> 
> >>> 
> >>> 
> >>> 
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 2; apic id = 04
> >>> fault virtual address = 0x89
> >>> fault code = supervisor read data, page not present
> >>> instruction pointer = 0x20:0x809645d4
> >>> stack pointer= 0x28:0xfe00acadb830
> >>> frame pointer= 0x28:0xfe00acadb830
> >>> code segment = base 0x0, limit 0xf, type 0x1b
> >>> = DPL 0, pres 1, long 1, def32 0, gran 1
> >>> processor eflags = interrupt enabled, resume, IOPL = 0
> >>> current process = 6869 (csh)
> >>> trap number = 12
> >>> panic: page fault
> >>> cpuid = 2
> >>> time = 1705306940
> >>> KDB: stack backtrace:
> >>> #0 0x806232f5 at kdb_backtrace+0x65
> >>> #1 0x805d7a02 at vpanic+0x152
> >>> #2 0x805d78a3 at panic+0x43
> >>> #3 0x809d58ad at trap_fatal+0x38d
> >>> #4 0x809d58ff at trap_pfault+0x4f
> >>> #5 0x809af048 at calltrap+0x8
> >>> #6 0x804c7a7e at ncl_bioread+0xb7e
> >>> #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 0x806c3002 at kern_getdirentries+0x222
> >>> #13 0x806c33a9 at sys_getdirentries+0x29
> >>> #14 0x809d6180 at amd64_syscall+0x110
> >>> #15 0x809af95b at fast_syscall_common+0xf8
> >>> 
> >>> 
> >>> 
> >>> On 15 Jan 2024, at 06:46, FreeBSD User  >>> <mailto:free...@walstatt-de.de>> wrote:
> >>> 
> >>> Am Sun, 14 Jan 2024 20:34:12 -0800
> >>> Cy Schubert  >>> <mailto:cy.schub...@cschubert.com>> schrieb:
> >>> 
> >>> In message 
> >>>  >>> <mailto:CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c> 
> >>>  
> >>> om>  
> >>> , Rick Macklem writes:
> >>> 
> >>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop  >>> <mailto:ronald-li...@klop.ws>>= wrote:
> >>> 
> >>> 
> >>> 
> >>> Van: FreeBSD User mailto:freebsd@walstatt-dede>>
> >>> Datum: 13 januari 2024 19:34
> >>> Aan: FreeBSD CURRENT  >>> <mailto:freebsd-current@freebsd.org>>
> >>> Onderwerp: NFSv4 crash of CURRENT
> >>> 
> >>> Hello,
> >>> 
> >>> running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a=
> >>> 
> >>> : Sat Jan 13 18:08:32
> >>> 
> >>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl=
> >>> 
> >>> ient, other is FreeBSD
> >>> 
> >>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
> >>> 
> >>> I can crash the client reproducable by accessing the one or other NFSv4 F=
> >>> 
> >>> S (a simple ls -la).
> >>> 
> >>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a=
> >>> 
> >>> ccess to the client
> >>> 
> >>> host, luckily the box recovers.
> >>> 
> >>> Did you rebuild both the nfscommon and nfscl modules from the same 
> >>> sources?
> >>> I did a commit to main that changes the interface between these two
> >>> modules and did bump the
> >>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
> >>> (If you have "options NFSCL" in your kernel config, both should have
> >>> been rebuilt as a part of
> >>> the kernel build.)
> >>> 
> >>> 
> >>> Is anyone by chance seeing autofs in the backtrace too?
> >>> 
> >>> 
> >>> 
> >>> Hello Cy Shubert,
> >>> 
> >>> I forgot to mention that those crashes occur with autofs mounted 
> >>> filesystems. Good
> >>> question, by the way, I will check whether crashes also happen when 
> >>> mounting the
> >>> tradidional way.
> >>> 
> >>> Kind regards,
> >>> 
> >>> oh
> >>> 
> >>> --
> >>> O. Hartmann  
> >   
> 



-- 
O. Hartmann

Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

[FreeBSD User]

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 affect FreeBSD.
> > 
> > The autoconf script checks that it is running in a RedHat or Debian
> > package build environment before trying to proceed. There are also
> > checks for GCC and binutils ld.bfd. And I'm not sure that the payload
> > (a precompiled Linux object file) would work with FreeBSD and
> > /lib/libelf.so.2.
> > 
> > See
> > 
> > https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27  
> 
> See also the following message from the FreeBSD security officer:
> 
> https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> 

Thank you very much for the quick answer.

Kind regards
oh

-- 
O. Hartmann

pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[FreeBSD User]

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 core dumps while performing installation. apache24 and redis are ports I 
realized this
misbehaviour on ALL 14-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 the same behaviour when updating 
packages on
target hosts where pkg is first updated, on those hosts, nextcloud-server and 
icinga2 host
utilizing also databases/redis and www/apache24, pkg fails the same way.

I do not dare to update our poudriere hosts since the problem seems to pop up 
when pkg 1.21.0
is installed, no matter whether I use poudriere built ports (from our own 
builder hosts) or
recent source tree with portmaster/make build process.

Looks like a serious bug to me and not a site/user specific problem. Hopefully 
others do
realize the same ...

Thanks in advance,

oh 


-- 
O. Hartmann

Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

[FreeBSD User]

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
> > 
> > FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited 
> > skills do not allow
> > me to judge wether the described exploit mechanism also works on FreeBSD.
> > RedHat already sent out a warning, the workaround is to move back towards 
> > an older variant.
> > 
> > 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.
> > 
> > Thanks in advance,
> > 
> > O. Hartmann
> > 
> >   
> 
> See so@'s answer from a couple days ago:
> 
> https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html
> 
> TL;DR no
> 
> Thanks,
> 
> Kyle Evans

Thank you very much.

Kind regards,

oh

-- 
O. Hartmann

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg-static core dumps on some ports

[FreeBSD User]

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 core dumps while performing installation. apache24 and redis are ports I 
> realized this
> misbehaviour on ALL 14-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 the same behaviour 
> when updating
> packages on target hosts where pkg is first updated, on those hosts, 
> nextcloud-server and
> icinga2 host utilizing also databases/redis and www/apache24, pkg fails the 
> same way.
> 
> I do not dare to update our poudriere hosts since the problem seems to pop up 
> when pkg 1.21.0
> is installed, no matter whether I use poudriere built ports (from our own 
> builder hosts) or
> recent source tree with portmaster/make build process.
> 
> Looks like a serious bug to me and not a site/user specific problem. 
> Hopefully others do
> realize the same ...
> 
> Thanks in advance,
> 
> oh 
> 
> 

Hello,

after following a recommnedation checking dependencies on ports via pkg check 
-Bn, recompiling
pkg via "portmaster -df ports-mgmt/pkg" along with all ports found by the check 
command as
well a sqlite (precaustion), still the pkg-static binary drops core dumps on 
some ports.

Phenomenon: When updating existing ports, like

www/apache24
databases/redis
net/openldap26-server
misc/e2fsprogs-libuuid

building the port runs smootly, but pkg-static dies on deleting attempt of the
old/to-be-reinstalled port. The problem arises by using portmaster as well as 
performing "make
install/make deinstall" in the specific target port.

Last port I hit is  misc/e2fsprogs-libuuid.

My skills debugging core dumps are rather limited, our boxes do have debugging 
disabled. Since
the problem spreads across several hosts running CURRENT (same IcyBridge CPU 
generation, but
one host most recent CURRENT with LLVM18, the other one running a CURRENT 
compiled 4 days ago
and as of last week the problem arose also on 14-STABLE on a box in the lab 
when performing
the tansition from pkg 1.20.9_1 -> 1.21.0), I'd exclude a hardware/memory issue.

Using (a freshly recompiled) gdb 14 from ports gives not much:

[...]
root@thor:/usr/ports # gdb  /usr/local/sbin/pkg-static
/packages/portmaster-backup/pkg-static.core
GNU gdb (GDB) 14.1 [GDB v14.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd15.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/pkg-static...
(No debugging symbols found in /usr/local/sbin/pkg-static)
[New LWP 101269]
Core was generated by `/usr/local/sbin/pkg-static delete -yf 
e2fsprogs-libuuid-1.47.0'.
Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
#0  0x00b3de2b in strlen_baseline ()



Kind regards,
oh



-- 
O. Hartmann

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[FreeBSD User]

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,
> >>>
> >>> 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 core dumps while performing installation. apache24 and redis are 
> >>> ports I realized
> >>> this misbehaviour on ALL 14-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 the same 
> >>> behaviour when
> >>> updating packages on target hosts where pkg is first updated, on those 
> >>> hosts,
> >>> nextcloud-server and icinga2 host utilizing also databases/redis and 
> >>> www/apache24, pkg
> >>> fails the same way.
> >>>
> >>> I do not dare to update our poudriere hosts since the problem seems to 
> >>> pop up when pkg
> >>> 1.21.0 is installed, no matter whether I use poudriere built ports (from 
> >>> our own builder
> >>> hosts) or recent source tree with portmaster/make build process.
> >>>
> >>> Looks like a serious bug to me and not a site/user specific problem. 
> >>> Hopefully others do
> >>> realize the same ...
> >>>
> >>> Thanks in advance,
> >>>
> >>> oh  
> >>
> >>
> >> Hmm, I just tried to reproduce that. Both ports mentioned, databases/redis
> >> and www/apache24, can be built and installed with Portmaster. The box is a
> >> 15.0-CURRENT with pkg-1.21.0.
> >>
> >> Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir'
> >> show some inconsistencies?
> >>
> >> Best wishes,
> >> Rainer
> >>
> >>  
> > using portmaster or not are strictly unlikely to be helpful here.
> > 
> > The right way to test if to report running with pkg - and also to 
> > recommand
> > testing with default options in pkg.conf.
> > 
> > Best regards,
> > Bapt  
> 
> This is correct and certainly better. I was not aware of this.
> 
> Fortunately, my less optimal suggestions helped O. Hartmann in this case 
> to find the missing and outdated dependencies.
> 
> In any case, many thanks for this helpfull advice.
> 
> Regards,
> Rainer
> 
> 

Hello,

@Babptist : it should be pkg -d, shouldn't it? Or do I miss again something 
here?

With today's update to pkg 1.21.1 the problem has vanished. 

@R. Hurling: Thanks for the tip using the checks. I missed that and somehow it 
revealed some
problems here I hopefully have fixed so far.

Kind regads and thanks,

oh
-- 
O. Hartmann

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

[FreeBSD User]

Am Tue, 9 Apr 2024 09:18:49 -0700
Gleb Smirnoff  schrieb:

> On Tue, Apr 09, 2024 at 04:47:07AM -0700, David Wolfskill wrote:
> D> --- trap 0xc, rip = 0x80b208c5, rsp = 0xfe048c204920, rbp = 
> 0xfe
> D> 048c204960 ---
> D> __mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfe048c204960
> D> clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfe048c204ab0
> D> local_rpcb() at local_rpcb+0x11b/frame 0xfe048c204b50
> D> rpcb_unset() at rpcb_unset+0x24/frame 0xfe048c204bb0
> D> svc_tp_create() at svc_tp_create+0xee/frame 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, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = 
> 0x3f00
> D> 96f7168, rbp = 0x3f0096f7230 ---
> D> KDB: enter: panic
> D> [ thread pid 1208 tid 101107 ]
> D> Stopped at  kdb_enter+0x33: movq$0,0x104eb92(%rip)  
> D> db>   
> 
> This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.
> 
> Sorry for that!
> 

Hello all.

The crash is still present on the most recent checked out sources as of minutes 
ago.

I just checked out on HEAD the latest commits (see below, just for the record 
and to prevent
being wrong here).

[...]
commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/main, 
origin/HEAD)
Author: Alan Cox 
Date:   Mon Apr 8 00:05:27 2024 -0500

arm64 pmap: Add ATTR_CONTIGUOUS support [Part 2]

Create ATTR_CONTIGUOUS mappings in pmap_enter_object().  As a result,
when the base page size is 4 KB, the read-only data and text sections
of large (2 MB+) executables, e.g., clang, can be mapped using 64 KB
pages.  Similarly, when the base page size is 16 KB, the read-only
data section of large executables can be mapped using 2 MB pages.

Rename pmap_enter_2mpage().  Given that we have grown support for 16 KB
base pages, we should no longer include page sizes that may vary, e.g.,
2mpage, in pmap function names.  Requested by: andrew

Co-authored-by: Eliot Solomon 
Differential Revision:  https://reviews.freebsd.org/D44575

commit e205fd318a296ffdb7392486cdcec7f660fcffcf
Author: Gleb Smirnoff 
Date:   Tue Apr 9 09:16:52 2024 -0700

rpc: use new macros to lock socket buffers

Fixes:  d80a97def9a1db6f07f5d2e68f7ad62b27918947

commit cb20a74ca06381e96c41cb4495d633710cc6cb79
Author: Stephen J. Kiernan 
Date:   Wed Apr 3 17:04:57 2024 -0400


-- 
O. Hartmann

serial/ulscom: response timeout using pySerial/esptool.py

[FreeBSD User]

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 Gold) or an oldish Fujitsu Celsius 7XX workstation, 6 
core Haswell
XEON.

Phenomenon: a couple of weeks now I try to connect to several Xtensa ESP32 dev 
boards
(ESP32-WROOM32 with CP2101 or CP2104 UART) via comms/py-esptool (doesn't matter 
whether it is
tho port's py39-esptool 4.5 or the latest py-esptool 4.7.0, doesn't matter 
whether pkg package
or self compiled on CURRENT and 14-STABLE, on all hardware platforms same 
result).

Attaching the ESP devel module via Micro USB cable (several type, differnt 
vendors tried ...)
show

dmesg:
[...]
ugen0.4:  at usbus0
uslcom0 on uhub3
uslcom0: 
on usbus0
[...]

When trying to connect to the ESP32 via below shown command (--trace not every 
time issued), I
get no connection:

[ohartmann]: esptool.py --trace --chip esp32 --baud 115200 --port /dev/cuaU1  
flash_id
esptool.py v4.7.0
Loaded custom configuration from /pool/home/ohartmann/esptool.cfg
Serial port /dev/cuaU1
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 
timeout=0.100 data=
07071220  | ... 
  | 
  | 
TRACE +0.000 Write 46 bytes: 
c824 000707122055 | ...$ UUU
  | 
 55c0 | U.
TRACE +0.102 No serial data received.
TRACE +0.052 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
07071220  | ... 
  | 
  | 
TRACE +0.000 Write 46 bytes: 
c824 000707122055 | ...$ UUU
  | 
 55c0 | U.
TRACE +0.107 No serial data received.
TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
07071220  | ... 
  | 
  | 
TRACE +0.000 Write 46 bytes: 
c824 000707122055 | ...$ UUU
  | 
 55c0 | U.
TRACE +0.107 No serial data received.
TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
07071220  | ... 
  | 
  | 
TRACE +0.000 Write 46 bytes: 
c824 000707122055 | ...$ UUU
  | 
 55c0 | U.


A serial exception error occurred: device reports readiness to read but 
returned no data
(device disconnected or multiple access on port?) Note: This error originates 
from pySerial.
It is likely not a problem with esptool, but with the hardware connection or 
drivers. For
troubleshooting steps visit:
https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
[...]


Whatever baud rate issued, in most cases on all tested OS versions and almost 
all hardware
platforms except the Fujistu Celsius 7XX (2015 model) I do not get any 
connection! And it get
more weird: To avoid out-of-sync-software I recompiled everything via 
"portmaster -df
comms/py-pyserial comms/py-esptool" and after that, everything was fine, the 
connection was
made, I got results out of the chip. Seconds later same problems.

I exchanged cablings, exchanged the ESP32 model and vendor. Invariants are 
14-STABLE, daily
compiled, CURRENT. daily compiled. On my private box (old Z77 based IvyBridge 
ASRock crap), a
couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo Q5XX boxes 
there is always
this weird error message, but in very rare cases I get connection.

Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last complied 
today noon). No
matter what ESP32, no matter what vendor, no matter what cablin used: 
connection is established
at any BAUD rate issued at any time. Not one single failure as shown above in 
any session (I
checked several tenth times)!

Now I'm out of ideas and I suspect the CP210X ulscom serial driver to have 
trouble with most
onboard serial chipsets.

Can anyone help me track down this issue? Is there anything I could have missed?

I drives me nuts ...

Thanks in advance,

Oliver

 
-- 
O. Hartmann

Re: serial/ulscom: response timeout using pySerial/esptool.py

[FreeBSD User]

Am Thu, 25 Apr 2024 21:51:21 +0200
Tomek CEDRO  schrieb:

> CP2102 are pretty good ones and never let me down :-)
> 
> Is your UART connection to ESP32 working correctly? Can you see the
> boot message and whatever happens next in terminal (cu / minicom)? Are
> RX TX pins not swapped? Power supply okay?

The ESP32 used are 
- ESP32-WROOM32 D1 mini, have 10 pieces of those, on each single one same 
behaviour on same
host
- ESP32-WROOM32 sold by Chinese distributor AZdelivery in Germany, I got a 
bunch of them,
Revision 1 (baught 2020) and a more recent revision V4, baught a couple 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,
mainboard is a crappy Z77 Pro4 ASrock, 

pciconf excerpts:
[...]
ichsmb0@pci0:0:31:3:class=0x0c0500 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x1e22
subvendor=0x1849 subdevice=0x1e22 vendor = 'Intel Corporation'
device = '7 Series/C216 Chipset Family SMBus Controller'
class  = serial bus
subclass   = SMBus
bar   [10] = type Memory, range 64, base 0xf7c15000, size 256, enabled
bar   [20] = type I/O Port, range 32, base 0xf040, size 32, enabled
..
ehci1@pci0:0:29:0:  class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x1e26
subvendor=0x1849 subdevice=0x1e26 vendor = 'Intel Corporation'
device = '7 Series/C216 Chipset Family USB Enhanced Host Controller'
class  = serial bus
subclass   = USB
bar   [10] = type Memory, range 32, base 0xf7c17000, size 1024, enabled
cap 01[50] = powerspec 2  supports D0 D3  current D0
cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
cap 13[98] = PCI Advanced Features: FLR TP
..
xhci0@pci0:0:20:0:  class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x1e31
subvendor=0x1849 subdevice=0x1e31 vendor = 'Intel Corporation'
device = '7 Series/C210 Series Chipset Family USB xHCI Host Controller'
class  = serial bus
subclass   = USB
bar   [10] = type Memory, range 64, base 0xf7c0, size 65536, enabled
cap 01[70] = powerspec 2  supports D0 D3  current D0
cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message



> 
> Are boards generic devkits of custom hardware? ESP32 in addition to RX
> TX needs two control lines Reset and Boot that will switch the chip to
> bootloader / flashing mode. Most USB-to-UART use RTS/CTS lines for
> that. Are you sure these lines are available on your board and
> connected to the target correctly? Do you have Reset and Boot buttons
> on the board so you could trigger bootloader by hand (hold Boot, press
> and release Reset, device will be in bootloader upload mode, retry
> esptool flashing now). You can also play with the buttons with active
> terminal attached (i.e. minicom) to see if they work as expected.

I tried minivom, but I have to confess, I'm a "noice" in that matter, so do not 
expect
professional debugging infos:

Unsuccessful issueing the following command on three different types of ESP32 as
described above, I use at least two of them and even one (a D1 mini) just 
unfolded from
its sealed anti static bag) while observing the minicom attached via -D 
/dev/cuaU1:

[...]
[ohartmann]: esptool.py --chip esp32 --baud 115200 --connect-attempts 400 
--port /dev/cuaU1
read_mac esptool.py v4.7.0
Loaded custom configuration from /pool/home/ohartmann/esptool.cfg
Serial port /dev/cuaU1
Connecting...

A serial exception error occurred: device reports readiness to read but 
returned no data
(device disconnected or multiple access on port?) Note: This error originates 
from pySerial.
It is likely not a problem with esptool, but with the hardware connection or 
drivers. For
troubleshooting steps visit:
https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

[...]

On the reference minicom terminal I observed with the D1 mini (minicom -b 
115200  -D
/dev/cuaU1):
[...]

Welcome to minicom 2.8

OPTIONS: I18n 
Compiled on Apr 27 2024, 09:04:50.
Port /dev/cuaU1, 10:50:53

Press CTRL-A Z for help on special keys

ts Jul 29 2019 12:21:46

rst:x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 U� U� U� U� U� U� U� U


[... the older ESP32 from 2020 ...]

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
�un  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
es Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH]�(�:���   �


[... and the one purchased last year, called revisio

Re: serial/ulscom: response timeout using pySerial/esptool.py

[FreeBSD User]

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 on an ESP32 D1 mini, not working 
with the
afore mentioned host, gives this (after a loop of 100x issued the esptool.py 
command, no
issues detected):

[...]
nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac
esptool.py v4.5
Serial port /dev/cuaU0
Connecting..
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme 
None
Crystal is 40MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
Running stub...
Stub running...
MAC: XX:XX:XX:XX:XX:XX
Hard resetting via RTS pin...
[...]

.. and those from AZdelivery (larger and older chips):
[...]
nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac
esptool.py v4.5
Serial port /dev/cuaU0
Connecting.
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme 
None
Crystal is 40MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
Running stub...
Stub running...
MAC: XX:XX:XX:XX:XX:XX
Hard resetting via RTS pin...

[...]

or

[... considered a different revision, but in fact the same old ESP32 as it 
reveals itself as
..]
nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac
esptool.py v4.5
Serial port /dev/cuaU0
Connecting...
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme 
None
Crystal is 40MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
Running stub...
Stub running...
MAC: XX:XX:XX:XX:XX:XX
Hard resetting via RTS pin...


Big question is: is this an issue introduced with FBSD 14? In 2020 I played 
around with my
first attempts using the Arduino IDE which worked pretty well, with some minor 
issues (I had
to perform several attempts to get connected, using 12- and 13-STABLE that 
time). But the
Arduino IDE doen't work as well


> Am Thu, 25 Apr 2024 21:51:21 +0200
> Tomek CEDRO  schrieb:
> 
> > CP2102 are pretty good ones and never let me down :-)
> > 
> > Is your UART connection to ESP32 working correctly? Can you see the
> > boot message and whatever happens next in terminal (cu / minicom)? Are
> > RX TX pins not swapped? Power supply okay?  
> 
> The ESP32 used are 
> - ESP32-WROOM32 D1 mini, have 10 pieces of those, on each single one same 
> behaviour on same
> host
> - ESP32-WROOM32 sold by Chinese distributor AZdelivery in Germany, I got a 
> bunch of them,
> Revision 1 (baught 2020) and a more recent revision V4, baught a couple 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,
> mainboard is a crappy Z77 Pro4 ASrock, 
> 
> pciconf excerpts:
> [...]
> ichsmb0@pci0:0:31:3:class=0x0c0500 rev=0x04 hdr=0x00 vendor=0x8086 
> device=0x1e22
> subvendor=0x1849 subdevice=0x1e22 vendor = 'Intel Corporation'
> device = '7 Series/C216 Chipset Family SMBus Controller'
> class  = serial bus
> subclass   = SMBus
> bar   [10] = type Memory, range 64, base 0xf7c15000, size 256, enabled
> bar   [20] = type I/O Port, range 32, base 0xf040, size 32, enabled
> ..
> ehci1@pci0:0:29:0:  class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 
> device=0x1e26
> subvendor=0x1849 subdevice=0x1e26 vendor = 'Intel Corporation'
> device = '7 Series/C216 Chipset Family USB Enhanced Host Controller'
> class  = serial bus
> subclass   = USB
> bar   [10] = type Memory, range 32, base 0xf7c17000, size 1024, enabled
> cap 01[50] = powerspec 2  supports D0 D3  current D0
> cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
> cap 13[98] = PCI Advanced Features: FLR TP
> ..
> xhci0@pci0:0:20:0:  class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 
> device=0x1e31
> subvendor=0x1849 subdevice=0x1e31 vendor = 'Intel Corporation'
> device = '7 Series/C210 Series Chipset Family USB xHCI Host 
> Controller'
> class  = serial bus
> subclass   = USB
> bar   [10] = type Memory, range 64, base 0xf7c0, size 65536, enabled
> cap 01[70] = powerspec 2  supports D0 D3  current D0
> cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
> 
> 
> 
> > 
> > Are boards generic devkits of custom hardware? ESP32 in add

Re: CURRENT kernel crash beyond git: 02d15215cef2

[FreeBSD User]

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 10:56:09 CEST 2024 amd64. Customized 
> > kernel.
> > 
> > After that commit, booting the kernel dies silently without any trace/core 
> > or similar and
> > resetting the system.
> > 
> > I tried to enable at least the standard debugging features, but that 
> > doesn't improve the
> > fact the machine resets/dies silently.  
> 
> Check the archive! Known issue:
> 
> https://lists.freebsd.org/archives/freebsd-current/2024-May/005990.html
> 
> No, idea why the fix hasn't been committed yet:
> 
> https://lists.freebsd.org/archives/freebsd-current/2024-May/005993.html
> 

My apology.
Nuni Teixeiras posting was right below mine :-(

Sorry for the noise,

Thanks and kind regards
oh

-- 
O. Hartmann

Re: main cadd2ca217 doesn't boot

[FreeBSD User]

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 part of a bigger series where it works fine, so 
> this slipped through cracks without getting noticed.
> 
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?
> 
> Bojan

The patch fixes the problem on amd64 here ...

-- 
O. Hartmann

CURRENT: exec_machdep.c:80:2: error: KDB must be enabled in order for DDB

[FreeBSD User]

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.  Always need this:
nooptions   KDB # Enable kernel debugger support.
nooptions   KDB_TRACE   # Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
include "std.nodebug"
[...]

to disable KDB. The include "std.debug" in GENERIC is new, prior to its 
occurence the sketched
scheme worked fine for me, but now I get this error while perfoming "make -jX 
buildworld
buildkernel":

[...]
/usr/src/sys/amd64/amd64/exec_machdep.c:80:2: error: KDB must be enabled in 
order for DDB to
work! 80 | #error KDB must be enabled in order for DDB to work!
  |  ^
[...]

Apart from the recommendation not to disable KDB in CURRENT, is there a way to 
disable
debugging features and mimik a stable branch?

Thanks in advance,

oh



-- 
O. Hartmann

bridge: no traffic with vnet (epair) beyond bridge device

[FreeBSD User]

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
bridge is performed by the jail.conf script.

I do not know how long the setup worked, but out of the blue, last week after a 
longish
poudriere run after updating the host to most recent CURRENT (as of today, 
latest update
kernel and world) and performing "etcupdate" on both the host and all jails, 
traffic beyond
the bridge is not seen on the network! All jails can communicate with each 
other. Traffic from
the host itself is routed via igb0 to network and back via igb1 onto the bridge.

I check all setups for net.link.bridge:

net.link.bridge.ipfw: 0
net.link.bridge.log_mac_flap: 1
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

I did not change anything (knowingly). 

I also have an oldish box running single socket processor, also driven by the 
very same
CURRENT and similar, but not identical setup. The box is running very well and 
the bridge is
working as expected.

I was wondering if something in detail has changed in the handling of jails, 
epair and
bridges. I followed the setup "after the book", nothing suspicious.

Maybe someone has a clue what might break the bridge.

By the way: ifconfig bridge1 looks as always, igb1 as member and it doesn't 
make any
difference whether I force the bridge to inherit igb1's MAC or not.

We also checked for the switches whether BPDU Guard may have been triggered, 
but everything
looks good from the outside - execept the fact the brdiged interface seems 
inactive (but up)
from the outside ...

Kind regards

oh

-- 
O. Hartmann

Re: bridge: no traffic with vnet (epair) beyond bridge device

[FreeBSD User]

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 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
> > bridge is performed by the jail.conf script.
> > 
> > I do not know how long the setup worked, but out of the blue, last week 
> > after a longish
> > poudriere run after updating the host to most recent CURRENT (as of 
> > today, latest update
> > kernel and world) and performing "etcupdate" on both the host and all 
> > jails, traffic beyond
> > the bridge is not seen on the network! All jails can communicate with 
> > each other. Traffic from
> > the host itself is routed via igb0 to network and back via igb1 onto 
> > the bridge.
> > 
> > I check all setups for net.link.bridge:
> > 
> > net.link.bridge.ipfw: 0
> > net.link.bridge.log_mac_flap: 1
> > net.link.bridge.allow_llz_overlap: 0
> > net.link.bridge.inherit_mac: 0
> > net.link.bridge.log_stp: 0
> > net.link.bridge.pfil_local_phys: 0
> > net.link.bridge.pfil_member: 0
> > net.link.bridge.ipfw_arp: 0
> > net.link.bridge.pfil_bridge: 0
> > net.link.bridge.pfil_onlyip: 0
> > 
> > I did not change anything (knowingly).
> > 
> > I also have an oldish box running single socket processor, also driven 
> > by the very same
> > CURRENT and similar, but not identical setup. The box is running very 
> > well and the bridge is
> > working as expected.
> > 
> > I was wondering if something in detail has changed in the handling of 
> > jails, epair and
> > bridges. I followed the setup "after the book", nothing suspicious.  
> 
> "after the book" = the IP of the host itself is not on igb1 but on a 
> different interface or on the bridge?
> 
> Is there a firewall active on the box itself? Which one?
> 
> What does wireshark / a traffic dump at the physical interface level 
> tell compared to a traffic dump at the switch interface? Did you replace 
> the cable / SFP / move to a different switch port as a test?
> 
> I suggest to provide the output of ifconfig -a and netstat -rn (feel 
> free to mangle the IPs, as long as the mangling is a consistent 
> replacement and not a cut-off).
> 
> Bye,
> Alexander.
> 

Hello Alexander and everybody brave enough reading my post.

Somehow I managed it to let 

"ifconfig_igb1="up"

disappear - I guess by accident when sneaking through the rc.conf file.

igb1 is the physical device connecting to the network. The bridge is layer 2 
only, no IP, only
the vnet-portions pointing towards the jail do have IPv6 and IPv4. The bridge 
has around 20
members, the last entry is igb1 - I never checked whether it is up ...
Sorry!

Kind regards,

oh

-- 
O. Hartmann


pgpEjETT1Jdg5.pgp
Description: OpenPGP digital signature

Re: git: 8d3c3b52423f - main - mpi3mr: Track IO per target counter during queue poll with local variable

[FreeBSD User]

Am Thu, 6 Jun 2024 10:39:33 GMT
Sumit Saxena  schrieb:

> The branch main has been updated by ssaxena:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=8d3c3b52423f9740da424aa6dd73a20e694a9e08
> 
> commit 8d3c3b52423f9740da424aa6dd73a20e694a9e08
> Author: Chandrakanth patil 
> AuthorDate: 2024-06-06 10:28:38 +
> Commit: Sumit Saxena 
> CommitDate: 2024-06-06 10:39:16 +
> 
> mpi3mr: Track IO per target counter during queue poll with local variable
> 
> Reviewed by:imp
> Approved by:imp
> Differential revision:  https://reviews.freebsd.org/D44494
> ---
>  sys/dev/mpi3mr/mpi3mr_cam.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/sys/dev/mpi3mr/mpi3mr_cam.c b/sys/dev/mpi3mr/mpi3mr_cam.c
> index e3958ed8daf2..e00d61073d96 100644
> --- a/sys/dev/mpi3mr/mpi3mr_cam.c
> +++ b/sys/dev/mpi3mr/mpi3mr_cam.c
> @@ -1839,6 +1839,7 @@ int mpi3mr_remove_device_from_os(struct mpi3mr_softc 
> *sc, U16 handle)
>  {
>   int retval = 0;
>   struct mpi3mr_target *target;
> + unsigned int target_outstanding;
>  
>   mpi3mr_dprint(sc, MPI3MR_EVENT,
>   "Removing Device (dev_handle: %d)\n", handle);
> @@ -1856,16 +1857,17 @@ int mpi3mr_remove_device_from_os(struct mpi3mr_softc 
> *sc, U16 handle)
>  
>   target->flags |= MPI3MRSAS_TARGET_INREMOVAL;
>  
> - if (mpi3mr_atomic_read(&target->outstanding)) {
> - mpi3mr_dprint(sc, MPI3MR_ERROR, "there are [%2d] outstanding 
> IOs on target:
> %d"
> -   "Poll reply queue once\n",
> mpi3mr_atomic_read(&target->outstanding),
> -   target->per_id);
> - mpi3mr_poll_pend_io_completions(sc);
> - if (mpi3mr_atomic_read(&target->outstanding))
> - mpi3mr_dprint(sc, MPI3MR_ERROR, "[%2d] outstanding IOs 
> present on
> target: %d"
> -   "despite poll\n",
> mpi3mr_atomic_read(&target->outstanding),
> -   target->per_id);
> - }
> + target_outstanding = mpi3mr_atomic_read(&target->outstanding);
> + if (target_outstanding) {
> + mpi3mr_dprint(sc, MPI3MR_ERROR, "there are [%2d] outstanding 
> IOs on target:
> %d "
> +   "Poll reply queue once\n", target_outstanding,
> target->per_id);
> + mpi3mr_poll_pend_io_completions(sc);
> + target_outstanding = mpi3mr_atomic_read(&target->outstanding);
> + if (target_outstanding)
> + target_outstanding = 
> mpi3mr_atomic_read(&target->outstanding);
> + 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->reset_in_progress) {
>   mpi3mr_rescan_target(sc, target);
> 
On recent CURRENT (FreeBSD 15.0-CURRENT #6 main-n270784-d1e652bf04b: Sun Jun 16 
18:19:49 CEST
2024 amd64) "make installkernel" fails with:

[...]
--- realinstall_subdir_mpi3mr ---
install -T release -o root -g wheel -m 444   mpi3mr.ko /boot/kernel/
install -T dbg -o root -g wheel -m 444   mpi3mr.ko.debug 
/usr/lib/debug/boot/kernel/
install: /usr/lib/debug/boot/kernel/INS@QhWCmf: No such file or directory
*** [_kmodinstall] Error code 71

make[4]: stopped in /usr/src/sys/modules/mpi3mr
make[4]: 1 error
[...]

The problem occurs when diabling makeoptions DEBUG=... in kernel configuration 
and including:

# Debugging support.  Always need this:
#optionsKDB # Enable kernel debugger support.
#optionsKDB_TRACE   # Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
include "std.nodebug"


On another host with the same CURRENT and mostly same configs, the problem does 
not
occur! The differenc between both is: tha failing host hasn't been updated for 
tha last 20
days, the other one has been updated almost every day.

On the failing host, "make cleanworld" has been issued before building 
world/kernel.

/etc/src.conf is also the same on both checked hosts. GENERIC compiles flawless.



-- 
O. Hartmann

Re: buildworld error

[FreeBSD User]

Am Sat, 24 Aug 2024 15:21:16 -0600
Warner Losh  schrieb:

> On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling  wrote:
> 
> > Hi Warner,
> >
> > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote:  
> > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling  wrote:  
> > > > I got the following buildworld error a recent -CURRENT
> > > >  
> > > > ===> stand/i386/pxeldr (all)  
> > > > `kldstat.o' is up to date.
> > > > -14152 bytes available
> > > >
> > > > The same happens on stable/14:
> > > >  
> > > > ===> stand/i386/pxeldr (all)  
> > > > -22344 bytes available  
> > > > ===> share/misc (all)  
> > > > --- loader ---
> > > > *** [loader] Error code 1
> > > >
> > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr
> > > > 1 error
> > > >
> > > > src.conf looks like the following:
> > > > WITH_BEARSSL=1
> > > > WITH_RETPOLINE=1
> > > > WITHOUT_CLEAN=1
> > > >
> > > > I remove the whole obj directories and tried several full builds, but  
> > the  
> > > > error persists for a while.
> > > >
> > > > Has any one a clue how to solve this?  
> > >
> > > Either disable pxe, raise the pxe limit (though it may not work), or  
> > select  
> > > the 4th loader for pxeboot.
> > >
> > > The loader is too big on BIOS to enable all the options.  
> >
> > I looked at src.conf(5), but didn't found a switch to disable pxe. What I
> > am
> > wondering about is that no one is facing the problem, since this it is a
> > pretty clean build without and special modifications, despite the ones
> > mention
> > above in the src.conf.
> >
> > Did you have a hint on how to disable pxe?
> >  
> 
> I was sure that I'd documented everything, but it seems not:
> 
> =t
> PXEBOOT_DEFAULT_INTERP=4th
> PXEBOOTSIZE?=525000
> 
> I'll look to make sure I don't have a commit stuck in a branch somewhere
> 
> Warner

After the introduction of

 WITHOUT_LOADER_PXEBOOT

and setting this knob to true in /etc/src.conf has mitigated for me the problem 
reported above
(it appears reproduceable when setting WITH_BEARSSL for me). But the problem 
mentione
reappeared recently (a week or two on CURRENT, building on testboxes almost 
daily ...) again.

Just for the record  


Kind regards,

oh

-- 
O. Hartmann

Re: buildworld error

[FreeBSD User]

Am Sat, 24 Aug 2024 15:21:16 -0600
Warner Losh  schrieb:

> On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling  wrote:
> 
> > Hi Warner,
> >
> > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote:  
> > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling  wrote:  
> > > > I got the following buildworld error a recent -CURRENT
> > > >  
> > > > ===> stand/i386/pxeldr (all)  
> > > > `kldstat.o' is up to date.
> > > > -14152 bytes available
> > > >
> > > > The same happens on stable/14:
> > > >  
> > > > ===> stand/i386/pxeldr (all)  
> > > > -22344 bytes available  
> > > > ===> share/misc (all)  
> > > > --- loader ---
> > > > *** [loader] Error code 1
> > > >
> > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr
> > > > 1 error
> > > >
> > > > src.conf looks like the following:
> > > > WITH_BEARSSL=1
> > > > WITH_RETPOLINE=1
> > > > WITHOUT_CLEAN=1
> > > >
> > > > I remove the whole obj directories and tried several full builds, but  
> > the  
> > > > error persists for a while.
> > > >
> > > > Has any one a clue how to solve this?  
> > >
> > > Either disable pxe, raise the pxe limit (though it may not work), or  
> > select  
> > > the 4th loader for pxeboot.
> > >
> > > The loader is too big on BIOS to enable all the options.  
> >
> > I looked at src.conf(5), but didn't found a switch to disable pxe. What I
> > am
> > wondering about is that no one is facing the problem, since this it is a
> > pretty clean build without and special modifications, despite the ones
> > mention
> > above in the src.conf.
> >
> > Did you have a hint on how to disable pxe?
> >  
> 
> I was sure that I'd documented everything, but it seems not:
> 
> WITHOUT_LOADER_PXEBOOT=t
> PXEBOOT_DEFAULT_INTERP=4th
> PXEBOOTSIZE?=525000
> 
> I'll look to make sure I don't have a commit stuck in a branch somewhere
> 
> Warner

Just a note:

src.conf(5) does not have (yet?) "PXEBOOTSIZE", instead, "LOADERSIZE" is 
mentioned, nor do I
see PXEBOOT_DEFAULT_INTERP in the manpage. I think that would be worth being 
mentioned.

Regards,

Oliver

-- 
O. Hartmann

/usr/share/mk/bsd.sanitizer.mk not found

[FreeBSD User]

Hallo,

running latest CURRENT as of FreeBSD 14.0-CURRENT #147 
main-n248437-600745f1e226: Mon Aug  2
18:34:54 CEST 2021 amd64, while compiling x11/nividia-driver, I get an error, 
stating
/usr/share/mk/bsd.sanitizer.mk is missing. This file ist existent in 
/usr/src/share/mk/, but
does not get installed.

devel/libsysinfo is another port (requisite for firefox) failing due to the 
same error.

What's wrong here?


-- 
O. Hartmann

databases/postgresl13-server issue: micsompilation on IvyBridge arch?

[FreeBSD User]

Hello,

on all(!) of my home systems based on Intel's IvyBridge CPU architecture

a) CPU microcode: updated from 0x1f to 0x21
   CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.09-MHz K8-class CPU)

b) CPU microcode: updated from 0x1f to 0x21
   CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)

I face a severe and nasty problem:

database/postgresql12-server, database/postgresql13-server, 
database/postgresql14-server, when
installed, do not allow any kind of tcp/ip connections, even on ::1 or 
127.0.0.1 (localhost).
All systems in question are dual stack and fully configured using IPv6. 
Firewall is FreeBSD
standard IPFW running from /etc/rc.conf (port 5432/tcp is open and listening as 
one can check
via sockstat -4 or sockstat -6).

The hosts in question do run 14-CURRENT (with customized kernels).

Phenomenon:

Login locally via "psql -U postgres -d postgres" via socket works for ALL DB 
users on all
configured to access databases as expected. Login via "psql -U postgres -d 
postgres -h
localhost" (or any form of an IP if access tried from another remote host, even 
locally via
127.0.0.1 or ::1) does result in:

: psql -U postgres -d postgres -h localhost
psql: error: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

On the server's postgresql log I always see connection attempts like:

[...]
2021-08-08 08:56:57.601 GMT [42987] LOG:  connection received: host=localhost 
port=12340

but nothing more, no error message or any kind of timeout message. 

I tried to raise the log level to debug, but it is always nothing shown execept 
the initial
connection attempt.

What I tried so far:
I used either self compiled ports or packages taken via pkg fetch from the 
official FreeBSD
pkg repos. I had LLVM suspected to miscompile something on IvyBridge. No 
different result so
far. Postgres 12, 13 14 fail the same way.

I installed with the above strategy vanilla databases. That includes a 
pg_hba.conf with the
follwoing lines (as anybody can proof):

[...]
# TYPE  DATABASEUSERADDRESS METHOD

# "local" is for Unix domain socket connections only
local   all all trust
# IPv4 local connections:
hostall all 127.0.0.1/32trust
# IPv6 local connections:
hostall all ::1/128 trust
hostall all 0.0.0.0/32  trust
hostall all ::/128  trust


That should grant access via "localhost" and, for test purposes, access from 
any other machine
in our LAN for any user to any database.

Also, I configured postgresql13-server's postgresql.conf with following 
additions:

log_destination = 'syslog,stderr'
log_min_messages = debug5
log_min_error_statement = debug5

debug_print_parse = on
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = on
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = on
log_error_verbosity = verbose   # terse, default, or verbose messages
log_hostname = on

Trying again a login from localhost via the psql command show above, gives this 
:


[...]
2021-08-08 09:12:12.999 GMT [55664] DEBUG:  0: forked new backend, 
pid=55673 socket=12

  
2021-08-08 09:12:12.999 GMT [55664] LOCATION:  BackendStartup, postmaster.c:4232


2021-08-08 09:12:13.000 GMT [55673] LOG:  0: connection received: 
host=localhost
port=42708
   
2021-08-08 09:12:13.000 GMT [55673] LOCATION:  BackendInitialize, 
postmaster.c:4385


2021-08-08 09:12:19.994 GMT [55667] DEBUG:  0: snapshot of 0+0 running 
transaction ids
(lsn 0/15FF178 oldest xid 487 latest complete 486 next xid 487)
2021-08-08 09:12:19.994 GMT [55667] LOCATION:  LogCurrentRunningXacts, 
standby.c:1124
2021-08-08 09:13:04.988 GMT [55669] DEBUG:  0: StartTransaction(1) name: 
unnamed;
blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
2021-08-08 09:13:04.988 GMT [55669] LOCATION:  ShowTransactionStateRec, 
xact.c:5358
2021-08-08 09:13:04.988 GMT [55669] DEBUG:  0: CommitTransaction(1) name: 
unnamed;
blockState: STARTED; state: INPROGRESS, xid/subid/cid: 0/1/0
2021-08-08 09:13:04.988 GMT [55669] LOCATION:  ShowTransactionStateRec, 
xact.c:5358
2021-08-08 09:13:04.988 GMT [55670] DEBUG:  0: received inquiry for 
database 0
2021-08-08 09:13:04.988 GMT [55670] LOCATION:  pgstat_recv_inquiry, 
pg

Re: databases/postgresl13-server issue: micsompilation on IvyBridge arch?

[FreeBSD User]

On Mon, 9 Aug 2021 08:40:04 -0400
Zaphod Beeblebrox  wrote:

> IIRC, isn't the postgresql-server's default install on FreeBSD, from ports,
> have TCP turned off?  IE: try editing the config (in the database
> directory) to uncomment the listen directive?

Hello and thank you very much for responding. I do not understand what you mean
by "editing the config (in the database directory). Do you mean by that the
postgresql.conf file? Well, this file is proper set and has been, the
installation has worked well once until May the 26th. I try out to figure out
what happened to CURRENT that time.

In the meanwhile, I tried to rebuild CURRENT from scratch with
WITHOUT_OPENSSL_KTLS set, avoiding any CPU optimization during compilation of
world and postgresql - but without any effect. The pain is, that two boxes
ofthe same CPU arch affected the same way, no matter what I do. 



> 
> On Sun, Aug 8, 2021 at 5:21 AM FreeBSD User  wrote:
> 
> > Hello,
> >
> > on all(!) of my home systems based on Intel's IvyBridge CPU architecture
> >
> > a) CPU microcode: updated from 0x1f to 0x21
> >CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.09-MHz K8-class CPU)
> >
> > b) CPU microcode: updated from 0x1f to 0x21
> >CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class
> > CPU)
> >
> > I face a severe and nasty problem:
> >
> > database/postgresql12-server, database/postgresql13-server,
> > database/postgresql14-server, when
> > installed, do not allow any kind of tcp/ip connections, even on ::1 or
> > 127.0.0.1 (localhost).
> > All systems in question are dual stack and fully configured using IPv6.
> > Firewall is FreeBSD
> > standard IPFW running from /etc/rc.conf (port 5432/tcp is open and
> > listening as one can check
> > via sockstat -4 or sockstat -6).
> >
> > The hosts in question do run 14-CURRENT (with customized kernels).
> >
> > Phenomenon:
> >
> > Login locally via "psql -U postgres -d postgres" via socket works for ALL
> > DB users on all
> > configured to access databases as expected. Login via "psql -U postgres -d
> > postgres -h
> > localhost" (or any form of an IP if access tried from another remote host,
> > even locally via
> > 127.0.0.1 or ::1) does result in:
> >
> > : psql -U postgres -d postgres -h localhost
> > psql: error: server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> >
> > On the server's postgresql log I always see connection attempts like:
> >
> > [...]
> > 2021-08-08 08:56:57.601 GMT [42987] LOG:  connection received:
> > host=localhost port=12340
> >
> > but nothing more, no error message or any kind of timeout message.
> >
> > I tried to raise the log level to debug, but it is always nothing shown
> > execept the initial
> > connection attempt.
> >
> > What I tried so far:
> > I used either self compiled ports or packages taken via pkg fetch from the
> > official FreeBSD
> > pkg repos. I had LLVM suspected to miscompile something on IvyBridge. No
> > different result so
> > far. Postgres 12, 13 14 fail the same way.
> >
> > I installed with the above strategy vanilla databases. That includes a
> > pg_hba.conf with the
> > follwoing lines (as anybody can proof):
> >
> > [...]
> > # TYPE  DATABASEUSERADDRESS METHOD
> >
> > # "local" is for Unix domain socket connections only
> > local   all all trust
> > # IPv4 local connections:
> > hostall all 127.0.0.1/32trust
> > # IPv6 local connections:
> > hostall all ::1/128 trust
> > hostall all 0.0.0.0/32  trust
> > hostall all ::/128  trust
> >
> >
> > That should grant access via "localhost" and, for test purposes, access
> > from any other machine
> > in our LAN for any user to any database.
> >
> > Also, I configured postgresql13-server's postgresql.conf with following
> > additions:
> >
> > log_destination = 'syslog,stderr'
> > log_min_messages = debug5
> > log_min_error_statement = debug5
> >
> > debug_print_parse = on
> > debug_print_rewritten = on
> > debug_print_plan = on
> > debug_pretty_print = on
> > log_checkpoint

ar: warning: can't open file: ccopy.pieo: No such file or directory

[FreeBSD User]

Hallo,

latest upgrade of CURRENT sources renders buildworld into failure, box is 
running 
FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST 2021 
amd64:

[...]
===> sbin/dhclient (all)
--- all_subdir_stand ---
--- libsa32_pie.a ---
building pie sa32 library
ar -crsD libsa32_pie.a __main.pieo abort.pieo assert.pieo bcd.pieo 
environment.pieo
getopt.pieo gets.pieo globals.pieo hexdump.pieo pager.pieo panic.pieo 
printf.pieo strdup.pieo
strerror.pieo random.pieo sbrk.pieo tslog.pieo twiddle.pieo zalloc.pieo 
zalloc_malloc.pieo
strcasecmp.pieo ntoh.pieo bcmp.pieo bcopy.pieo bzero.pieo ffs.pieo fls.pieo 
memccpy.pieo
memchr.pieo memcmp.pieo memcpy.pieo memmove.pieo memset.pieo strcat.pieo 
strchr.pieo
strchrnul.pieo strcmp.pieo strcpy.pieo stpcpy.pieo stpncpy.pieo strcspn.pieo 
strlcat.pieo
strlcpy.pieo strlen.pieo strncat.pieo strncmp.pieo strncpy.pieo strnlen.pieo 
strpbrk.pieo
strrchr.pieo strsep.pieo strspn.pieo strstr.pieo strtok.pieo swab.pieo abs.pieo 
strtol.pieo
strtoll.pieo strtoul.pieo strtoull.pieo subr_boot.pieo clzsi2.pieo ctzsi2.pieo 
divmoddi4.pieo
divmodsi4.pieo divdi3.pieo divsi3.pieo moddi3.pieo modsi3.pieo udivmoddi4.pieo 
udivmodsi4.pieo
udivdi3.pieo udivsi3.pieo umoddi3.pieo umodsi3.pieo ashldi3.pieo ashrdi3.pieo 
lshrdi3.pieo
hypervisor.pieo uuid_create_nil.pieo uuid_equal.pieo uuid_from_string.pieo 
uuid_is_nil.pieo
uuid_to_string.pieo _setjmp.pieo bzlib.pieo crctable.pieo decompress.pieo 
huffman.pieo
randtable.pieo adler32.pieo crc32.pieo infback.pieo inffast.pieo inflate.pieo 
inftrees.pieo
zutil.pieo lz4.pieo closeall.pieo dev.pieo ioctl.pieo nullfs.pieo stat.pieo 
fstat.pieo
close.pieo lseek.pieo open.pieo read.pieo write.pieo readdir.pieo smbios.pieo 
arp.pieo
ether.pieo ip.pieo inet_ntoa.pieo in_cksum.pieo net.pieo udp.pieo netif.pieo 
rpc.pieo
bootp.pieo rarp.pieo bootparam.pieo ufs.pieo nfs.pieo cd9660.pieo tftp.pieo 
gzipfs.pieo
bzipfs.pieo dosfs.pieo ext2fs.pieo splitfs.pieo pkgfs.pieo time.pieo 
ffs_subr.pieo
ffs_tables.pieo explicit_bzero.pieo crc32_libkern.pieo pwgets.pieo sha256c.pieo 
sha512c.pieo
md5c.pieo rijndael-alg-fst.pieo rijndael-api-fst.pieo rijndael-api.pieo 
geliboot.pieo
geliboot_crypto.pieo gelidev.pieo geli_metadata.pieo g_eli_hmac.pieo 
g_eli_key.pieo
g_eli_key_cache.pieo pkcs5v2.pieo xform_aes_xts.pieo ccopy.pieo dec32be.pieo 
dec64be.pieo
enc32be.pieo enc64be.pieo pemdec.pieo ec_all_m31.pieo ec_c25519_m31.pieo 
ec_c25519_m62.pieo
ec_c25519_m64.pieo ec_default.pieo ec_p256_m31.pieo ec_p256_m62.pieo 
ec_p256_m64.pieo
ec_prime_i31.pieo ec_pubkey.pieo ec_secp256r1.pieo ec_secp384r1.pieo 
ec_secp521r1.pieo
ecdsa_atr.pieo ecdsa_default_vrfy_asn1.pieo ecdsa_i31_bits.pieo 
ecdsa_i31_vrfy_asn1.pieo
ecdsa_i31_vrfy_raw.pieo multihash.pieo sha1.pieo sha2big.pieo sha2small.pieo 
i31_add.pieo
i31_bitlen.pieo i31_decmod.pieo i31_decode.pieo i31_encode.pieo i31_fmont.pieo 
i31_iszero.pieo
i31_moddiv.pieo i31_modpow.pieo i31_modpow2.pieo i31_montmul.pieo 
i31_muladd.pieo
i31_ninv31.pieo i31_rshift.pieo i31_sub.pieo i31_tmont.pieo i32_div32.pieo 
i62_modpow2.pieo
rsa_default_pkcs1_vrfy.pieo rsa_i31_pkcs1_vrfy.pieo rsa_i31_pub.pieo 
rsa_i62_pkcs1_vrfy.pieo
rsa_i62_pub.pieo rsa_pkcs1_sig_unpad.pieo asn1enc.pieo x509_decoder.pieo 
x509_minimal.pieo
readfile.pieo brf.pieo vesigned.pieo vets.pieo xmem.pieo vector.pieo 
dearmor.pieo decode.pieo
opgp_key.pieo opgp_sig.pieo vectx.pieo veopen.pieo vepcr.pieo verify_file.pieo
efi_variables.pieo efi_init.pieo zfs.pieo nvlist.pieo skein.pieo 
skein_block.pieo list.pieo
zstd_shim.pieo zstd.pieo --- all_subdir_sbin --- --- all_subdir_sbin/dmesg --- 
===> sbin/dmesg
(all) --- all_subdir_stand --- ar: warning: can't open file: ccopy.pieo: No 
such file or
directory 1.72 real 3.57 user 1.07 sys


Kind regards

oh
-- 
O. Hartmann

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

[FreeBSD User]

Am Wed, 11 Aug 2021 15:03:54 -0400
Ed Maste  schrieb:

> On Wed, 11 Aug 2021 at 05:41, FreeBSD User  wrote:
> >
> > Hallo,
> >
> > latest upgrade of CURRENT sources renders buildworld into failure, box is 
> > running
> > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST 
> > 2021 amd64:  
> 
> Assuming this was with BEARSSL enabled, it should be fixed with:
> 
> commit 879675e9a0d84880cad9834e2ef98e8724c5532c
> Author: Warner Losh 
> Date:   Wed Aug 11 10:59:28 2021 -0600
> 
> stand: Add MK_PIE=no to defs.mk
> 
> There's no need to build both pie and non-pie .o's for stand. There's
> some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes
> that causes the pie build to fail that the 'ar' stage now. Since we don't
> need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader.
> 
> Reviewed by:emaste
> Sponsored by:   Netflix
> 

Yes, it has.

Thanks a lot.

oh

-- 
O. Hartmann

CURRENT: can not build 13-STABLE: missing .a lib files?

[FreeBSD User]

Running several flavours of CURRENT (all within the last three days rebuilt and
updated,  FreeBSD 14.0-CURRENT #16 main-n248811-1a4d7030bbf: Thu Aug 19
15:13:39 CEST 2021 amd64,  and today, for instance, fail either to build a
poudriere 13-STABLE jail or buildworld for 13-STABLE for FreeBSD base packages.


"poudriere jail -j 13amd64 -u -b" dies somewhere unspectatcular with

[...]
===> share/man/man4 (all)
--- all_subdir_stand ---
*** [libsa_pie.a] Error code 1

make[4]: stopped in /pool/poudriere/jails/13amd64/usr/src/stand/libsa


while the package building process dies with a 

[...]
install: libc_p.a: No such file or directory


Kind regards,

oh

FreeBSD-13-STABLE: lib/libsecureboot/verify_file.c: error: use of undeclared identifier 'SOPEN_MAX'

[FreeBSD User]

Hello,

enabling 

WITH_BEARSSL 

in src.conf renders buildworld on 13-STABLE to fail, but not on
14-CURRENT. 



This is the difference between the sources, obviously 14-CURRENT contains the 
correct
definition of SOPEN_MAX, while 13-STABLE not (undefinied SOPNE_MAX triggers the 
compiler to
fail, 
/usr/src/lib/libsecureboot/verify_file.c:59:22: error: use of undeclared 
identifier
'SOPEN_MAX'), see

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258211


[...]
13-STABLE
:/pool/sources/13-STABLE/src # grep -r SOPEN_MAX .
./lib/libsecureboot/tests/Makefile:XCFLAGS.verify_file += -DSOPEN_MAX=64
./lib/libsecureboot/verify_file.c:static int ve_status[SOPEN_MAX+1];
./lib/libsecureboot/verify_file.c:  if (fd >= 0 && fd < SOPEN_MAX) {
./lib/libsecureboot/verify_file.c:  ve_status[SOPEN_MAX] = ves;
./lib/libsecureboot/verify_file.c: *@li ve_status[SOPEN_MAX] if 
ve_status_state is none
./lib/libsecureboot/verify_file.c:  fd >= 0 && fd < SOPEN_MAX)
./lib/libsecureboot/verify_file.c:  return (ve_status[SOPEN_MAX]);  /* most 
recent */

[...]
14-CURRENT
./lib/libsecureboot/tests/Makefile:XCFLAGS.verify_file += -DSOPEN_MAX=64
./lib/libsecureboot/verify_file.c:#ifndef SOPEN_MAX
./lib/libsecureboot/verify_file.c:#define   SOPEN_MAX   64
./lib/libsecureboot/verify_file.c:static int ve_status[SOPEN_MAX+1];
./lib/libsecureboot/verify_file.c:  if (fd >= 0 && fd < SOPEN_MAX) {
./lib/libsecureboot/verify_file.c:  ve_status[SOPEN_MAX] = ves;
./lib/libsecureboot/verify_file.c: *@li ve_status[SOPEN_MAX] if 
ve_status_state is none
./lib/libsecureboot/verify_file.c:  fd >= 0 && fd < SOPEN_MAX)
./lib/libsecureboot/verify_file.c:  return (ve_status[SOPEN_MAX]);  /* most 
recent */




-- 
O. Hartmann

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

[FreeBSD User]

Am Wed, 11 Aug 2021 15:03:54 -0400
Ed Maste  schrieb:

> On Wed, 11 Aug 2021 at 05:41, FreeBSD User  wrote:
> >
> > Hallo,
> >
> > latest upgrade of CURRENT sources renders buildworld into failure, box is 
> > running
> > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST 
> > 2021 amd64:  
> 
> Assuming this was with BEARSSL enabled, it should be fixed with:
> 
> commit 879675e9a0d84880cad9834e2ef98e8724c5532c
> Author: Warner Losh 
> Date:   Wed Aug 11 10:59:28 2021 -0600
> 
> stand: Add MK_PIE=no to defs.mk
> 
> There's no need to build both pie and non-pie .o's for stand. There's
> some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes
> that causes the pie build to fail that the 'ar' stage now. Since we don't
> need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader.
> 
> Reviewed by:emaste
> Sponsored by:   Netflix
> 

Hello again,

I think I face the very same problem on 14-CURRENT boxes building either 
13-STABLE sources or
13-STABLE poudriere jails, when on the 14-CURRENT box WITH_BEARSSL is enabled 
in the
14-CURRENT host's /etc/src.conf.

I have two scenarios:

Building 13-STABLE for FreeBSD-pkg-base (having WITH_BEARSSL enabled in the 
src.conf dor the
13-STABLE source tree) and

Building poudriere jail from a dedicated source tree for 13-STABLE
(/pool/sources/13-STABLE/src) with WITH_BEARSSL enabled. 

The latter scenario sounds ridiculous to have BEARSSL enabled, but we use the 
very same
src.conf file for both the packages for FreeBSD pkg base and so for the 
poudriere jail built
from the same source tree.

For a couple of weeks now I'm unable to build both the packages nor the jails.

The question would be: is the solution you offered above and fixed the problem 
I had initailly
also applicable to 13-STABLE without breakage of something else?

Tahnk you very much in advance,

O. Hartmann

 

-- 
O. Hartmann

OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[FreeBSD User]

Hello,

after upgrading 14-CURRENT to recent sources September, the 8th 2021, we 
realizes today a
strange non-standard behaviour when connecting attempts from several clients to 
14-CURRENT
based machines were made involving sshd.

First discovered on 13-STABLE clients (NanoBSD, router/fw appliance). With 
non-public-key
authentication we copy the config partition tar'ed over to a backup system. 
This worked great
until yesterday. Today the connection is dropped immediately, /var/log/auth.log 
(sshd log on
14-CURRENT) states:

Sep  9 19:19:10 <4.6> thor sshd[1350]: Failed password for user01 from 
192.168.11.111 port
24332 ssh2

A usual ssh login attempt also fails this way:
Permission denied, please try again.

The same behaviour is to observe with Xubuntu 20.04 clients and several other 
FreeBSD
13.0-RELENG and 13-STABLE clients. Also 14-CURRENT-to-14-CURRENT connection 
attempts are
negative!

The only working scheme right now is public key authentication and that is for 
some scenarios
not applicable.

What has changed in the recent 14-CURRENT OpenSSH update that dramatically that 
working
schematics do not work any more?

By the way, on the target host's sshd, on all instances,

settings like these

[...]
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes

are set explicitely, while "UsePAM" produces an error:

/etc/ssh/sshd_config line 89: Unsupported option UsePAM

this sound ridiculous, since the usage of that tag is documented in the man 
page as well as
present in the example sshd_config and set yes by default.

What is wrong here? How can the sshd issue be fixed?

Kind regards and thanks in advance,

O. Hartmann

-- 
O. Hartmann

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[FreeBSD User]

Am Thu, 9 Sep 2021 22:12:09 +0200
Philipp Ost  schrieb:

> On 9/9/21 9:15 PM, FreeBSD User wrote:
> [...]
> > What has changed in the recent 14-CURRENT OpenSSH update that dramatically 
> > that working
> > schematics do not work any more?  
> 
> OpenSSH has been updated to v8.7p1:
> 
> https://cgit.freebsd.org/src/commit/?id=19261079b74319502c6ffa1249920079f0f69a72
> 
> One of the more prominent changes is the deprecation of SHA1.
> 
> There's some additional information here: 
> https://lists.freebsd.org/archives/freebsd-hackers/2021-September/000289.html
> 
> HTH
> Philipp
> 

I was and I'm aware of the published changes and deprecating SHA1 would imply 
non-use of
SHA1-based public keys. But public key authentication works fine, for pure ssh 
and ssh-based
rsync (scp untested). Password authentication doesn't work anymore either for 
pure ssh, scp
and rsync. I can not find any hints to dramatic changes to that and this 
authentication scheme
doesn't even work with the standard/vanilla sshd_config for the 14-CURRENT 
server side.

And beware: this problem is present only in relations, were recent 14-CURRENT 
is the ssh
server.

oh

-- 
O. Hartmann

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

[FreeBSD User]

Am Fri, 10 Sep 2021 09:04:30 -0400
Ed Maste  schrieb:

> On Fri, 10 Sept 2021 at 04:29, Gary Jennejohn  wrote:
> >
> > Was the config.h in the patch the same as the one you committed?  
> 
> No it wasn't - USE_PAM was #defined in config.h after applying the
> patch, while the committed version accidentally did not.
> 

Hello out there,

Just for clarification: after the last patches to the tree regarding openssh 
and recompilation
of the base system, it seemed that everything turned to normal afterwards - in 
my case.

Thanks.

Kind regards,

O. Hartmann

-- 
O. Hartmann

WITH_LLVM_BINUTILS: objcopy: error: invalid output format: 'efi-app-x86_64' *** [boot1.efi]

[FreeBSD User]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello list,

Trying to "crosscompile" a 13-STABLE appliance on 14-CURRENT ( FreeBSD 
14.0-CURRENT #8
main-n249550-8db1669959ce: Wed Sep 22 05:39:53 CEST 2021 amd64) with

WITH_LLVM_BINUTILS=YES

set in /etc/src.conf (and a complete fresh rebuild of the whole OS afterwards) 
results in some
serious fallout lately.

Compiling a recent, just updated this minute, 13-STABLE source, I face this 
error now and
relate this to the llvm-binutils: 

[...]
- --- boot1.efi ---
if nm boot1.sym | grep ' U '; then  echo "Undefined symbols in boot1.sym";  
exit 1;  fi
SOURCE_DATE_EPOCH=1451606400  objcopy -j .peheader -j .text -j .sdata -j .data  
-j .dynamic -j
.dynsym -j .rel.dyn  -j .rela.dyn -j .reloc -j .eh_frame  
--output-target=efi-app-x86_64
boot1.sym boot1.efi 
objcopy: error: invalid output format: 'efi-app-x86_64' *** [boot1.efi]
Error code 1

I guess this is fallout from the binutils migration and compiling 13-STABLE on 
14-CURRENT host
is a special case. Can this be fixed easily or is the migration process to 
immature at this
point?

Kind regards,

Oliver Hartmann 



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYUtsZgAKCRA4N1ZZPba5
R9JSAQDozG5xwFhGxPTbhOPCJ731/GrxdI0lfjERziGMbXbg7QEApvkWChAKg9NM
Ztgos3LH/+1Q9/gQ9CTYQbebxgcRgQM=
=8J4u
-END PGP SIGNATURE-


-- 
O. Hartmann

FreeBSD base pkg (packaging) and critical ports build alongside

[FreeBSD User]

Hello,

I use FreeBSD-base packages built on self hosted systems to update 13-STABLE
and CURRENT hosts.  I run into the problem, that the packages of the FreeBSD
base, built via the FreeBSD framework and from most recent 13-STABLE sources,
are often oit of synchronisation with our poudriere packaging builders, that is
especially true for critical ports with kernel modules, like i915 drm,
virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources
and probably the API changes more rapidly than those of the appropriate builder
hosts for poudriere and since it takes a bunch of days to build a whole
poudriere packages repository, there is often a gap between the revision of the
kernel and the port containing kernel modules.

So, the question is: how can I add ports to the building process of the FreeBSD
sources tree in the way they get build every time I build the FreeBSD-base
packages alongside the OS?

Thanks in advance,

oh

clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[FreeBSD User]

On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e:
Fri Oct  8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based
appliance failed very early in the build process of the 13-STABLE
sources as shown below. 13-STABLE is most recent, since the sources are
fetched every time the build process is triggered.

The framework for the build process is nanoBSD, the same error occurs
when building poudriere's jail based upon 13-STABLE from scratch via
the FreeBSD native build framework. 

"Cross building" of 13-STABLE on a CURRENT platform worked in most
cases and most time, hopefully this hickup is a solveable problem and
it would be nice to have this fixed. 

What is the reason for the linker fail?

Are there any recommenadtions how to "cross build" 13-STABLE on a
14-CURRENT platform in case the approach of mine s not  a desireable on?

Thanks in advance,

Oliver

[...]

sh
/pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
-s -o root -g wheel -m 555   compile_et
/pool/home/ohartmann/Projects/router/router/apu2
c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
--- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: undefined
symbol: setupterm
>>> referenced by Process.cpp
>>>   Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
>>> in archive
>>> /pool/home/ohartmann/Projects/router/router/apu2c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a

git: "overlay" of own remote-branch on official freebsd-ports repo

[FreeBSD User]

I do not know whether I'm right in this list, but since the subject is mutual 
so common
in development and GIT, I have the strong feeling I'm right here.

Im quite new to git, so apologizes for any inconvenience reading my question.

Using poudriere on 14-CURRENT to create a selection of packages also includes 
updating
the ports tree on a regular basis. I maintain some "special" ports not official 
part of
the FreeBSD ports tree and some other ports are part of those I'm supposed to 
maintain. I
keep personally track of the changes in a git repo of my own.

Now I'd like to "overlay" the official portas repo by that of mine to include 
changes.
With SVN, there was no problem to have local changes not overwritten by regular 
updates
of the ports tree as long as the specific port in question wasn't updated by 
the official
site. In git, this behaviour seems to have changed, any changes I made so far 
are gone
after poudriere is adviced to update the tree.

I'd like to ask how FreeBSD developers and maintainers do the trick. If there 
is an
official cookbook fpr maintainers (I haven't found it yet ...), please be so 
kind and
refer to it. Any advice is welcome.

Kind regards and thanks in advance,

O. Hartmann

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

[FreeBSD User]

On Tue, 12 Oct 2021 18:01:56 +
Brooks Davis  wrote:

> On Tue, Oct 12, 2021 at 05:31:48PM +0200, FreeBSD User wrote:
> > I'd like to ask how FreeBSD developers and maintainers do the trick. If
> > there is an official cookbook fpr maintainers (I haven't found it yet ...),
> > please be so kind and refer to it. Any advice is welcome.  
> 
> If you only want to add extra ports, I'd recommend maintaining a
> separate repo for use with the ports collection's under-documented
> overlay feature.  This avoids the need to rebase or merge your trees.
> 
> You create the overlay in poudriere with something like:
> 
> poudriere ports -c -p cheri-ports-overlay -U
> https://github.com/CTSRD-CHERI/cheri-ports-overlay.git -m git -B main
> 
> You then use it by adding -O cheri-ports-overlay to your other poudriere
> commands like poudriere bulk.
> 
> Note that you may need to install poudriere-devel or install it by hand
> to get this feature.
> 
> -- Brooks

Hello,

that sounds very good and usefull.

Thank you very much

Kind regards,

Oliver

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

[FreeBSD User]

On Tue, 12 Oct 2021 10:01:00 -0600
Warner Losh  wrote:

> On Tue, Oct 12, 2021 at 9:32 AM FreeBSD User  wrote:
> 
> > I do not know whether I'm right in this list, but since the subject is
> > mutual so common
> > in development and GIT, I have the strong feeling I'm right here.
> >
> > Im quite new to git, so apologizes for any inconvenience reading my
> > question.
> >
> > Using poudriere on 14-CURRENT to create a selection of packages also
> > includes updating
> > the ports tree on a regular basis. I maintain some "special" ports not
> > official part of
> > the FreeBSD ports tree and some other ports are part of those I'm supposed
> > to maintain. I
> > keep personally track of the changes in a git repo of my own.
> >
> > Now I'd like to "overlay" the official portas repo by that of mine to
> > include changes.
> > With SVN, there was no problem to have local changes not overwritten by
> > regular updates
> > of the ports tree as long as the specific port in question wasn't updated
> > by the official
> > site. In git, this behaviour seems to have changed, any changes I made so
> > far are gone
> > after poudriere is adviced to update the tree.
> >
> > I'd like to ask how FreeBSD developers and maintainers do the trick. If
> > there is an
> > official cookbook fpr maintainers (I haven't found it yet ...), please be
> > so kind and
> > refer to it. Any advice is welcome.
> >  
> 
> tl;dr: branches are cheap and well supported in git. You just make a branch
> for your
> local changes, and update that however you see fit.
> 
> For ports I have like that, I've just created a branch in git. I rebase the
> branch forward
> each time I update. For me, though, the branch is mostly uncommitted in
> upstream
> changes that may not be ready for some reason... There's two ways to do
> this.
> You can just merge, which is OK if you aren't upstreaming the changes, or
> you can
> rebase if the changes or a subset of the changes likely will end up in
> FreeBSD.
> 
> Others might recommend stash, but I find it too unwieldy for more than a
> couple
> of things.
> 
> So the workflow would be:
> 
> git clone -o freebsd  freebsd-ports
> cd freebsd-ports
> git checkout -b hartmann-specials
> 
> 
> Now, you can use poudriere-ports with the -B hartmann-specials and your
> local repo as the source of truth.
> 
> to update
> 
> cd freebsd-ports
> git checkout main
> git pull --rebase  # or --ff-only, I use
> --rebase because I push and it's habit
> git rebase -i main hartmann-specials
> 
> Note: if you need to have multiple trees with this branch you are modifying,
> then a git pull --rebase will let you cope with the forced-pushes this
> method
> would require. You can also do it with git merge on hartmann-specials if you
> don't need to keep the changes separate or you have a lot of downstreams
> that would get cranky, which doesn't sound like the case here.
> 
> Warner

As I wrote, I'm quite new to git and always surprised. Thanks for the help and
the neat tip. I'll try.

Kind regards and thanks,

Oliver

13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call

[FreeBSD User]

After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu 
Oct 14
20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also 
updating port
graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, graphics/libdrm 
to
libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following 
message:

[~] firefox
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with
reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system
callgraphics/libdrm.

info on packages installed:
[~] pkg info -x drm
drm-fbsd13-kmod-5.4.144.g20211013
drm-kmod-g20190710_1
libdrm-2.4.107_1,1
linux-c7-libdrm-2.4.97

It doesn't matter whether to update the ports (including firefox) from a 
regular FreeBSD
ports repo or, in my case, compiling special kernel related kmod port like
drm-fbsd13-kmod manually on each kernel build. The ports package of
graphics/drm-fbsd13-kmod seems to be behind the version
of drm-fbsd13-kmod-5.4.144.g20211013 when updating from regular package host, 
but it
doesn't matter, the result then is the same: Bad system call on Firefox.

So FreeBSD 13-STABLE seems to be the culprit. What happened? I saw the Linux 
KPI changed
again, so might this trigger this? 

Kind regards,

O. Hartmann

Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call

[FreeBSD User]

On Fri, 15 Oct 2021 23:25:01 +0300
Konstantin Belousov  wrote:

> On Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote:
> > FreeBSD User  writes:
> >   
> > > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: 
> > > Thu Oct 14
> > > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and 
> > > also
> > > updating port graphics/drm-fbsd13-kmod to 
> > > drm-fbsd13-kmod-5.4.144.g20211013,
> > > graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes 
> > > now with
> > > the following message:  
> > 
> > Which revision "13-STABLE" was before the update? If you didn't change
> > any kernel options (and bump into a pilot error) bisecting may help.
> >   
> > >
> > > [~] firefox
> > > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close 
> > > with
> > > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad 
> > > system
> > > callgraphics/libdrm.  
> > 
> > Run under truss(1) or ktrace(1) (enable tracing descendants) to get the
> > syscall name or number. For example, Firefox requires CAPABILITIES for
> > cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust.
> > 
> > [1] https://github.com/rust-lang/libc/pull/2406  
> 
> If you set kern.lognosys=3, it should be quite loud advertized which syscall
> was missed, ie. console + control terminal.
> terminal) 
> 

Hello,

thanks for the fast response.
I changed indeed one single kernel parameter: commenting out the 
COMPAT_FREEBSD11. I
think Jan Beich pointed towards the right thing.

Thanks for the help and soryy for the noise.

Kind regards,

O. Hartmann

CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)

[FreeBSD User]

Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov 22 
18:17:54
CET 2021 amd64) troubles me with our DNS server/service.
Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 version 
and also,
after the compilation of a fresh OS with LLVM13, the upgrade from bind-9.16.22 
to
bind-9.16.23 took place as well as ASLR being the default.

Since then named is crashing with a mysterious segmentation fault (see PR 
259921,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921).

Disabling ASLR as recommended to check whether ASLR triggers the SegFault did 
not solve
the problem, so I suspect a miscompilation due to llvm13.

On 13-STABLE bind-9.16.23 seem not to have this behaviour.

I'm floating like a dead man in the water, can someone help?

Kind regards,

oh

CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress

[FreeBSD User]

Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT
#7 main-n251463-935dc0de881: Wed Dec  8 06:49:25 CET 2021 amd64) fails with the
linker error shown below.

Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build.


[...]
cc -O2 -pipe -O3 -fno-common
-I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc
-I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG
-std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-variable -Qunused-arguments
-I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include
 -static
-L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib
-o nm nm.o
-L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf
-ldwarf
-L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf
-lelf
-L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc
-lelftc_pie
-L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf
-lelf  -legacy ld: error: undefined symbol: uncompress
>>> referenced by libdwarf_elf_init.c
>>>   libdwarf_elf_init.o:(_dwarf_elf_init) in archive
>>> /usr/lib/libdwarf.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [nm] Error code 1

Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress

[FreeBSD User]

Am Wed, 8 Dec 2021 10:43:41 -0500
schrieb Mark Johnston :

> On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote:
> > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD
> > 14.0-CURRENT #7 main-n251463-935dc0de881: Wed Dec  8 06:49:25 CET
> > 2021 amd64) fails with the linker error shown below.
> > 
> > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be
> > build.
> > 
> > 
> > [...]
> > cc -O2 -pipe -O3 -fno-common
> > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc
> > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common
> > -DNDEBUG -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall
> > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> > -Wchar-subscripts -Wnested-externs -Wredundant-decls
> > -Wold-style-definition -Wno-pointer-sign
> > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> > -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-error=unused-but-set-variable -Qunused-arguments
> > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include
> > -static
> > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib
> > -o nm nm.o
> > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf
> > -ldwarf
> > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf
> > -lelf
> > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc
> > -lelftc_pie
> > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf
> > -lelf  -legacy ld: error: undefined symbol: uncompress  
> > >>> referenced by libdwarf_elf_init.c
> > >>>   libdwarf_elf_init.o:(_dwarf_elf_init) in archive
> > >>> /usr/lib/libdwarf.a  
> > cc: error: linker command failed with exit code 1 (use -v to see
> > invocation) *** [nm] Error code 1  
> 
> Is this build using WITHOUT_CLEAN?  If so I think you'll need to try a
> clean build if you had previous built world between dbf05458e3bd and
> 8d5d329553b3.
> 

Hello.

Thanks for responding. The issue occured in poudriere and indeed, I set
WITHOUT_CLEAN.
After deleting the obj folder poudriere and the 14-CURRENT environment
compiled the 13-STABLE source as expected.

Thanks.
oh

CURRENT: ZFS freezes system beyond reboot

[FreeBSD User]

Running CURRENT (FreeBSD 14.0-CURRENT #52 main-n251260-156fbc64857: Thu
Dec  2 14:45:55 CET 2021 amd64), out of the sudden the ZFS RAIDZ pool
suffered from an error: 

Solaris: WARNING: Pool 'POOL00' has encountered an uncorrectable I/O
failure and has been suspended.

The system does not repsond anymore on that pool, transactions to and
from that pool are frozen, the system is 99.9% idle.
The most "not so funny" part is: the box doesn't even recognize a
"shutdown -r now" or a brute force "reboot". I still can login via ssh,
but any action regarding the ZFS pool freezes the console/terminal.

ZFS very often renders the system unresponsible forever. How can this
be mitigated? The system in question is on a remote site and it seems
not only to be bound to CURRENT, we realised similar problems on
13-STABLE as well. 

What can I do to "unfreeze" the ZFS? The main OS is, luckily, on an
UFS/FFS filesystem and so not affected from that problem.

By the way, here some more details, as far as I can pick those up:

zpool clear POOL00 cannot clear errors for POOL00: I/O error

Whatever took out the ZFS pool (can not see any hardware errors, the
pool is part of services and especially a poudriere build system and
under heavy load all the time, the box has 16 GB RAM), it also renders
the rest of the system unusable in a way which is beyond a "reboot".

Kind regrads,
oh

Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)

[FreeBSD User]

On Fri, 10 Dec 2021 19:41:07 +1030
Daniel O'Connor via freebsd-current  wrote:

> > On 25 Nov 2021, at 18:50, FreeBSD User  wrote:
> > 
> > Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov 
> > 22
> > 18:17:54 CET 2021 amd64) troubles me with our DNS server/service.
> > Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 
> > version and
> > also, after the compilation of a fresh OS with LLVM13, the upgrade from 
> > bind-9.16.22
> > to bind-9.16.23 took place as well as ASLR being the default.
> > 
> > Since then named is crashing with a mysterious segmentation fault (see PR 
> > 259921,
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921).
> > 
> > Disabling ASLR as recommended to check whether ASLR triggers the SegFault 
> > did not
> > solve the problem, so I suspect a miscompilation due to llvm13.
> > 
> > On 13-STABLE bind-9.16.23 seem not to have this behaviour.
> > 
> > I'm floating like a dead man in the water, can someone help?  
> 
> lang/sdcc also seg faults 
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303),
> although there disabling ASLR via proccontrol does fix it.
> 
> Can you show a stacktrace for your seg fault?

Hello.
I have to prepare the boxes for debugging first, we switched everything off 
including
core dumping.

In the meanwhile, bind-9.16.24_1 has been issued in ports - the same problem 
occurs with
that version, too, when compiled with llvm13.


Kind regards,

O. Hartmann
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>  -- Andrew Tanenbaum
> 
> 

Re: CURRENT: ZFS freezes system beyond reboot

[FreeBSD User]

On Mon, 13 Dec 2021 09:30:50 +0200
Andriy Gapon  wrote:

> On 12/12/2021 18:45, Alan Somers wrote:
> > You need to look at what's causing those errors.  What kind of disks
> > are you using, with what HBA?  It's not surprising that any access to
> > ZFS hangs; that's what it's designed to do when a pool is suspended.  
> 
> However, a pool does not have to be suspended on errors.
> failmode property provides a couple of alternatives:
>   wait  Blocks all I/O access until the device connectivity is
> recovered and the errors are cleared.  This is the
> default behavior.
> 
>   continue  Returns EIO to any new write I/O requests but allows
> reads to any of the remaining healthy devices.  Any
> write requests that have yet to be committed to disk
> would be blocked.
> 
>   panic Prints out a message to the console and generates a
> system crash dump.
> 
> But neither does any magic.
> The errors will still be there.
> 

Hello.

The error's cause was not obvous. I used a SSD, partioned into two halfes, one 
for ZIL,
the other for L2ARC. When showing "zpool status", the RAIDZ's HDDs 
(Hitachi/Seagate 4 TB
NAS HDD) where "online", ZIL was "online" and L2ARC device/vdev showd - nothing.

I had to power off/power on the box. For several hours nothing moved on, the 
box was
frozen, any invocation of any ZFS volume related tool/command hanged the 
terminal/console.

Several datasets showed errors at <0x0>, nothing serious.

After deleting the ZIL and L2ARC extra SSD from the RAIDZ pool, verything went 
to normal
again.

It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole 
box even if
the essential operating system stuff is isolated on a dedicated UFS filesystem.

Kind regards,

O. Hartmann

Arduino IDF -> make/automake based environment

[FreeBSD User]

Hello out there,

I'm using the port devel/arduino18 as the basis for some small projects. I'd 
like to get
rid of that clumsy JAVA based IDF and move towards a more make/automake based
environment. Since I'm interested in coding for some smaller AMTEL MCUs and 
ESP32 and
like to digg a bit deeper than simply clicking a host base from a menu, I'm not 
afraid of
doing some larger basic setup if needed. But I have so far almost no experience 
in cross
compiling on FreeBSD and I'd like to ask whether someone out here has already 
done
setting up an environment based on the basic tools FreeBSD provides to develop 
in an
crosscompiling sense.
My IDE of choice would be Anjuta, but this is only a notice besides.

As fas as I know, the base OS for most MCUs, including my choices ESP32, 
ESP8266, is a
derivative of Amazone's FreeRTOS. Can the OS being compiled (cross compiled) on 
FreeBSD
assuming the correct compiler is at hand (which is the case, I presume since 
the Arduino
IDF is already working on FreeBSD)?

Thanks in advance,

Oliver

Re: Arduino IDF -> make/automake based environment

[FreeBSD User]

Am Mon, 20 Dec 2021 14:35:10 +0100
schrieb Marc Fonvieille :

> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
> > 
> >   
> > > On 19. Dec 2021, at 12:18, FreeBSD User 
> > > wrote:
> > > 
> > > environment. Since I'm interested in coding for some smaller
> > > AMTEL MCUs and ESP32 and like to digg a bit deeper than simply
> > > clicking a host base from a menu, I'm not afraid of doing some
> > > larger basic setup if needed.  
> > 
> > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are
> > in ports. 
> 
> For ESP32, you should look at:
> https://wiki.freebsd.org/electronics/arduino/esp32
> and
> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
> 

Great!

Thanks a lot.

Oliver

Re: Arduino IDF -> make/automake based environment

[FreeBSD User]

On Mon, 20 Dec 2021 14:35:10 +0100
Marc Fonvieille  wrote:

> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
> > 
> >   
> > > On 19. Dec 2021, at 12:18, FreeBSD User  wrote:
> > > 
> > > environment. Since I'm interested in coding for some smaller AMTEL MCUs 
> > > and ESP32
> > > and like to digg a bit deeper than simply clicking a host base from a 
> > > menu, I'm not
> > > afraid of doing some larger basic setup if needed.  
> > 
> > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in ports.
> >  
> 
> For ESP32, you should look at:
> https://wiki.freebsd.org/electronics/arduino/esp32

Following these instructions with the most recent required ports on the latest 
13-STABLE,
results in an linker error:

/usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
cannot find crt1-sim.o: No such file or directory
/usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
cannot find _vectors.o: No such file or directory
collect2: error: ld returned 1 exit status


> and
> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
> 

Re: Arduino IDF -> make/automake based environment

[FreeBSD User]

On Wed, 29 Dec 2021 09:10:02 +0200
Daniel Braniss  wrote:

> > On 29 Dec 2021, at 01:25, FreeBSD User  wrote:
> > 
> > On Mon, 20 Dec 2021 14:35:10 +0100
> > Marc Fonvieille mailto:black...@freebsd.org>> wrote:
> >   
> >> Le 19.12.2021 21:03, Andrew Stevenson a écrit :  
> >>> 
> >>>   
> >>>> On 19. Dec 2021, at 12:18, FreeBSD User  wrote:
> >>>> 
> >>>> environment. Since I'm interested in coding for some smaller AMTEL MCUs 
> >>>> and ESP32
> >>>> and like to digg a bit deeper than simply clicking a host base from a 
> >>>> menu, I'm not
> >>>> afraid of doing some larger basic setup if needed.
> >>> 
> >>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in 
> >>> ports.
> >>>   
> >> 
> >> For ESP32, you should look at:
> >> https://wiki.freebsd.org/electronics/arduino/esp32  
> > 
> > Following these instructions with the most recent required ports on the 
> > latest
> > 13-STABLE, results in an linker error:
> > 
> > /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
> > cannot find crt1-sim.o: No such file or directory
> > /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
> > cannot find _vectors.o: No such file or directory
> > collect2: error: ld returned 1 exit status
> > 
> >   
> >> and
> >> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
> >> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/>
> >>  
> i gave up compiling the xtensa stuff, specially after espressif came out with 
> a riscv
> version. so I downloaded the oficial idf and under FreeBSD-13 it almost 
> worked  out of
> the box, if you want I can search my notes …
> 
> danny
> 

Hello.

I think, that will be the first step in the right direction (using the official 
eps-idf).
Since I didn't come along with the salvation of the linker error reported 
earlier, I
switched back to an older project from January this year. It is also based on 
the
official FreeBSD Arduino 1.8.5 port and the xtensa compiler 5.2.0 from ports, 
but I used
within sketchbook/hardware/esp32 the esp32 git branch release/v1.0 instead of 
master on
which I faced the crt1-sim.o error. The goal is to compile HyperionLED (as a 
side
product) with the recommended libraries for this project.
It doesn't compile with ESP32 branch release/v1.0, the error is now

[...]
libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:149:33: error:
'cpu_hal_get_cycle_count' was not declared ...
[...]

which lead me to the conclusion that a more recent version is required. With 
the recent
version of ESP32 stuff in place, I face the mentioned crt1-sim.o error.

Searching the web for that error leads to a discrepancy of ESP-IDF and the 
compiler stuff.

I'll try the original esp-idf as you suggested (it is a pity it is backed by 
cmake, I'm
not quite familiar with cmake yet).

Any advice is highly appreciated.

Kind regards,
oh

13/STABLE: usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated'

[FreeBSD User]

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 
-fno-strict-aliasing
-march=native  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-common-fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -MD
-MF.depend.hack.pico -MThack.pico 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone 
-mno-mmx
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option
-Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body
-Wno-error=parentheses-equality -Wno-error=unused-function 
-Wno-error=pointer-sign
-Wno-error=shift-negative-value -Wno-address-of-packed-member
-Wno-error=unused-but-set-variable -Wno-format-zero-length   -mno-aes -mno-avx
-std=iso9899:1999 -nostdlib hack.c -o hack.pico rm -f hack.c --- modules-all 
--- ---
all_subdir_aac --- ===> aac (all) --- all_subdir_aacraid --- ===> aacraid (all) 
---
all_subdir_accf_data --- ===> accf_data (all) --- tsc.o ---
/usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated' 
goto
calibrated;


Kind regards and thanks in advance,

oh

bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[FreeBSD User]

Hello folks,

we run at least two poudriere build systems on recent CURRENT boxes and one of 
these
poudriere build systems is working within a jail - setup via FreeBSD's 
/etc/jail.conf and
by misusing the port ezjail for copying/deploying our self-compiled jail 
binary. The
poudriere jail uses ZFS and is, to make it short, working like a charme.

Now we try to setup another poudriere, but this time the base is XigmaNAS 
12.3.0.4/9009,
which is based upon 12.X-RELENG, utilizing "bastille". Bastille is up to date 
(in terms
od the XigmaNAS plugin).

Following the setup we used 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" on all of 
our systems
for jails and so does XigmaNAS.

Starting a building process via poudriere ends up with


# poudriere bulk -p head -z default -j 123-amd64 -f
/usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating the 
reference
jail... done [00:00:01] Mounting system devices for 123-amd64-head-default
[00:00:01] Warning: Using packages from previously failed, or uncommitted, 
build:
/mnt/poudriere/data/packages/123-amd64-head-default/.building [00:00:01] 
Mounting ports
from: /mnt/poudriere/ports/head [00:00:01] Mounting packages from:
/mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] Mounting 
distfiles from:
/mnt/poudriere/ports/distfiles [00:00:01] Copying /var/db/ports from:
/usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02] Appending 
to
make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf ->
/mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf [00:00:02] 
Starting
jail 123-amd64-head-default jail: jail_set: Operation not permitted
[00:00:02] Cleaning up
[00:00:02] Unmounting file systems

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:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 14:11:32
/mnt/poudriere/jails/130-amd64

The jail.conf for this specific jail is as follows:

[...]
pulverfass-001 {
devfs_ruleset = 13;
enforce_statfs = 1;
exec.clean;
exec.consolelog = /mnt/extensions/bastille/logs/pulverfass-001_console.log;
exec.start = '/bin/sh /etc/rc';
exec.stop = '/bin/sh /etc/rc.shutdown';
host.hostname = X;
mount.devfs;
mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
path = /mnt/extensions/bastille/jails/pulverfass-001/root;
securelevel = 0;

vnet;
vnet.interface = e0b_bastille4;
exec.prestart += "jib addm bastille4 igb0";
exec.prestart += "ifconfig e0a_bastille4 description \"vnet host interface for 
Bastille
jail pulverfass-001\""; exec.poststop += "jib destroy bastille4";

allow.mount;
allow.mount.fdescfs;
allow.mount.devfs;
allow.mount.tmpfs;
allow.mount.nullfs;
allow.mount.procfs;
allow.mount.linsysfs;
allow.mount.linprocfs;
allow.mount.zfs;

allow.chflags;
allow.raw_sockets;
allow.socket_af;
allow.sysvipc;

linux = new;

exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
exec.start += "/sbin/zfs mount -a";
exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";

}
[...]

Tracking the execution of the build process by issuing

poudriere -x bulk ...

and examin the resulting trace doesn' tgive me any hint, the error reported 
above
immediately occurs when the jail is about to be started:

+ set -u +x
+ jail -c persist 'name=123-amd64-head-default' 'path=/mnt/poudriere/data/.m/ \
  123-amd64-head-default/ref' 'host.hostname=basehost.local.domain' \
  'ip4.addr=127.0.0.1' 'ip6.addr=::1' allow.chflags allow.sysvipc
jail: jail_set: Operation not permitted
+ exit_handler
[...]

Searching the net revealed some issues with setting IP4 and IP6 in poudriere, 
but those
findings are dated back to 2017 and 2014 and I guess this is solved right now.

The difference between our manually jail.conf driven setup and the 
XigmaNAS/bastille
based one is, bastille uses jib/netgraph based seutups of the vnet and the 
ip4/ip6 is
setup from rc.conf, while we use epair in the other world and the ip is setup 
from
withing the jail definition in jail.conf.

I'm out of ideas here and after two days of trial and error and trying to 
understand
what's going on lost ... Any hints or tipps?

Thanks in advance,

O. Hartmann

Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[FreeBSD User]

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:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> > 14:11:32 /mnt/poudriere/jails/130-amd64
> > 
> > The jail.conf for this specific jail is as follows:
> > 
> > [...]
> > pulverfass-001 {
> > devfs_ruleset = 13;
> > enforce_statfs = 1;
> > exec.clean;
> > exec.consolelog =
> > /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start
> > = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown';
> > host.hostname = X;
> > mount.devfs;
> > mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> > path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> > securelevel = 0;
> > 
> > vnet;
> > vnet.interface = e0b_bastille4;
> > exec.prestart += "jib addm bastille4 igb0";
> > exec.prestart += "ifconfig e0a_bastille4 description \"vnet host
> > interface for Bastille jail pulverfass-001\""; exec.poststop += "jib
> > destroy bastille4";
> > 
> > allow.mount;
> > allow.mount.fdescfs;
> > allow.mount.devfs;
> > allow.mount.tmpfs;
> > allow.mount.nullfs;
> > allow.mount.procfs;
> > allow.mount.linsysfs;
> > allow.mount.linprocfs;
> > allow.mount.zfs;
> > 
> > allow.chflags;
> > allow.raw_sockets;
> > allow.socket_af;
> > allow.sysvipc;
> > 
> > linux = new;
> > 
> > exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> > exec.start += "/sbin/zfs mount -a";
> > exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
> > 
> > }
> > [...]
> > 
> > Tracking the execution of the build process by issuing
> > 
> > poudriere -x bulk ...
> > 
> > and examin the resulting trace doesn' tgive me any hint, the error
> > reported above immediately occurs when the jail is about to be
> > started:
> > 
> > + set -u +x
> > + jail -c persist 'name=123-amd64-head-default'
> > 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref'
> > 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1'
> > 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation
> > not permitted
> > + exit_handler
> > [...]
> > 
> > Searching the net revealed some issues with setting IP4 and IP6 in
> > poudriere, but those findings are dated back to 2017 and 2014 and I
> > guess this is solved right now.
> > 
> > The difference between our manually jail.conf driven setup and the
> > XigmaNAS/bastille based one is, bastille uses jib/netgraph based
> > seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we
> > use epair in the other world and the ip is setup from withing the
> > jail definition in jail.conf.
> > 
> > I'm out of ideas here and after two days of trial and error and
> > trying to understand what's going on lost ... Any hints or tipps?
> > 
> > Thanks in advance,
> > 
> > O. Hartmann  
> 
> Hi Oliver,
> 
> I don't see `children.max` set in any of the configuration you shared
> above.
> 
> Cheers
> Michael
> 

Hello Michael,

bummer! I was so selfconfident because I copied the initial config from a 
working test
and had this attribute already set that I never checked again its existence - 
and started
reorganizing the jail.conf attributes ... 
A fine observation and a full hit: after setting children.max= 128; the 
poudriere jail
started working ... didn't wait for the finish so far.

I'm sorry for the noise - thanks for you eyes ...

Kind regards,

Oliver

CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

[FreeBSD User]

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 possible anymore, the build process dies with the error shown
below:

[...]
>>> Install check world
--
mkdir -p /tmp/install.l1zhrZWFwP
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp  date echo
egrep find grep id install   ln make mkdir mtree mv pwd_mkdb  rm sed
services_mkdb sh sort strip sysctl test true uname wc  zic tzsetup  makewhatis;
do  if progpath=`env
PATH=/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/usr/sbin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/usr/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/sbin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
which $prog`; then  echo $progpath;  else  echo "Required tool $prog not found
in PATH ($PATH)." >&2;  exit 1;  fi;  done);  if [ -z "" ] ; then  libs=$(ldd
-f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u |  while read line; do
set -- $line;  if [ "$2 $3" != "not found" ]; then  echo $2;  else  echo
"Required library $1 not found." >&2;  exit 1;  fi;  done);  fi;  cp $libs
$progs /tmp/install.l1zhrZWFwP cp: [vdso]: No such file or directory *** Error
code 1

Stop.
make[5]: stopped in /pool/sources/13-STABLE/src
*** Error code 1

Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

[FreeBSD User]

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-current" 
> Gesendet: Freitag, 1. April 2022 15:50:31
> Betreff: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file 
> or directory
> *** Error
> 
> On Fri, 1 Apr 2022 at 08:54, FreeBSD User  wrote:
> >
> > 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 possible anymore  
> 
> Could you give this patch a try?
> 
> diff --git a/Makefile.inc1 b/Makefile.inc1
> index c91034ed42fe..bd58f48a64d2 100644
> --- a/Makefile.inc1
> +++ b/Makefile.inc1
> @@ -1366,6 +1366,9 @@ distributeworld installworld stageworld:
> _installcheck_world .PHONY
> libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs
> 2>/dev/null | sort -u | \  
> while read line; do \
> set -- $$line; \
> +   if [ "$$1" = "[preloaded]"; then \
> +   break; \
> +   fi \
> if [ "$$2 $$3" != "not found" ]; then \
> echo $$2; \
> else \
> 

Hello,

it is also impossible to installworld - same error. I'm on FreeBSD 14.0-CURRENT 
#134
main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 amd64, sources are up to 
date as of
now. 

It isn't only an issue with crossbuilding another FreeBSD branch.

Kind regards,

O. Hartmann


-- 
O. Hartmann

Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

[FreeBSD User]

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
> https://reviews.freebsd.org/D34734.
> 

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, see bewlo. What I'm 
doing weong here?

Kind reagrds,

O. Hartmann


[...]
>>> Install check world
--
--- installworld ---
mkdir -p /tmp/install.7P7AV5IW4F
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp  date echo 
egrep find grep
id install   ln make mkdir mtree mv pwd_mkdb  rm sed services_mkdb sh sort 
strip sysctl test
time true uname wc  zic tzsetup  makewhatis; do  if progpath=`env
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
which $prog`; then  echo $progpath;  else  echo "Required tool $prog not found 
in PATH
($PATH)." >&2;  exit 1;  fi;  done);  if [ -z "" ] ; then  libs=$(ldd -f "%o 
%p\n" -f "%o
%p\n" $progs 2>/dev/null | sort -u |  while read line; do  $line;  if [ "$1" = 
"[preloaded]"
|| "$1" = "[vdso]" ]; then  continue;  fi;   if [ "$2 $3" != "not found" ]; 
then  echo $2;
else  echo "Required library $1 not found." >&2;  exit 1;  fi;  done);  fi;  cp 
$libs $progs
/tmp/install.7P7AV5IW4F [: missing ] sh: [preloaded]: not found [: missing ] 
sh: [vdso]: not
found [: missing ] sh: libc.so.7: not found [: missing ] sh: 
libcap_fileargs.so.1: not found
[: missing ] sh: libcasper.so.1: not found [: missing ]
sh: libedit.so.8: not found
[: missing ]
sh: libformw.so.6: not found
[: missing ]
sh: libm.so.5: not found
[: missing ]
sh: libmd.so.6: not found
[: missing ]
sh: libncursesw.so.9: not found
[: missing ]
sh: libnv.so.0: not found
[: missing ]
sh: libprivatebsddialog.so.0: not found
[: missing ]
sh: libregex.so.1: not found
[: missing ]
sh: libthr.so.3: not found
[: missing ]
sh: libtinfow.so.9: not found
[: missing ]
sh: libutil.so.9: not found
[: missing ]
sh: libxo.so.0: not found
cp: [vdso]: No such file or directory
*** [installworld] Error code 1

make[1]: stopped in /usr/src


-- 
O. Hartmann

PAM: SSH: reject login when homdir does not exist?

[FreeBSD User]

Hello fellows, happy Easter!

I run into a security issue this morning here and tried to look for a solution. 
We use
OpenLDAP for all "regular users" login on hosts and web services. 
Authentication is
required from some cloud/moodle services via LDAP, but some users not having any
homedirectory on any machine within the domain will still be allowed to login, 
even if
the home dir is not present. They get loged in onto the root of the filesystem, 
when
login via SSH.

Is there a way to prohibit login if homedir isn't present? Can you point me to 
the right
place (PAM or something, 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

13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine

[FreeBSD User]

I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and 13.1-RELENG
on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been
made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13.

As with today, building from sources either 13.1-RELENG and 13.0-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:

[...]
--
>>> Install check world
--
mkdir -p /tmp/install.6R4Ifq8o
...
cp: [vdso]: No such file or directory
*** Error code 1
[...]

and on building from sources 13.1-RELENG while in installworld we get:

[...]
===> usr.bin/lex/lib (install)
install -l h -o root -g wheel -m 444
/home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib
ln_p.a
/home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a
install: link
/home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a
 -> /home/ohartman
n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a:
No such file or directory
*** Error code 71


Thanks in advance,

O. Hartmann

Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

[FreeBSD User]

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,
> > see bewlo. What I'm doing weong here?  
> 
> You're not doing anything wrong, I had another bug in the version of
> the patch you tried. I've updated Phabricator again, please try again.
> 

Hello,

sorry for the very late response.
After the commit, everything on CURRENT was all right and worked as expected.
Many thanks for the fast response!

Kind regards,

O. Hartmann

Re: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine

[FreeBSD User]

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 the reported [vdso] error (see below).

> The vdso error is fixed by cherry-picking
> b3b462229f972e2ed24d450d7d2f8855cdd58a87.

Still does not build.

> I'm not sure about the second error, though if it's a general profile
> error, you make need WITHOUT_PROFILE=t in both the build and install phases.

This is now working on the above reported builder host version. The key was,
indeed, setting WITHOUT_PROFILE=t. Thank you for the hint.

On CURRENT I can build both, 13.0-RELENG and 13.1-RELENG without issues.

Kind regards,

Oliver Hartmann

> 
> 
> On Tue, Apr 19, 2022 at 5:46 AM FreeBSD User  wrote:
> 
> > I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and
> > 13.1-RELENG
> > on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been
> > made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13.
> >
> > As with today, building from sources either 13.1-RELENG and 13.0-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:
> >
> > [...]
> > --  
> > >>> Install check world  
> > --
> > mkdir -p /tmp/install.6R4Ifq8o
> > ...
> > cp: [vdso]: No such file or directory
> > *** Error code 1
> > [...]
> >
> > and on building from sources 13.1-RELENG while in installworld we get:
> >
> > [...]  
> > ===> usr.bin/lex/lib (install)  
> > install -l h -o root -g wheel -m 444
> >
> > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib
> > ln_p.a
> >
> > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a
> > install: link
> > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a
> > -> /home/ohartman  
> >
> > n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a:
> > No such file or directory
> > *** Error code 71
> >
> >
> > Thanks in advance,
> >
> > O. Hartmann
> >
> >  

ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery

[FreeBSD User]

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 da4p3 denied due to unsupported optional features:
needs_recovery

How can this problem be solved?

Thanks in advance,

oh

Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery

[FreeBSD User]

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 
> > > 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 da4p3 denied due to unsupported optional features:
> > > needs_recovery
> > >
> > > How can this problem be solved?
> > >
> > > Thanks in advance,
> > >
> > > oh
> > >  
> > Probably as the name of the mailing list suggest you should upgrade to
> > 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it.
> >
> > --
> > Marek Zarychta
> >  
> 
> You might also try sysutils/fusefs-ext2 from ports.
> 

Hi all,

thanks for the response. 

First of all, I'm bound to FreeBSD 12.3, which is the base for XigmaNAS (used 
for the
ease of use for those colleagues without FreeBSD experience). No clue, when 
this project
will jump over to 13.0 or 13.1.

Last time I installed ports on Xigmanas itself and tried to remove those ports, 
some of
the base system essential also got removed - so the system was wrecked. 
Therefore, I'm
planning to try jails and grant access to the jail and try to bind/mount the 
HDDs in
question into the jail for backup - if this task is not an impossible mission 
on FBSD.

Last, but the most problematic issue is: I do not know what the HDDs filesystem 
in
reality really is! There is an EFI partition (FAT32), there is a second one, 
fstyp report
unknown and here is the large partition identified as ext2fs by fstyp. But I 
think he
former administration in the department used LVM on the more recent Linux 
boxes, so I
might have to deal with that also.

Kind regards,

O. Hartmann
Another issue on several of those HDDs in question seems to be 

vnet/if_bridge: ARP issues: connection failure

[FreeBSD User]

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 point of view). The box has two NICs, em0 which is 
dedicated
for managing the host and igb0 for services like NFS, SMB and jails (the host 
is de facto
a Xigmanas box). The NIC igb0 also has an IPv4 which is accessible without 
problem (sshd
is listening on em0 and igb0 and any service bound to igb0 and its IP itself 
works like a
charme, execept anything that is connected via if_bridge/vnet). Both, em0 and 
igb0, are
member of the same network and connected to the same switch (I guess, it's the 
campus
infrastructure, I have no access to that).

Phenomenon: trying to ping a jail results initially in a long term waiting and 
often in
"Host is down" - but then, sudenly, the jail is responding. Trying to connect to
port 22/tcp of any jail doesn't work in 90% of the cases, but randomly, a host 
(out of
five) does respond and the connection can be established. Terminating the 
connection and
tryin again is in 99% then a fail. Once connected the ssh connection fries 
after a couple
of seconds of inactivity.

Checking ARP on the jail (login via host and jexec) and listening via
tcpdump -XXvi vnet0 arp
on a jail while pinging the jail from the netowrk shows up the typical 
requests, but not
every request is then acompanied by a reply. I'm not firm in terms of 
networking and
investigating ARP issues, so I followed some instructions found with ARP issues 
on FBSD,
vnet and routing.

MIB settings (on the host itself, vnet untouched):
net.inet.ip.forwarding: 0
net.link.bridge.ipfw: 0
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

I also realised that on the igb0 interace checksum errors occured while rxcsum 
is
enabled. I disbaled special features via "ifconfig igb0  -rxcsum -txcsum -tso 
-lro

I'm out of ideas here.

Another box, the same base OS, similar setup (two NICs, same ambition), but 
with the
difference that the second NIC resides on a different network and is connected 
to a
different switch, also if_bridge and vnet attached jails, there is no problem.

Either there is a serious bug in 12.3-p5 (haven't had the chance to check on 
13/CURRENT)
or I'm doing something terribly wrong.

Some technical details:




em0@pci0:0:25:0:class=0x02 card=0x29828016 chip=0x153b8086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection I217-V'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xf7d0, size 131072, enabled
bar   [14] = type Memory, range 32, base 0xf7d35000, size 4096, enabled
bar   [18] = type I/O Port, range 32, base 0xf080, size 32, enabled
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 13[e0] = PCI Advanced Features: FLR TP


gb0@pci0:4:0:0:class=0x02 card=0x00028086 chip=0x15848086 rev=0x03 
hdr=0x00
vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xf790, size 1048576, enabled
bar   [1c] = type Memory, range 32, base 0xf7a0, size 16384, enabled
cap 01[40] = powerspec 3  supports D0 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks 
cap 11[70] = MSI-X supports 5 messages, enabled
 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) FLR NS
 max read 512
 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1)
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 x
ecap 0017[1a0] = TPH Requester 1

Kind regards,

oh

NFSv4: Invalid fstype: Invalid argument

[FreeBSD User]

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: nmount: /tmp/mnt, Invalid fstype: Invalid argument

and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on 
the server side,
see below) via

:/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt
[udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
or
:/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt
[udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered

Womdering about the TCP conenction attempts, I checked the configurations on 
both, the CURRENT
and XigmaNAS (server) side.

[... server side ...]
nas01: ~# ps -waux|grep mountd
root   4332   0.0  0.0  11684  2652  -  Is   23:13  0:00.01 
/usr/sbin/mountd -l -r -S
-R /etc/exports /etc/zfs/exports

rpcinfo -p
   program vers proto   port  service
104   tcp111  rpcbind
103   tcp111  rpcbind
102   tcp111  rpcbind
104   udp111  rpcbind
103   udp111  rpcbind
102   udp111  rpcbind
104 local111  rpcbind
103 local111  rpcbind
102 local111  rpcbind
1000241   udp671  status
1000241   tcp671  status
1000210   udp   1003  nlockmgr
1000210   tcp603  nlockmgr
1000211   udp   1003  nlockmgr
1000211   tcp603  nlockmgr
1000213   udp   1003  nlockmgr
1000213   tcp603  nlockmgr
1000214   udp   1003  nlockmgr
1000214   tcp603  nlockmgr

I do not see mountd nor nfsd being registered, hope this is all right within a 
NFSv4-only
environment.

Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT 
client I try to
access the XigmaNAS NFSv4 fs from, rpcinfo looks like:

(current server):
root@walhall:/usr/src # rpcinfo -p
   program vers proto   port  service
104   tcp111  rpcbind
103   tcp111  rpcbind
102   tcp111  rpcbind
104   udp111  rpcbind
103   udp111  rpcbind
102   udp111  rpcbind
104 local111  rpcbind
103 local111  rpcbind
102 local111  rpcbind
1000241   udp774  status
1000241   tcp774  status
1000210   udp746  nlockmgr
1000210   tcp661  nlockmgr
1000211   udp746  nlockmgr
1000211   tcp661  nlockmgr
1000213   udp746  nlockmgr
1000213   tcp661  nlockmgr
1000214   udp746  nlockmgr
1000214   tcp661  nlockmgr

Well, I also checked from client to current server and client to XigmaNAS 
server via rpcinfo
-p and I get always the very same result.

Checking the accessibility of the server host on the net via nmap gives this 
result (please be
aware we use a dual stack network and need both IPv6 and IPv4 access so this 
attempt shows
IPv4 access, but IPv6 access is also granted and assured):

UDP:
:/etc # nmap -sU 192.168.0.11
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST
Nmap scan report for nas01.intern (192.168.0.11)
Host is up (0.00094s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
111/udp  open  rpcbind
514/udp  open|filtered syslog
2049/udp open  nfs
5353/udp open  zeroconf

and TCP (since port 2049/NFSv4 is tcp):
:/etc # nmap -sS 192.168.0.11
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST
Nmap scan report for nas01.intern (192.168.0.11)
Host is up (0.00074s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
443/tcp  open  https
2049/tcp open  nfs

I'm out of ideas here. What does 

mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument

mean? Is it the server reporting that it doesn't serve the requested fstyp or 
is there an
issue with the local filesystem/mountpoint (located on UFS/FFS, the backend NFS 
fs are all
located on ZFS)?

I'm drifting like a dead man in the water here and I did not find aome answeres 
to the error
reported here in the net applicable to the problem seen.

Some hints are highly appreciated.

Tahnks in advance and kind regards,

oh





-- 
O. Hartmann

Re: NFSv4: Invalid fstype: Invalid argument

[FreeBSD User]

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 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: nmount: /tmp/mnt, Invalid fstype: Invalid argument
> 
> and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on 
> the server side,
> see below) via
> 
> :/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt
> [udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
> or
> :/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt
> [udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
> 
> Womdering about the TCP conenction attempts, I checked the configurations on 
> both, the
> CURRENT and XigmaNAS (server) side.
> 
> [... server side ...]
> nas01: ~# ps -waux|grep mountd
> root   4332   0.0  0.0  11684  2652  -  Is   23:13  0:00.01 
> /usr/sbin/mountd -l -r -S
> -R /etc/exports /etc/zfs/exports
> 
> rpcinfo -p
>program vers proto   port  service
> 104   tcp111  rpcbind
> 103   tcp111  rpcbind
> 102   tcp111  rpcbind
> 104   udp111  rpcbind
> 103   udp111  rpcbind
> 102   udp111  rpcbind
> 104 local111  rpcbind
> 103 local111  rpcbind
> 102 local111  rpcbind
> 1000241   udp671  status
> 1000241   tcp671  status
> 1000210   udp   1003  nlockmgr
> 1000210   tcp603  nlockmgr
> 1000211   udp   1003  nlockmgr
> 1000211   tcp603  nlockmgr
> 1000213   udp   1003  nlockmgr
> 1000213   tcp603  nlockmgr
> 1000214   udp   1003  nlockmgr
> 1000214   tcp603  nlockmgr
> 
> I do not see mountd nor nfsd being registered, hope this is all right within 
> a NFSv4-only
> environment.
> 
> Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT 
> client I try to
> access the XigmaNAS NFSv4 fs from, rpcinfo looks like:
> 
> (current server):
> root@walhall:/usr/src # rpcinfo -p
>program vers proto   port  service
> 104   tcp111  rpcbind
> 103   tcp111  rpcbind
> 102   tcp111  rpcbind
> 104   udp111  rpcbind
> 103   udp111  rpcbind
> 102   udp111  rpcbind
> 104 local111  rpcbind
> 103 local111  rpcbind
> 102 local111  rpcbind
> 1000241   udp774  status
> 1000241   tcp774  status
> 1000210   udp746  nlockmgr
> 1000210   tcp661  nlockmgr
> 1000211   udp746  nlockmgr
> 1000211   tcp661  nlockmgr
> 1000213   udp746  nlockmgr
> 1000213   tcp661  nlockmgr
> 1000214   udp746  nlockmgr
> 1000214   tcp661  nlockmgr
> 
> Well, I also checked from client to current server and client to XigmaNAS 
> server via rpcinfo
> -p and I get always the very same result.
> 
> Checking the accessibility of the server host on the net via nmap gives this 
> result (please
> be aware we use a dual stack network and need both IPv6 and IPv4 access so 
> this attempt shows
> IPv4 access, but IPv6 access is also granted and assured):
> 
> UDP:
> :/etc # nmap -sU 192.168.0.11
> Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST
> Nmap scan report for nas01.intern (192.168.0.11)
> Host is up (0.00094s latency).
> Not shown: 996 closed ports
> PORT STATE SERVICE
> 111/udp  open  rpcbind
> 514/udp  open|filtered syslog
> 2049/udp open  nfs
> 5353/udp open  zeroconf
> 
> and TCP (since port 2049/NFSv4 is tcp):
> :/etc # nmap -sS 192.168.0.11
> Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST
> Nmap scan report for nas01.intern (192.168.0.11)
> Host is up (0.00074s latency).
> Not shown: 996 closed ports
> PORT STATE SERVICE
> 22/tcp   open  ssh
> 111/tcp  open  rpcbind
> 443/tcp  open  https
> 2049/tcp open  nfs
> 
> I'm out of ideas here. What does 
> 
> mount_nfs: nmount: /tmp/mnt, Invalid fstype: Inv

ZFS: cannot import zroot: I/O error

[FreeBSD User]

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 cold 
start it after
approx. 30 minutes of waiting. After that, rhe virtual drive and its ZFS 
filesystem was
wrecked, shwing a stream of 

zio_read error: 5
ZFS: i/o error - all block copies unavailable

After a quick search I found some advices howto try fixing, last an longest one 
was 

zpool import -fFX -N -R /alternate/path zroot

which took approx 20 minutes - with no success.

There are some valuable data on the partition, which are all backed up, but it 
would take its
time to restore everything, so I'd like to ask whether there is any cance to 
"repair" the
mysterious damage.

I'm able to boot off from an USB flash drive ...

Kind regards

oh



-- 
O. Hartmann

security/clamav: /ar/run on TMPFS renders the port broken by design

[FreeBSD User]

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-footprint
installation schemes in which /var/run - amongst other system folders - are 
created at boot
time as TMPFS and highly volatile.

In our case, the boxes running a small security appliance based upon FreeBSD is 
rebooted every
24 hours and so /var/run is vanishing.

To make the long story short:

The solution for this problem would be a check for existence and take action 
addendum in
precmd() routine of the rc-script as sketched in Bug 259699.
The maintainer rejects such a workaround by arguing this would violate POLA 
(see comment 4 in
PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound to 
me.

The question is: how can this issue be solved?

It is really hard to always chenge our local repository and patch whenever 
clamav has been
patched and modified for what reason ever.

Tahanks for reading,

kind regards

O. Hartmann

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699


-- 
O. Hartmann

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[FreeBSD User]

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 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-footprint
> > installation schemes in which /var/run - amongst other system folders - are 
> > created at boot
> > time as TMPFS and highly volatile.
> > 
> > In our case, the boxes running a small security appliance based upon 
> > FreeBSD is rebooted
> > every 24 hours and so /var/run is vanishing.
> > 
> > To make the long story short:
> > 
> > The solution for this problem would be a check for existence and take 
> > action addendum in
> > precmd() routine of the rc-script as sketched in Bug 259699.
> > The maintainer rejects such a workaround by arguing this would violate POLA 
> > (see comment 4
> > in PR 259699 [2]. The maintainer's argument regaring to mtree's files are 
> > sound to me.
> > 
> > The question is: how can this issue be solved?
> > 
> > It is really hard to always chenge our local repository and patch whenever 
> > clamav has been
> > patched and modified for what reason ever.
> > 
> > Tahanks for reading,
> >   
> 
> Why don’t you simply add an rc script to your appliance that creates the 
> missing
> directory/directories on boot before clamav is started?
> 
> Best
> Michael
> 
> 
> 

Why not fixing this on a more general basis?

Best regards,

oh

-- 
O. Hartmann

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[FreeBSD User]

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 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-footprint
> > installation schemes in which /var/run - amongst other system folders - are 
> > created at boot
> > time as TMPFS and highly volatile.
> > 
> > In our case, the boxes running a small security appliance based upon 
> > FreeBSD is rebooted
> > every 24 hours and so /var/run is vanishing.  
> Why are you rebooting every 24 hours?

The appliance has to be on a non-writable medium and is to be rebooted every 24 
hours to
cleanse temporary memory. This is given in the specs and by the department(s) 
the appliance
is for. 

Kind regards
> 
> Best regards
> Michael
> > 
> > To make the long story short:
> > 
> > The solution for this problem would be a check for existence and take 
> > action addendum in
> > precmd() routine of the rc-script as sketched in Bug 259699.
> > The maintainer rejects such a workaround by arguing this would violate POLA 
> > (see comment 4
> > in PR 259699 [2]. The maintainer's argument regaring to mtree's files are 
> > sound to me.
> > 
> > The question is: how can this issue be solved?
> > 
> > It is really hard to always chenge our local repository and patch whenever 
> > clamav has been
> > patched and modified for what reason ever.
> > 
> > Tahanks for reading,
> > 
> > kind regards
> > 
> > O. Hartmann
> > 
> > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585
> > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699
> > 
> > 
> > -- 
> > O. Hartmann
> >   
> 
> 



-- 
O. Hartmann

Re: security/clamav: /var/run on TMPFS renders the port broken by design

[FreeBSD User]

Am Sun, 28 Aug 2022 06:11:20 -0700
Cy Schubert  schrieb:

> In message <20220828130107.1a76d54a.gre...@freebsd.org>, Michael Gmelin 
> writes:
> > 
> >
> >
> > On Sun, 28 Aug 2022 03:21:24 -0700
> > Cy Schubert  wrote:
> >  
> > > In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>,
> > > Michael Gmelin w
> > > rites:  
> > > > 
> > > >
> > > >
> > > > > On 28. Aug 2022, at 10:42, free...@oldach.net wrote:
> > > > >=20
> > > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > > > (CEST):
> > > > >> As stated before in this thread, replacing /var/run with tmpfs
> > > > >> is not a supported configuration.
> > > > >=20
> > > > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > > > creates a t=
> > > > mpfs backed /var, populates it through mtree, and makes a proper
> > > > /var/run av= ailable.
> > > > >=20
> > > > > However it doesn't (yet) create /var/run/clamav of course.
> > > > >=20
> > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > > > walks thro=
> > > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > > > found as need= ed. All that the security/clamav port would need to
> > > > do then is to drop an ap= propriate small mtree file as
> > > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > > > the same logic as dropping service scripts as /usr/local/=
> > > > etc/rc.d/clamav-*.
> > > >
> > > > =46rom a user's perspective, it would be preferable to have this
> > > > happen at s= ervice start though, as (unlike in the setup
> > > > described) reboots don't happen= that frequently, but files in
> > > > /var/run might get deleted manually. Maybe so= me rc framework
> > > > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > > > which, if set, is applied in the default start_precmd. Besides
> > > > being mo= re resilient, this would also have the advantage that all
> > > > required file syst= ems should be available at that point and the
> > > > separation between system and p = orts would be more clear. Another
> > > > advantage would be that directories are on= ly created for services
> > > > that are actually enabled/started.
> > > 
> > > Unfortunately this requires all ports to include an mtree file.
> > > Relying on port maintainers who are human to ensure that these files
> > > are created and updated when ports are created and maintained will
> > > result in more human error. I've learned over my long career to rely
> > > more on automation than human beings. Automation [should] never fail
> > > and when it does it does temporarily until the bug is found and
> > > fixed. Human beings inconsistently fail.
> > > 
> > > If it were an auto-discovery script that created an mtree file as
> > > part of the packaging process, it would be another matter. But this
> > > optional solution path should be discussed on ports@, not here.
> > > 
> > >   
> >
> > I don't have much skin in the game, but I created a little proof of
> > concept to allow further discussion (which is not ports-specific, as it
> > works for all service scripts):
> >
> > https://reviews.freebsd.org/D36385  
> 
> I've been toying with the idea for a few months but was never bothered to 
> create a review or even a script for that matter.
> 
> >
> > This basically allows both system admins and port maintainers to
> > create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
> > always relative to the service script called) which are automatically
> > applied on service start. It's non-intrusive and doesn't require any
> > sweeping changes to existing ports/services.  
> 
> Understood that this is a manual process.
> 
> >
> > In this specific case, the requester could create
> > /usr/local/etc/mtree/clamav-clamd with the required content (or
> > persuade the port maintainer to include that file).
> >
> > You could of course add some construct to the ports framework that
> > picks up certain directories from the package list automatically and
> > places them into an mtree file as part of the build or installation
> > process. But that would be an additional feature on top of this change.  
> 
> Someone could. Personally, I think that's a lot of work compared to simply 
> saving the state of /var/run at shutdown and restoring it at boot. I can't 
> speak for the ports management though.
> 
> >
> > This is meant to inspire more discussions, I'm not trying to force
> > anything in. ;)  
> 
> Agreed.
> 
> I cobbled something up yesterday that saves the directory tree state of 
> /var/run prior to shutdown (or manually) and restores it at boot.
> 
> https://reviews.freebsd.org/D36386
> 
> People can try 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 

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

[FreeBSD User]

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 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 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: Mon Dec  2 
> > > > 23:11:07 CET 2024
> > > > amd64
> > > >
> > > > When performing "git pull" und /usr/ports, I received after roughly 5-7 
> > > > minutes:
> > > >
> > > > error: RPC failed: curl 56 recv failure: Operation timed out
> > > 
> > > Generally it would be worth seeing if the HTTP(S) layers are doing the 
> > > right thing
> > > or not, and then working down from there, to tcpdump / wireshark and then 
> > > if
> > > necessary into kernel itself.  
> > 
> > My skills are limited, according to packet analysis utilizing 
> > tcpdum/wireshark (and
> > theory,of course). I tried due to "a feeling" my used older Intel based NIC 
> > could have
> > some checksum issues like in the past (I saw e1000 driver updates recently 
> > flowing
> > into FreeBSD CURRENT).  
> > > 
> > > If fetch fails reliably in ports distfile fetching, then isolate a 
> > > suitable tarball,
> > > and try it again in curl, with tcpdump already prepared to capture 
> > > traffic to the
> > > remote host.
> > > 
> > > tcpdump -w /tmp/curl.pcap -i ... host ...
> > > 
> > > env SSLKEYLOGFILE=/tmp/ssl.keys curl -vsSLo /dev/null --trace
> > > /tmp/curl.log https://what.ev/er
> > > 
> > > I would guess that between the two something useful should pop up.
> > > 
> > > I like opening the pcap in wireshark, it often has angry red and black 
> > > highlighted
> > > lines already giving me a hint.
> > > 
> > > The SSLKEYLOGFILE can be imported into wireshark, and allows decrypting 
> > > the TLS
> > > traffic as well in case there are issues further in. Very handy,
> > > see https://everything.curl.dev/usingcurl/tls/sslkeylogfile.html for how 
> > > to do that.
> > > 
> > > If your issues only occur with git pull, its also curl inside and 
> > > supports similar
> > > debugging. Ferreting
> > > through 
> > > https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems/56094711#56094711
> > >  should get you similar info.
> > > 
> > > A+
> > > Dave
> > >   
> > 
> > Thanks for the hints and precious tips! I'll digg deeper into the matter.
> > 
> > In the meanwhile, I updated some other machines running CURRENT since 
> > approx. two
> > weeks with an older CURRENT to the most recent one - and face similar but 
> > not
> > identical problems!
> > Updating exiting FreeBSD repositories, like src.git and ports.git, show no 
> > problems
> > except they take longer to accomplish than expected.
> > Cloning a repo is impossible, after 10 or 15 minutes I receive a timeout.
> > 
> > On aCURRENT recently updated and worked flawlessly before (CURRENT now: 
> > FreeBSD
> > 15.0-CURRENT #5 main-n274014-b2bde8a6d39: Wed Dec  4 22:22:22 CET 2024 
> > amd64), cloning
> > attempts for 14.2-RELENG ends up in this mess:
> > 
> > # git clone --branch releng/14.2 https://git.freebsd.org/src.git 
> > 14.2-RELENG/src/
> > Cloning into '14.2-RELENG/src'...
> > error: RPC failed; curl 56 Recv failure: Operation timed out
> > fatal: expected 'packfile'
> > 
> > This is nasty. The host now in question has an i350 based dual-port NIC - 
> > the host's
> > kernel is very similar to the box I reported the issue first time, both do 
> > have
> > customized kernels (in most cases, I compile several modules like ZFS and
> > several NETGRAPH modules statically into the kernel - a habit inherited 
> > from a small
> > FBSD project I configured (I wouldn't say developed) which does not allow 
> > loadable
> > kernel

Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

[FreeBSD User]

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 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: Mon Dec  2 
> > 23:11:07 CET 2024
> > amd64
> >
> > When performing "git pull" und /usr/ports, I received after roughly 5-7 
> > minutes:
> >
> > error: RPC failed: curl 56 recv failure: Operation timed out  
> 
> Generally it would be worth seeing if the HTTP(S) layers are doing the right 
> thing or
> not, and then working down from there, to tcpdump / wireshark and then if 
> necessary
> into kernel itself.

My skills are limited, according to packet analysis utilizing tcpdum/wireshark 
(and
theory,of course). I tried due to "a feeling" my used older Intel based NIC 
could have
some checksum issues like in the past (I saw e1000 driver updates recently 
flowing into
FreeBSD CURRENT).
> 
> If fetch fails reliably in ports distfile fetching, then isolate a suitable 
> tarball,
> and try it again in curl, with tcpdump already prepared to capture traffic to 
> the
> remote host.
> 
> tcpdump -w /tmp/curl.pcap -i ... host ...
> 
> env SSLKEYLOGFILE=/tmp/ssl.keys curl -vsSLo /dev/null --trace
> /tmp/curl.log https://what.ev/er
> 
> I would guess that between the two something useful should pop up.
> 
> I like opening the pcap in wireshark, it often has angry red and black 
> highlighted
> lines already giving me a hint.
> 
> The SSLKEYLOGFILE can be imported into wireshark, and allows decrypting the 
> TLS traffic
> as well in case there are issues further in. Very handy,
> see https://everything.curl.dev/usingcurl/tls/sslkeylogfile.html for how to 
> do that.
> 
> If your issues only occur with git pull, its also curl inside and supports 
> similar
> debugging. Ferreting
> through 
> https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems/56094711#56094711
>  should get you similar info.
> 
> A+
> Dave
> 

Thanks for the hints and precious tips! I'll digg deeper into the matter.

In the meanwhile, I updated some other machines running CURRENT since approx. 
two weeks
with an older CURRENT to the most recent one - and face similar but not 
identical
problems!
Updating exiting FreeBSD repositories, like src.git and ports.git, show no 
problems
except they take longer to accomplish than expected.
Cloning a repo is impossible, after 10 or 15 minutes I receive a timeout.

On aCURRENT recently updated and worked flawlessly before (CURRENT now: FreeBSD
15.0-CURRENT #5 main-n274014-b2bde8a6d39: Wed Dec  4 22:22:22 CET 2024 amd64), 
cloning
attempts for 14.2-RELENG ends up in this mess:

# git clone --branch releng/14.2 https://git.freebsd.org/src.git 
14.2-RELENG/src/
Cloning into '14.2-RELENG/src'...
error: RPC failed; curl 56 Recv failure: Operation timed out
fatal: expected 'packfile'

This is nasty. The host now in question has an i350 based dual-port NIC - the 
host's
kernel is very similar to the box I reported the issue first time, both do have
customized kernels (in most cases, I compile several modules like ZFS and
several NETGRAPH modules statically into the kernel - a habit inherited from a 
small FBSD
project I configured (I wouldn't say developed) which does not allow loadable 
kernel
modules due to regulations.

I hoped others would stumble over this tripwire in recent CURRENT sources, 
since the
phenomena and its distribution over a bunch of CURRENT boxes with different OS 
states
seemingly show different behviour.

And for the record: I also build my ports via poudriere and mostly via make. I 
also
rebuilt in a two day's marathon all packages via "make -f" - for librewolf, 
curl and so
on to ensure having latest sources/packages.

(I repeat myself here again, sorry, its for the record).

Will report in on further development and "investigations" 

Kind regards and thanks,

oh