Re: user problems when upgrading to v15

[Graham Perrin]

On 31/08/2023 03:31, brian whalen wrote:

Understood. I guess I was expecting the update process of etcupdate -p 
&& make installworld && etcupdate -B to not whack existing users or 
delete an existing root user's password. I accepted the remote and 
then recreated users and reset passwords and am retrying this.


BW


Thanks.

For clarity: did the routine /not/ prompt you to edit the file (in 
which, you would have seen conflict markers etc.)?



On 8/30/2023 7:21 PM, Graham Perrin wrote:

On 31/08/2023 03:00, brian whalen wrote:

… I ran etcupdate resolve accepting the remote option and saw 2 issues.

The root user's password was deleted.

The non root user no longer existed.
Logically, remote does not include things such as your root user's 
password.

Re: user problems when upgrading to v15

[brian whalen]

Understood. I guess I was expecting the update process of etcupdate -p 
&& make installworld && etcupdate -B to not whack existing users or 
delete an existing root user's password. I accepted the remote and then 
recreated users and reset passwords and am retrying this.


BW

On 8/30/2023 7:21 PM, Graham Perrin wrote:

On 31/08/2023 03:00, brian whalen wrote:

… I ran etcupdate resolve accepting the remote option and saw 2 issues.

The root user's password was deleted.

The non root user no longer existed.
Logically, remote does not include things such as your root user's 
password.

Re: user problems when upgrading to v15

[Graham Perrin]

On 31/08/2023 03:00, brian whalen wrote:

… I ran etcupdate resolve accepting the remote option and saw 2 issues.

The root user's password was deleted.

The non root user no longer existed.
Logically, remote does not include things such as your root user's 
password.

Re: pkg problems with v15

[Graham Perrin]

On 31/08/2023 02:59, brian whalen wrote:

…
pkg: 
http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/meta.txz: Not 
Found

…



For 15.0-CURRENT you should use latest; don't expect quarterly.

Also, it's probably too soon for latest.

1. 

2. seek (filter) main-amd64

3. click the 'Started (UTC)' column heading until you get reverse 
chronological order.


Whilst 
 
is 'stopped:done:', I can't guess whether the end result was suitable 
for general end use.

Re: user problems when upgrading to v15

[brian whalen]

I have seen this twice. Once when going from 13.2 to current 14.0 alpha1 
and then to 15, and a 2nd time when going from 13.2 to 15.


I have a user that is a member of the wheel group.

After I upgraded and ran the post reboot commands in single user mode I 
was alerted to merge conflicts. I ran etcupdate resolve accepting the 
remote option and saw 2 issues.


The root user's password was deleted.

The non root user no longer existed.

pkg problems with v15

[brian whalen]

root@f15:~ # pkg update
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap 
-f" recommended

Updating FreeBSD repository catalogue...
pkg: http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/meta.txz: 
Not Found

repository FreeBSD has no meta file, using default settings
pkg: 
http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/packagesite.pkg: 
Not Found
pkg: 
http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/packagesite.txz: 
Not Found

Unable to update repository FreeBSD
Error updating repositories!

root@f15:~ # pkg bootstrap -f
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from 
pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/quarterly, please wait...
pkg: Error fetching 
http://pkg.FreeBSD.org/FreeBSD:15:amd64/quarterly/Latest/pkg.txz: 
Operation timed out

A pre-built version of pkg could not be found for your system.
Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.

The pkg package is installed; I put it there while the system was at 13.2

root@f15:~ # pkg info
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap 
-f" recommended

bash-5.2.15    GNU Project's Bourne Again SHell
ca_root_nss-3.89.1 Root certificate bundle from the Mozilla 
Project
ccache-3.7.12_4    Tool to minimize the compile time of 
C/C++ programs
curl-8.1.2 Command line tool and library for 
transferring data with URLs

expat-2.5.0    XML 1.0 parser written in C
fusefs-libs-2.9.9_2    FUSE allows filesystem implementation in 
userspace

gettext-runtime-0.21.1 GNU gettext runtime libraries and programs
git-2.41.0 Distributed source code management tool
glib-2.76.4_1,2    Some useful routines of C programming 
(current stable version)

indexinfo-0.3.1    Utility to regenerate the GNU info page index
libdnet-1.13_3 Simple interface to low level networking 
routines

libffi-3.4.4   Foreign Function Interface
libiconv-1.17  Character set conversion library
libidn2-2.3.4  Implementation of IDNA2008 
internationalized domain names

libmspack-0.11alpha    Library for Microsoft compression formats
libnghttp2-1.53.0  HTTP/2.0 C Library
libpsl-0.21.2_3    C library to handle the Public Suffix List
libssh2-1.11.0,3   Library implementing the SSH2 protocol
libunistring-1.1   Unicode string library
libxml2-2.10.4 XML parser library for GNOME
mpdecimal-2.5.1    C/C++ arbitrary precision decimal 
floating point libraries
open-vm-tools-nox11-12.2.5,2   Open VMware tools for FreeBSD VMware 
guests (without X11)

p5-Authen-SASL-2.16_1  Perl5 module for SASL authentication
p5-CGI-4.57    Handle Common Gateway Interface requests 
and responses

p5-Clone-0.46  Recursively copy Perl datatypes
p5-Digest-HMAC-1.04    Perl5 interface to HMAC Message-Digest 
Algorithms

p5-Encode-Locale-1.05  Determine the locale encoding
p5-Error-0.17029   Error/exception handling in 
object-oriented programming style
p5-GSSAPI-0.28_2   Perl extension providing access to the 
GSSAPIv2 library

p5-HTML-Parser-3.81    Perl5 module for parsing HTML documents
p5-HTML-Tagset-3.20_1  Some useful data table in parsing HTML
p5-HTTP-Date-6.05  Conversion routines for the HTTP protocol 
date formats

p5-HTTP-Message-6.44   Representation of HTTP style messages
p5-IO-HTML-1.004   Open an HTML file with automatic charset 
detection
p5-IO-Socket-IP-0.41   Drop-in replacement for IO::Socket::INET 
supporting IPv4 and IPv6

p5-IO-Socket-SSL-2.083_1   Perl5 interface to SSL sockets
p5-LWP-MediaTypes-6.04 Guess media type for a file or a URL
p5-Mozilla-CA-20221114 Perl extension for Mozilla CA cert bundle 
in PEM format

p5-Net-SSLeay-1.92 Perl5 interface to SSL
p5-TimeDate-2.33,1 Perl5 module containing a better/faster 
date parser for absolute dates
p5-URI-5.19    Perl5 interface to Uniform Resource 
Identifier (URI) references
pcre2-10.42    Perl Compatible Regular Expressions 
library, version 2

perl5-5.32.1_3 Practical Extraction and Report Language
pkg-1.19.2 Package manager
python39-3.9.17    Interpreted object-oriented programming 
language
readline-8.2.1 Library for editing command lines as they 
are typed

Re: Possible regression in main causing poor performance

[Cy Schubert]

In message <20230830184426.gm1...@freebsd.org>, Glen Barber writes:
> 
>
> On Mon, Aug 28, 2023 at 06:06:09PM -0700, Mark Millard wrote:
> > Has any more been learned about this? Is it still an issue?
> >=20
>
> I rebooted the machine before the ALPHA3 builds with no other changes,
> and the overall times for 14.x builds went back to normal.  I do not
> like to experiment with builders during a release cycle, but as we are
> going to have 15.x snapshots available moving forward, I will not reboot
> that machine next week in hopes to get some useful data.
>
> If my memory serves correctly, mm@ has a pending ZFS import from
> upstream for both main and stable/14 pending.  Whether or not that will
> resolve any issue here, I do not know.

Two of my poudriere builder machines have experienced different panics 
since the ZFS import two days ago. The problems have been documented on the 
-current list.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0





Re: Possible issue with linux xattr support?

[Shawn Webb]

On Wed, Aug 30, 2023 at 06:55:14AM +0200, Alexander Leidinger wrote:
> Am 2023-08-29 21:02, schrieb Shawn Webb:
> 
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> 
> You enabled it by default. I would assume you had a thought about the
> implications... any memories about it?

I hope you don't mind if I quote a response I wrote to another person
on the list about the feature:

=== begin quote ===
In HardenedBSD's case, since we use filesystem extended attributes to
toggle exploit mitigations on a per-application basis, there's now a
conceptual security boundary between the host and the jail.

Should the jail and the host share resources, like executables, a
jailed process could toggle an exploit mitigation, and the toggle
would bubble up to the host. So the next time the host executed
/shared/app/executable/here, the security posture of the host would be
affected.

FreeBSD uses ELF header tagging, not filesystem extended attributes,
to toggle exploit mitigations. So my description above is moot for
FreeBSD users. I'm just hoping to share a unique perspective.
=== end quote ===

The main reason for enabling it by default in HardenedBSD is so that
exploit mitigation toggles get applied to the application on `pkg
install` (or `make install` in ports.) We have patches to our ports
tree and have forked pkg to support the way we toggle exploit
mitigations.

So, I wanted to make sure that applications would behave the same in a
jailed environment and the host... to avoid a POLA violation.

> 
> What I'm after is:
>  - What can go wrong if we enable it by default?

I don't know if there's anything that could go wrong if FreeBSD was to
enable it by default. I think it might be more of a downstream issue:
those who have developed custom behavior backed by filesystem extended
attributes.

>  - Why would we like to disable it (or any ideas why it is disabled by
> default in FreeBSD)?

I wouldn't want to dictate what approach FreeBSD takes, if any. I
think the approach I've taken works well for HardenedBSD. But the
FreeBSD community might prefer an entirely different approach
altogether.

> 
> Depending in the answers we may even use a simpler patch and have it allowed
> in jails even without the possibility to configure it.

I also wonder if extended attributes could be taught to (optionally?)
scope extended attributes to each jail. That might be a topic worth
exploring some day for someone. Just a random thought. :-)

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Dmitry Chagin]

On Tue, Aug 29, 2023 at 02:07:11PM -0500, Kyle Evans wrote:
> On 8/29/23 14:02, Shawn Webb wrote:
> > On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote:
> > > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > > > * Dmitry Chagin  [20230828 18:57]:
> > > > > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > > > > > * Cy Schubert  [20230827 16:59]:
> > > > > > > 
> > > > > > > If we are to break it to fix a problem, maybe a sysctl to 
> > > > > > > enable/disable then?
> > > > > > 
> > > > > > IMHO depends on the exact nature of the problem. If it's confirmed 
> > > > > > that
> > > > > > it (always and only) breaks for jailed processes, just disabling it 
> > > > > > for
> > > > > > them would be the better workaround. "No-op" calls won't break 
> > > > > > anything.
> > > > > > 
> > > > > 
> > > > > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
> > > > 
> > > > Thanks, I can confirm this avoids the issue in both cases I experienced
> > > > (install from GNU coreutils and python).
> > > > 
> > > thanks, this is the first half of the fix, it works for you due to you
> > > are running tools under unprivileged user, afaiu. The second I have
> > > tested by myself :)
> > > 
> > > > If I understand this patch correctly, it completely avoids EPERM,
> > > > masking it as not supported, so callers should consider it non-fatal,
> > > > allowing to silently ignore writing of "system" attributes while still
> > > > keeping other functionality?
> > > > 
> > > system namespace is accessible only for privileged user, for others Linux
> > > returns ENOTSUP. So many tools ignores this error, eg ls.
> > > 
> > > the second: https://people.freebsd.org/~dchagin/sea_jailed.patch
> > > 
> > > Try this under privileged user, please.
> > 
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > 
> > Hopefully that's useful to someone.
> > 
> > Thanks,
> > 
> 
> FWIW (which likely isn't much), I like this approach much better; it makes
> more sense to me that it's a feature controlled by the creator of the jail
> and not one allowed just by using a compat ABI within a jail.
>


Seems phab mail is dead, https://reviews.freebsd.org/D41643

Re: sscanf change prevents build of CURRENT

[Dag-Erling Smørgrav]

"John F Carr"  writes:
> I had a problem yesterday and today rebuilding a -CURRENT system from
> source: [...]  The cause was an sscanf call unexpectedly failing to
> parse the input.  This caused the mkmagic program (internal tool used
> to build magic number table for file) to fail.

This was fixed in aca3bd160257.

> I am trying to manually compile a working mkmagic and restart the
> build to get unstuck.

mkmagic is fine, just build and install libc.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

Re: Possible regression in main causing poor performance

[Glen Barber]

On Mon, Aug 28, 2023 at 06:06:09PM -0700, Mark Millard wrote:
> Has any more been learned about this? Is it still an issue?
> 

I rebooted the machine before the ALPHA3 builds with no other changes,
and the overall times for 14.x builds went back to normal.  I do not
like to experiment with builders during a release cycle, but as we are
going to have 15.x snapshots available moving forward, I will not reboot
that machine next week in hopes to get some useful data.

If my memory serves correctly, mm@ has a pending ZFS import from
upstream for both main and stable/14 pending.  Whether or not that will
resolve any issue here, I do not know.

Glen



signature.asc
Description: PGP signature

sscanf change prevents build of CURRENT

[John F Carr]

I had a problem yesterday and today rebuilding a -CURRENT system from source:

  --- magic.mgc ---
  ./mkmagic magic
  magic, 4979: Warning: Current entry does not yet have a description for 
adding a MIME type
  mkmagic: could not find any valid magic files!

The cause was an sscanf call unexpectedly failing to parse the input.  This 
caused
the mkmagic program (internal tool used to build magic number table for file) 
to fail.

If I link mkmagic against the static libc.a in /usr/obj then it works.  So my 
installed
libc.so is broken and the latest source works.  I think.  My installed kernel 
is at
76edfabbecde, the end of the binary integer parsing commit series, so my libc
should be the same.

The program below demonstrates the bug.  See src/contrib/file/src for context.

I am trying to manually compile a working mkmagic and restart the build to get 
unstuck.

#include 
#include 

struct guid {
uint32_t data1;
uint16_t data2;
uint16_t data3;
uint8_t data4[8];
};

int main(int argc, char *argv[])
{
  struct guid g = {0, 0, 0, {0}};
  char *text = "75B22630-668E-11CF-A6D9-00AA0062CE6C";

  if (argc > 1)
text = argv[1];
  int count =
sscanf(text,
   "%8x-%4hx-%4hx-%2hhx%2hhx-%2hhx%2hhx%2hhx%2hhx%2hhx%2hhx",
   , , , [0], [1],
   [2], [3], [4], [5],
   [6], [7]);

  fprintf(stdout,
  
"[%d]:\n%08x-%04hx-%04hx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx\n",
  count,
  g.data1, g.data2, g.data3, g.data4[0], g.data4[1],
  g.data4[2], g.data4[3], g.data4[4], g.data4[5],
  g.data4[6], g.data4[7]);
  return count != 11;
}

Another ZFS Panic -- buffer modified while frozen

[Cy Schubert]

A different panic on a different amd64 machine also running poudriere but 
building amd64 packages. Exmh was just started, displaying back to my 
laptop at the time of panic.

panic: buffer modified while frozen!
cpuid = 1
time = 1693417762
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe008e67fba0
vpanic() at vpanic+0x132/frame 0xfe008e67fcd0
panic() at panic+0x43/frame 0xfe008e67fd30
arc_cksum_verify() at arc_cksum_verify+0x12c/frame 0xfe008e67fd80
arc_buf_destroy_impl() at arc_buf_destroy_impl+0x6f/frame 0xfe008e67fdc0
arc_buf_destroy() at arc_buf_destroy+0xd5/frame 0xfe008e67fdf0
dbuf_destroy() at dbuf_destroy+0x60/frame 0xfe008e67fe40
dbuf_evict_one() at dbuf_evict_one+0x176/frame 0xfe008e67fe70
dbuf_evict_thread() at dbuf_evict_thread+0x345/frame 0xfe008e67fef0
fork_exit() at fork_exit+0x82/frame 0xfe008e67ff30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe008e67ff30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 3h46m10s
Dumping 1962 out of 8122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91
%

__curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57
57  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu
,
(kgdb) bt
#0  __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57
#1  doadump (textdump=textdump@entry=1)
at /opt/src/git-src/sys/kern/kern_shutdown.c:405
#2  0x806c1b30 in kern_reboot (howto=260)
at /opt/src/git-src/sys/kern/kern_shutdown.c:526
#3  0x806c202f in vpanic (
fmt=0x83d82b7c "buffer modified while frozen!", 
ap=ap@entry=0xfe008e67fd10)
at /opt/src/git-src/sys/kern/kern_shutdown.c:970
#4  0x806c1dd3 in panic (fmt=)
at /opt/src/git-src/sys/kern/kern_shutdown.c:894
#5  0x83ae5f2c in arc_cksum_verify (buf=0xf80188cde180)
at /opt/src/git-src/sys/contrib/openzfs/module/zfs/arc.c:1475
#6  0x83ae99ff in arc_buf_destroy_impl (
buf=buf@entry=0xf80188cde180)
at /opt/src/git-src/sys/contrib/openzfs/module/zfs/arc.c:3113
#7  0x83ae9625 in arc_buf_destroy (buf=0xf80188cde180, 
tag=tag@entry=0xf80104a534c8)
at /opt/src/git-src/sys/contrib/openzfs/module/zfs/arc.c:3889
#8  0x83b0eee0 in dbuf_destroy (db=db@entry=0xf80104a534c8)
at /opt/src/git-src/sys/contrib/openzfs/module/zfs/dbuf.c:2983
#9  0x83b17996 in dbuf_evict_one ()
at /opt/src/git-src/sys/contrib/openzfs/module/zfs/dbuf.c:781
--Type  for more, q to quit, c to continue without paging--c
#10 0x83b0c345 in dbuf_evict_thread (unused=)
at /opt/src/git-src/sys/contrib/openzfs/module/zfs/dbuf.c:819
#11 0x80677ab2 in fork_exit (
callout=0x83b0c000 , arg=0x0, 
frame=0xfe008e67ff40) at /opt/src/git-src/sys/kern/kern_fork.c:1160
#12 
(kgdb) 


FreeBSD cwsys 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #4 
komquats-n26508
9-b22aae410bc7: Wed Aug 30 04:38:24 PDT 2023 root@cwsys:/export/obj/opt/
src/
git-src/amd64.amd64/sys/BREAK2 amd64

Almost the same configuration as the other machine.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0




Re: 100% CPU time for sysctl command, not killable

[Alexander Leidinger]

Am 2023-08-20 21:23, schrieb Alexander Leidinger:


Am 2023-08-20 18:55, schrieb Mina Galić:
procstat(1) kstack could be helpful here.

 Original Message 
On 20 Aug 2023, 17:29, Alexander Leidinger alexan...@leidinger.net> 
wrote:
Hi, sysctl kern.maxvnodes=1048576000 results in 100% CPU and a 
non-killable sysctl program. This is somewhat unexpected... Bye, 
Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 
0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 
0x8F31830F9F2772BF


  PIDTID COMMTDNAME  KSTACK
94391 118678 sysctl  -   sysctl_maxvnodes 
sysctl_root_handler_locked sysctl_root userland_sysctl sys___sysctl 
amd64_syscall fast_syscall_common


I experimented a bit by multiplying my initial value of 104857600. It 
fails between 5 and 6 times the initial value.


sysctl kern.maxvnodes=524288000 is successful within 4 seconds.

sysctl kern.maxvnodes=629145600 goes into a loop with the same procstat 
-k output.


Bye,

Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: ZFS Page Derefrence

[Cy Schubert]

In message , Mark Johnston writes:
> On Tue, Aug 29, 2023 at 07:08:35PM -0700, Cy Schubert wrote:
> > Hi
> > 
> > Just got the following panic on an and64 machine running poudriere building
>  
> > i386 packages.
> > 
> > panic: vm_page_dequeue_deferred: page 0xfe000b222808 has unexpected 
> > queue state^M
> > [...]
> > 
> > uname reports,
> > 
> > FreeBSD bob 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #1 
> > komquats-n265075-2e8edbc285cf: Tue Aug 29 03:51:59 PDT 2023 
> > root@cwsys:/export/obj/opt/src/git-src/amd64.amd64/sys/BREAK2 amd64
> > 
> > My BREAK2 kernel removes devices I don't use and enables keystrokes to 
> > interrupt the system from the conosle (conserver). Local patches affect 
> > ipfilter only.
> > 
> > Head of core.txt:
> > 
> > __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57
> > 57  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
>  
> > pcpu
> > ,
> > (kgdb) #0  __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:
> 5
> > 7
> > #1  doadump (textdump=textdump@entry=1)
> > at /opt/src/git-src/sys/kern/kern_shutdown.c:405
> > #2  0x806c1b30 in kern_reboot (howto=260)
> > at /opt/src/git-src/sys/kern/kern_shutdown.c:526
> > #3  0x806c202f in vpanic (
> > fmt=0x80b5da55 "%s: page %p has unexpected queue state",
> > ap=ap@entry=0xfe00bf55d770)
> > at /opt/src/git-src/sys/kern/kern_shutdown.c:970
> > #4  0x806c1dd3 in panic (fmt=)
> > at /opt/src/git-src/sys/kern/kern_shutdown.c:894
> > #5  0x809daab2 in vm_page_dequeue_deferred (m=,
> > m@entry=0xfe000b222808) at /opt/src/git-src/sys/vm/vm_page.c:3790
> > #6  0x809ddfeb in vm_page_free_prep (m=m@entry=0xfe000b222808)
> > at /opt/src/git-src/sys/vm/vm_page.c:3928
>
> Could you please print/x *m from this frame?

Sure.

(kgdb) print/x *m
$1 = {plinks = {q = {tqe_next = 0x, 
  tqe_prev = 0x}, s = {ss = {
sle_next = 0x}}, memguard = {p = 
0x,
  v = 0x}, uma = {slab = 0x, 
  zone = 0x}}, listq = {tqe_next = 0x, 
tqe_prev = 0x}, object = 0x0, pindex = 0x572c, 
  phys_addr = 0x1b67d5000, md = {pv_list = {tqh_first = 0x0, 
  tqh_last = 0xfe000b222840}, pv_gen = 0xf4a, pat_mode = 0x6}, 
  ref_count = 0x0, busy_lock = 0xfffe, a = {{flags = 0x10, queue = 
0xff,
  act_count = 0x0}, _bits = 0xff0010}, order = 0xd, pool = 0x0, 
  flags = 0x1, oflags = 0x0, psind = 0x0, segind = 0x5, valid = 0xff, 
  dirty = 0x0}
(kgdb) 


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0




Re: net/mpd5 on stable/14 - COMPAT_FREEBSD12 required?

[Herbert J. Skuhra]

On Wed, 30 Aug 2023 15:29:28 +0200, "Herbert J. Skuhra" wrote:
> 
> Hi,
> 
> after updating from stable/13 to (main and later to) stable/14
> net/mpd5 only connects to my ISP (VDSL with VLAN) if I enable "options
> COMPAT_FREEBSD12" in my kernel. Without I get only:
> 
> Aug 30 15:08:06 gw mpd[59876]: [L1] PPPoE connection timeout after 9 seconds
> Aug 30 15:08:06 gw mpd[59876]: [L1] Link: DOWN event
> Aug 30 15:08:06 gw mpd[59876]: [L1] LCP: Down event
> Aug 30 15:08:06 gw mpd[59876]: [L1] Link: reconnection attempt 1 in 7 seconds
> Aug 30 15:08:14 gw mpd[59876]: [L1] Link: reconnection attempt 1
> Aug 30 15:08:14 gw mpd[59876]: [L1] PPPoE: Connecting to ''
> Aug 30 15:08:23 gw mpd[59876]: [L1] PPPoE connection timeout after 9 seconds
> Aug 30 15:08:23 gw mpd[59876]: [L1] Link: DOWN event
> Aug 30 15:08:23 gw mpd[59876]: [L1] LCP: Down event
> [..]
> 
> I guess the problem is:
> 
> Without "COMPAT_FREEBSD12" vlanproto = 0x. If I run "ifconfig
> vlan31 vlanproto 802.1q" mpd5 works.

Maybe this commit is related:

commit afbb64f1d85b7d8c2938031c3567946b5d10da4f
Author: Alexander V. Chernikov
Date:   Sun Apr 11 17:47:03 2021 +0100

Fix vlan creation for the older ifconfig(8) binaries.

Reported by:allanjude
MFC after:  immediately

?

--
Herbert

net/mpd5 on stable/14 - COMPAT_FREEBSD12 required?

[Herbert J. Skuhra]

Hi,

after updating from stable/13 to (main and later to) stable/14
net/mpd5 only connects to my ISP (VDSL with VLAN) if I enable "options
COMPAT_FREEBSD12" in my kernel. Without I get only:

Aug 30 15:08:06 gw mpd[59876]: [L1] PPPoE connection timeout after 9 seconds
Aug 30 15:08:06 gw mpd[59876]: [L1] Link: DOWN event
Aug 30 15:08:06 gw mpd[59876]: [L1] LCP: Down event
Aug 30 15:08:06 gw mpd[59876]: [L1] Link: reconnection attempt 1 in 7 seconds
Aug 30 15:08:14 gw mpd[59876]: [L1] Link: reconnection attempt 1
Aug 30 15:08:14 gw mpd[59876]: [L1] PPPoE: Connecting to ''
Aug 30 15:08:23 gw mpd[59876]: [L1] PPPoE connection timeout after 9 seconds
Aug 30 15:08:23 gw mpd[59876]: [L1] Link: DOWN event
Aug 30 15:08:23 gw mpd[59876]: [L1] LCP: Down event
[..]

I guess the problem is:

Without "COMPAT_FREEBSD12" vlanproto = 0x. If I run "ifconfig
vlan31 vlanproto 802.1q" mpd5 works.

--
Herbert

Re: ZFS Page Derefrence

[Mark Johnston]

On Tue, Aug 29, 2023 at 07:08:35PM -0700, Cy Schubert wrote:
> Hi
> 
> Just got the following panic on an and64 machine running poudriere building 
> i386 packages.
> 
> panic: vm_page_dequeue_deferred: page 0xfe000b222808 has unexpected 
> queue state^M
> [...]
> 
> uname reports,
> 
> FreeBSD bob 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #1 
> komquats-n265075-2e8edbc285cf: Tue Aug 29 03:51:59 PDT 2023 
> root@cwsys:/export/obj/opt/src/git-src/amd64.amd64/sys/BREAK2 amd64
> 
> My BREAK2 kernel removes devices I don't use and enables keystrokes to 
> interrupt the system from the conosle (conserver). Local patches affect 
> ipfilter only.
> 
> Head of core.txt:
> 
> __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57
> 57  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
> pcpu
> ,
> (kgdb) #0  __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:5
> 7
> #1  doadump (textdump=textdump@entry=1)
> at /opt/src/git-src/sys/kern/kern_shutdown.c:405
> #2  0x806c1b30 in kern_reboot (howto=260)
> at /opt/src/git-src/sys/kern/kern_shutdown.c:526
> #3  0x806c202f in vpanic (
> fmt=0x80b5da55 "%s: page %p has unexpected queue state",
> ap=ap@entry=0xfe00bf55d770)
> at /opt/src/git-src/sys/kern/kern_shutdown.c:970
> #4  0x806c1dd3 in panic (fmt=)
> at /opt/src/git-src/sys/kern/kern_shutdown.c:894
> #5  0x809daab2 in vm_page_dequeue_deferred (m=,
> m@entry=0xfe000b222808) at /opt/src/git-src/sys/vm/vm_page.c:3790
> #6  0x809ddfeb in vm_page_free_prep (m=m@entry=0xfe000b222808)
> at /opt/src/git-src/sys/vm/vm_page.c:3928

Could you please print/x *m from this frame?

Re: Possible issue with linux xattr support?

[Dmitry Chagin]

On Wed, Aug 30, 2023 at 12:58:45PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230830 13:48]:
> > On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> > > Unfortunately, install from GNU coreutils is now unable to install
> > > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > > a difference:
> > > [...]
> > > I assume the fsetxattr call needs some adjustment of error codes as well
> > > to make GNU tools play nice.
> > > 
> > 
> > I don't changed setxattr syscalls due to EPERM is a valid error from it,
> > however here's the essential difference between Linux and FreeBSD.
> > FreeBSD does not permits manipulatingg attributes in the
> > system namespace for unprivileged accounts.
> 
> Interesting! (and, a weird design ...)
> 
> > https://people.freebsd.org/~dchagin/xattr.patch
> 
> Yes, that's basically the same change I meanwhile did locally, except I
> restricted the adjustment to cases of writing the system namespace --
> not sure that's good for anything though.
> 
> In short: Works fine that way!
> 
Thanks, I see, I agree with your change, taken into account.

Re: Possible issue with linux xattr support?

[Felix Palmen]

* Felix Palmen  [20230830 12:58]:
> * Dmitry Chagin  [20230830 13:48]:
> > I don't changed setxattr syscalls due to EPERM is a valid error from it,
> > however here's the essential difference between Linux and FreeBSD.
> > FreeBSD does not permits manipulatingg attributes in the
> > system namespace for unprivileged accounts.
> 
> Interesting! (and, a weird design ...)

I meant the filesystem-specific policies of course. Quoting fail on my
side.

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Felix Palmen]

* Dmitry Chagin  [20230830 13:48]:
> On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> > Unfortunately, install from GNU coreutils is now unable to install
> > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > a difference:
> > [...]
> > I assume the fsetxattr call needs some adjustment of error codes as well
> > to make GNU tools play nice.
> > 
> 
> I don't changed setxattr syscalls due to EPERM is a valid error from it,
> however here's the essential difference between Linux and FreeBSD.
> FreeBSD does not permits manipulatingg attributes in the
> system namespace for unprivileged accounts.

Interesting! (and, a weird design ...)

> https://people.freebsd.org/~dchagin/xattr.patch

Yes, that's basically the same change I meanwhile did locally, except I
restricted the adjustment to cases of writing the system namespace --
not sure that's good for anything though.

In short: Works fine that way!

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Dmitry Chagin]

On Wed, Aug 30, 2023 at 12:33:23PM +0200, Felix Palmen wrote:
> * Felix Palmen  [20230830 12:01]:
> > Unfortunately, install from GNU coreutils is now unable to install
> > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > a difference:
> > [...]
> > I assume the fsetxattr call needs some adjustment of error codes as well
> > to make GNU tools play nice.
> 
> On a second thought, shouldn't it be two separate patches in the end?
> 
> * Some adjustment of the error codes seems to be needed to correctly
>   mimick Linux, so GNU tools et al don't misinterpret some error as
>   being "fatal"
> 
> * Optionally allowing access to the system namespace from within a jail
>   is also needed for some use cases (as shown by HBSD having a patch),
>   but is in fact unrelated to the issue with Linux *xattr calls
> 
> Please correct me if I'm wrong here ;)
>

sure, xattr.patch includes 5 commits

Re: Possible issue with linux xattr support?

[Felix Palmen]

* Felix Palmen  [20230830 12:01]:
> * Dmitry Chagin  [20230830 12:22]:
> > On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > > * Unprivileged user will get ENOTSUP when trying to access the system
> > >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> > >   coreutils install should "just work".
> > ENOTSUP or ENODATA (getxattr)
> 
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:

Sorry for the noise ... this little change fixes it for me:
https://people.freebsd.org/~zirias/patches/linux-setxattr.patch

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Dmitry Chagin]

On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230830 12:22]:
> > On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > > * Unprivileged user will get ENOTSUP when trying to access the system
> > >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> > >   coreutils install should "just work".
> > ENOTSUP or ENODATA (getxattr)
> 
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:
> 
> | # /compat/linux/usr/bin/install -c .libs/libexpat.so.1.8.10 
> /wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10
> | /compat/linux/usr/bin/install: setting permissions for 
> ‘/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10’:
>  Operation not permitted
> 
> .. and truss shows this again:
> 
> | linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation not 
> permitted'
> 
> This is without the new jail option. When I enable it, it still fails
> the same way as 'nobody' (which poudriere uses for building), but works
> fine as 'root'.
> 
> I assume the fsetxattr call needs some adjustment of error codes as well
> to make GNU tools play nice.
> 

I don't changed setxattr syscalls due to EPERM is a valid error from it,
however here's the essential difference between Linux and FreeBSD.
FreeBSD does not permits manipulatingg attributes in the
system namespace for unprivileged accounts. Well, we can return ENOTSUP
due to in Linux read and write access to system namespace depend on the
policy implemented for each filesystem, so we'll mimics we're a
filesystem that prohibits this for unprivelegd users.

https://people.freebsd.org/~dchagin/xattr.patch

Re: Possible issue with linux xattr support?

[Felix Palmen]

* Felix Palmen  [20230830 12:01]:
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:
> [...]
> I assume the fsetxattr call needs some adjustment of error codes as well
> to make GNU tools play nice.

On a second thought, shouldn't it be two separate patches in the end?

* Some adjustment of the error codes seems to be needed to correctly
  mimick Linux, so GNU tools et al don't misinterpret some error as
  being "fatal"

* Optionally allowing access to the system namespace from within a jail
  is also needed for some use cases (as shown by HBSD having a patch),
  but is in fact unrelated to the issue with Linux *xattr calls

Please correct me if I'm wrong here ;)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Felix Palmen]

* Dmitry Chagin  [20230830 12:22]:
> On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > * Unprivileged user will get ENOTSUP when trying to access the system
> >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> >   coreutils install should "just work".
> ENOTSUP or ENODATA (getxattr)

Unfortunately, install from GNU coreutils is now unable to install
anything again. I tried both as 'nobody' and as 'root', it doesn't make
a difference:

| # /compat/linux/usr/bin/install -c .libs/libexpat.so.1.8.10 
/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10
| /compat/linux/usr/bin/install: setting permissions for 
‘/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10’:
 Operation not permitted

.. and truss shows this again:

| linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation not 
permitted'

This is without the new jail option. When I enable it, it still fails
the same way as 'nobody' (which poudriere uses for building), but works
fine as 'root'.

I assume the fsetxattr call needs some adjustment of error codes as well
to make GNU tools play nice.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Dmitry Chagin]

On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230830 11:57]:
> > On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> > > Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> > > 
> > I think yes, thanks for testing, I revised the error handling and made
> > it more precise, can you test new patch in your environment.
> > 
> > https://people.freebsd.org/~dchagin/xattr.patch
> 
> Great, thanks! I see you now chose to add a jail option, certainly the
> cleanest solution.
> 
> Will test later today. Just to make sure I have the correct expectation
> about the behavior with the new patch applied:
> 
> * Unprivileged user will get ENOTSUP when trying to access the system
>   namespace (regardless of the new jail setting), so GNU tools like e.g.
>   coreutils install should "just work".
ENOTSUP or ENODATA (getxattr)

> * Root will get either ENOTSUP, or a fully working access to system.*
>   with the new jail setting enabled.
> 
> Are these assumptions correct?
> 
yes

Re: Possible issue with linux xattr support?

[Felix Palmen]

* Dmitry Chagin  [20230830 11:57]:
> On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> > Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> > 
> I think yes, thanks for testing, I revised the error handling and made
> it more precise, can you test new patch in your environment.
> 
> https://people.freebsd.org/~dchagin/xattr.patch

Great, thanks! I see you now chose to add a jail option, certainly the
cleanest solution.

Will test later today. Just to make sure I have the correct expectation
about the behavior with the new patch applied:

* Unprivileged user will get ENOTSUP when trying to access the system
  namespace (regardless of the new jail setting), so GNU tools like e.g.
  coreutils install should "just work".
* Root will get either ENOTSUP, or a fully working access to system.*
  with the new jail setting enabled.

Are these assumptions correct?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

[Dmitry Chagin]

On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230829 21:12]:
> > On Tue, Aug 29, 2023 at 07:02:22PM +0200, Felix Palmen wrote:
> > > So, using user.* works, using system.* doesn't, and maybe a bit
> > > surprising(?), dumping all attributes which by default excludes the
> > > system namespace doesn't work either.
> > > 
> > 
> > As expected, the second patch intended to allow access to system
> > namespace in jailed env.
> 
> Not exactly, according to the manual, 'getfattr -d' *excludes* the
> system namespace by default, so I would have expected it to work. But
> maybe that's an issue with the getfattr tool itself.
> 
> > > I still wonder, is the first patch needed anyways? Maybe I fail to
> > > understand something here. Won't it map *every* EPERM to ENOSUP and
> > > can't this be an issue?
> > > 
> > 
> > fine, thanks. Gnu tools running under unprivileged user will fail, eg
> > ls, which uses getfattr() to get the posix acl
> 
> Ah, I see, that would still break "Linux jails" then...
> 
> Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> 
I think yes, thanks for testing, I revised the error handling and made
it more precise, can you test new patch in your environment.

https://people.freebsd.org/~dchagin/xattr.patch

Revert previous patches