Re: Possible issue with linux xattr support?
* Dmitry Chagin [20230904 21:49]: > On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote: > > I guess I'll now do a full rebuild of my linuxulator userspace branch on > > a kernel with that patch, just to be sure it won't break anything else, > > this will take a few hours, I will report back. So far looking really > > good :) This completed while I was sleeping. No issues! With ~120 "Linux ports" building fine, using all sorts of tools (like python and some tools from coreutils), I think it's fair to assume it's all fixed now. 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 [20230904 21:49]: > On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote: > > Thanks a lot for the quick patch! I have to admit I don't fully > > understand it immediately, but I assume it's an attempt to only list > > attributes not in system.* when that namespace is restricted? > > no, > + if (error == EPERM) > + break; > mean that listxattr will fail if user is unauthorized to access system > namespace, ie, listxattr will return ENOTSUP Ah, now I get it, so breaking out of the loop there will leave attrnamespace at EXTATTR_NAMESPACE_SYSTEM if that was the cause, therefore error_to_xattrerror() works as expected. Nice! Well, given that I really don't expect any further problems, but give my poor builder a few hours to *really* verify :) 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?
Hello Dmitry, * Dmitry Chagin [20230904 21:29]: > Thanks for the report, > please, try this: https://people.freebsd.org/~dchagin/lxattr.patch > Don't be surprised, there 2 fixes Thanks a lot for the quick patch! I have to admit I don't fully understand it immediately, but I assume it's an attempt to only list attributes not in system.* when that namespace is restricted? Well, it *does* solve the issue with 'cp -p' from GNU coreutils! I guess I'll now do a full rebuild of my linuxulator userspace branch on a kernel with that patch, just to be sure it won't break anything else, this will take a few hours, I will report back. So far looking really good :) 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 [20230904 15:39]: > For some reason (I still have to try to get more information about it, > will do soon), something else is broken now. While install from GNU > coreutils works fine, some build systems use 'cp -p' to install files > instead, which now fails with: > > | cp: preserving permissions for [...]: Operation not permitted The issue seems to be with listing attributes: | root@15-default:/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/libxcb-1.15/doc # truss /compat/linux/bin/cp -pR ./tutorial '/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/stage/compat/linux/usr/share/doc/libxcb/' 2>&1 | grep xattr | linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not permitted' | linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not permitted' | linux_llistxattr(0xcdd9,0x0,0x0) ERR#-1 'Operation not permitted' The following q patch makes it work again: #v+ diff --git a/sys/compat/linux/linux_xattr.c b/sys/compat/linux/linux_xattr.c index 74b47f1cbaec..0b5af084b1b1 100644 --- a/sys/compat/linux/linux_xattr.c +++ b/sys/compat/linux/linux_xattr.c @@ -198,7 +198,7 @@ listxattr(struct thread *td, struct listxattr_args *args) if (error == 0) td->td_retval[0] = cnt; free(data, M_LINUX); - return (error_to_xattrerror(attrnamespace, error)); + return (error_to_xattrerror(EXTATTR_NAMESPACE_SYSTEM, error)); } int #v- I think this makes sense, because listxattr iterates over all namespaces, so there's no sane way to know whether the EPERM was caused by trying to access "system" or something else. 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?
Hello Dmitry, * Dmitry Chagin [20230830 14:04]: > Thanks, I see, I agree with your change, taken into account. Thanks a lot for committing the fix/workaround as well as the new feature! I just upgraded my test builders to 15-CURRENT to double-check. For some reason (I still have to try to get more information about it, will do soon), something else is broken now. While install from GNU coreutils works fine, some build systems use 'cp -p' to install files instead, which now fails with: | cp: preserving permissions for [...]: Operation not permitted I'm pretty sure this worked fine with the patch you linked earlier, and also with my own change taking the namespace into account ... Did you change anything else in your commits compared to the patch? I'll post a followup as soon as I could get some truss output to know exactly which syscall causes the issue now! 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 [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?
* 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?
* 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?
* 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?
* 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 [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 [20230829 23:16]: > On Tue, Aug 29, 2023 at 03:02:58PM -0400, Shawn Webb wrote: > > 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. > > > > Nice, thank you. I'd prefer to disable it by default, like on a host. When it's disabled by default, it will require additional configuration to make "Linux jails" work again. -- 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?
* Shawn Webb [20230829 15:25]: > On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote: > > * Kyle Evans [20230829 14:07]: > > > On 8/29/23 14:02, Shawn Webb wrote: > > > > 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. > > > > Well, a typical GNU userland won't work in a jail without this, that's > > what I know now. But I'm certainly with you, it doesn't feel logical > > that a Linux binary can do something in a jail a FreeBSD binary can't. > > > > So, indeed, making it a jail option sounds better. > > > > Unless, bringing back a question raised earlier in this thread: What's > > the reason to restrict this in a jailed context in the first place? IOW, > > could it just be allowed unconditionally? > > 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. Isn't the sane approach here *not* to share any executables with a jail other than via a read-only nullfs mount? > 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. Thanks! -- 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?
* Kyle Evans [20230829 14:07]: > On 8/29/23 14:02, Shawn Webb wrote: > > 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. Well, a typical GNU userland won't work in a jail without this, that's what I know now. But I'm certainly with you, it doesn't feel logical that a Linux binary can do something in a jail a FreeBSD binary can't. So, indeed, making it a jail option sounds better. Unless, bringing back a question raised earlier in this thread: What's the reason to restrict this in a jailed context in the first place? IOW, could it just be allowed unconditionally? 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 [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? 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 [20230829 17:45]: > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote: > > 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 :) Sure, poudriere is running all builds as "nobody" by default. > > 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 Ok, I did some tests in a poudriere jail using Linux bash, as root. First, with only the first patch: | bash-5.2# getfattr -d /bin/sh | getfattr: /bin/sh: Operation not supported | bash-5.2# setfattr -n user.foo -v bar /bin/sh | bash-5.2# getfattr -n user.foo /bin/sh | getfattr: Removing leading '/' from absolute path names | # file: bin/sh | user.foo="bar" | bash-5.2# setfattr -x user.foo /bin/sh | bash-5.2# setfattr -x system.foo /bin/sh | setfattr: /bin/sh: Operation not supported 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. Then with the second patch applied as well: | bash-5.2# getfattr -d /bin/sh | bash-5.2# setfattr -n system.foo -v bar /bin/sh | bash-5.2# getfattr -d /bin/sh -m- | getfattr: Removing leading '/' from absolute path names | # file: bin/sh | system.foo="bar" | | bash-5.2# setfattr -x system.foo /bin/sh | bash-5.2# getfattr -d /bin/sh -m- | bash-5.2# This looks perfectly fine, thanks a lot! 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? 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 [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). 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? I wonder whether this could cause trouble in other scenarios (like a read-only fs or actually missing file permissions)? 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?
* Cy Schubert [20230827 16:59]: > On August 27, 2023 12:55:23 PM PDT, Felix Palmen wrote: > >* Dmitry Chagin [20230827 22:46]: > >> On Sun, Aug 27, 2023 at 07:59:32PM +0200, Felix Palmen wrote: > >> > * Dmitry Chagin [20230827 20:54]: > >> > > 1. which fs are you using? > >> > > >> > ZFS. > >> > > >> > > 2. jailed? > >> > > >> > Yes, this is during building ports with poudriere. > >> > > >> > >> I think it's a weird prohibition on changing system namespace extattr > >> attributes, look to comments in extattr_check_cred() > > > >Maybe that's when I should finally start trying to understand the stuff > >in src.git ;) > > > >> I can fix this completely disabling exttatr for jailed proc, > >> however, it's gonna be bullshit, though > > > >Would probably be better than nothing. AFAIK, "Linux jails" are used a > >lot, probably with userlands from distributions actually using xattr. > > > >Cheers, Felix > > > > 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. 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 [20230827 22:46]: > On Sun, Aug 27, 2023 at 07:59:32PM +0200, Felix Palmen wrote: > > * Dmitry Chagin [20230827 20:54]: > > > 1. which fs are you using? > > > > ZFS. > > > > > 2. jailed? > > > > Yes, this is during building ports with poudriere. > > > > I think it's a weird prohibition on changing system namespace extattr > attributes, look to comments in extattr_check_cred() Maybe that's when I should finally start trying to understand the stuff in src.git ;) > I can fix this completely disabling exttatr for jailed proc, > however, it's gonna be bullshit, though Would probably be better than nothing. AFAIK, "Linux jails" are used a lot, probably with userlands from distributions actually using xattr. 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 [20230827 20:54]: > 1. which fs are you using? ZFS. > 2. jailed? Yes, this is during building ports with poudriere. 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 [20230825 19:54]: > To verify, I removed xattr support completely from coreutils (and also > sed) in commit "linuxsrc: Disable usage of xattr" and indeed, with this > change, GNU's install works as it should. I now ran into a second case which makes it very likely the xattr support is indeed the problem. Trying to create a port for python setuptools, calling "setup.py install" with debugging opened showed me this error: #v+ File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/command/install.py", line 706, in run self.run_command(cmd_name) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/cmd.py", line 317, in run_command self.distribution.run_command(command) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/dist.py", line 1217, in run_command super().run_command(command) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/dist.py", line 987, in run_command cmd_obj.run() File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/command/install_egg_info.py", line 42, in run self.execute( File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/cmd.py", line 338, in execute util.execute(func, args, msg, dry_run=self.dry_run) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/_distutils/util.py", line 344, in execute func(*args) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/command/install_egg_info.py", line 63, in copytree unpack_archive(self.source, self.target, skimmer) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/archive_util.py", line 53, in unpack_archive driver(filename, extract_dir, progress_filter) File "/wrkdirs/usr/ports/devel/linuxsrc-setuptools/work/setuptools-63.1.0/setuptools/archive_util.py", line 88, in unpack_directory shutil.copystat(f, target) File "/usr/lib64/python3.11/shutil.py", line 380, in copystat _copyxattr(src, dst, follow_symlinks=follow) File "/usr/lib64/python3.11/shutil.py", line 322, in _copyxattr names = os.listxattr(src, follow_symlinks=follow_symlinks) ^^ PermissionError: [Errno 1] Operation not permitted: 'setuptools.egg-info/top_level.txt' #v- I then rebuilt python passing "ac_cv_header_sys_xattr_h=no" to its configure script, so it thinks there is no sys/xattr.h header. Indeed, this made the problem installing setuptools go away. 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 [20230825 19:54]: > So, hoping for someone with some knowledge how to debug this ;) Information I forgot to add, sorry: I did my tests on an aarch64 machine with a kernel built from a98a0090b2ba64ff0bc3cf71a00fb5f9e31fc1d3. 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
Possible issue with linux xattr support?
Hi all and Dmitry, (CC to Dmitry because he added this linux xattr support in 22dca7acf7756c07d3ccbfdc8dfd10fd9ad3f9cf) I'm currently working on an idea to build a userland for Linuxulator from source here: https://github.com/Zirias/zfbsd-ports/commits/linux Now I ran into an issue with the first port using the full "base" userland for building (I tried expat2 for this): The "install" tool from GNU coreutils was unable to set file permissions, and truss showed me this: | linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation | not permitted' To verify, I removed xattr support completely from coreutils (and also sed) in commit "linuxsrc: Disable usage of xattr" and indeed, with this change, GNU's install works as it should. So, hoping for someone with some knowledge how to debug this ;) Thanks, 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: Problem compiling py-* ports
* Marek Zarychta [20230418 11:41]: > What is the culprit? Most likely some leftovers from older package versions (so it's only a problem when building in the live system. A clean jail won't have the offending files). > Removing blindly all py- packages for all affected > hosts with dependent software is not the best solution. Depending on your situation, it might or might not be faster than trying to identify the exact offending files and just removing them ;) -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --{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: Problem compiling py-* ports
* Filippo Moretti [20230418 08:12]: > File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", > line 31, in > if isinstance(ob, importlib_metadata.MetadataPathFinder) > AttributeError: module 'importlib_metadata' has no attribute > 'MetadataPathFinder' Looks like you're building directly on your host (not in clean jails) and the build picks up "something" that's already installed. I'd probably try to uninstall all python packages, check whether there are leftovers in LOCALBASE/lib/python3.9 (and remove them if necessary) and then do a rebuild. You can avoid this class of issues using poudriere btw... -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --{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: Trying to compile theNVIDIA driver ........ however no ^bsd.sysdir.mk^
* louis.free...@xs4all.nl [20221107 16:21]: > So I downloaded the driver from the NVIDIA site and tried to compile. That … > does not work > > How to fix this!? Use the port: https://www.freshports.org/x11/nvidia-driver/ -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --{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: Good practices with bectl
* Nuno Teixeira [20220921 00:11]: > (...) > maybe: > > yes | make DESTDIR=${BASEDIR} delete-old delete-old-libs Exactly, DESTDIR is used by all the targets. BTW, you can just set BATCH_DELETE_OLD_FILES=yes (either on the command-line or in make.conf) instead of using "yes" here. -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --{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: Error during installkernel
* Filippo Moretti via current [20211026 13:53]: > I tried to update my system today everything fine but installkernel:==> zlib > (install)install -T release -o root -g wheel -m 555 zlib.ko > /boot/kernel/install -T dbg -o root -g wheel -m 555 zlib.ko.debug > /usr/lib/debug/boot/kernel/kldxref /boot/kernelfailed to read > progbitsef_read_entry failed*** Signal 11Stop.make[3]: stopped in > /usr/src/sys/modules*** Error code 1Stop.make[2]: stopped in > /usr/obj/usr/src/amd64.amd64/sys/STING*** Error code 1Stop.make[1]: stopped > in /usr/src*** Error code 1Stop.make: stopped in /usr/src[root@sting > /usr/src]# > > [root@sting /usr/src]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD > 14.0-CURRENT #57 heads/main-n250195-6ba2210ee03: Thu Oct 21 21:19:23 CEST > 2021 filippo@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 Filippo Ignore it. The new kernel should boot anyways, and after installworld, installkernel will finish successfully. It seems kldxref again needs some new feature, but it's not part of the temporary tools built, so the host's (old) kldxref is used. -- Dipl.-Inform. Felix Palmen ,.//.. {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A signature.asc Description: PGP signature
Re: git: "overlay" of own remote-branch on official freebsd-ports repo
* Warner Losh [20211012 10:01]: > 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. +1, I do basically the same. I'd say having a local branch in your local repo is one ot the killer features of git over svn. I just do a few details slightly different, maybe it helps as one possible example. I only fetch 'main' from the official repo and rebase my 'local' branch onto that. During the rebase, it's easy to solve any conflicts with changes in 'main'. You still keep a list of your local commits, well organized. I recently decided to also publish my local branch. So now I just have two remotes on my local ports repo, the official FreeBSD repo and another one on github, looking like this: # git remote -v origin https://github.com/Zirias/zfbsd-ports.git (fetch) origin https://github.com/Zirias/zfbsd-ports.git (push) upstreamhttps://git.freebsd.org/ports.git (fetch) upstreamhttps://git.freebsd.org/ports.git (push) With that and remote branch tracking set up correctly, I just need these commands (I have them in a script) to update from the official repo, rebase and force push to my github repo: git checkout local git fetch upstream main:main && git rebase main git push -f --all BTW, git leaves working copy changes alone if possible, so maybe it's poudriere's way of using git that erases them – just use git directly instead of poudriere. And then, I always hated having random local changes not organized in any way, this quickly grows into a maintenance nightmare, so I'm very thankful I can now easily use git branches instead. -- Dipl.-Inform. Felix Palmen ,.//.. {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A signature.asc Description: PGP signature
Re: Writing large build logs to NFS extremely slow?
* Rick Macklem [20211009 15:35]: > Felix Palmen wrote: > Assuming your NFS performance is acceptable for other things and it > is only this log file that is a problem, then I doubt there is much you > can do to improve it. Yes, that's the only problem I found so far… > --> Append (as in O_APPEND opens) are a poor case for NFS, since there > is no append write in NFS. To approximate append write, it must flush > all dirty data to the server, do a Getattr to find out the file's > current > size and then do the write (over and over and over again). Ok, thanks for the insight here! So maybe, I could have a look at poudriere's code? If I understand you correctly, keeping the file open and just issuing more write() calls wouldn't trigger that problem? > You could try the "nocto" mount option, which might help, if the log file > is being re-opened many times, but I doubt it will help. Well, I take any suggestion, so will try that as well and report back, thanks again! Side note, please don't CC/To me, I'm subscribed the list ;) -- Dipl.-Inform. Felix Palmen ,.//.. {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A signature.asc Description: PGP signature
Re: Writing large build logs to NFS extremely slow?
* Mehmet Erol Sanliturk [20211007 10:42]: > The problem is caused mainly by NFS definition parameters . > > If you study NFS definition parameters one by one , I think you will be > able to find which one is effective . > > My opinion is the one setting is "write directly to disk" , i.e. , "do not > use the cache" . > > In the "write directly to disk" case , without completion of a write , the > computer in use is waiting for completion of previous write operation > before writing a new record . This is useful in case of abrupt program > terminations because every record is written into the disk file , by > consuming more time . Well this is kind of what I assume might be the problem. Could anyone give me a hint what configuration to change on FreeBSD? -- Dipl.-Inform. Felix Palmen ,.//.. {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A signature.asc Description: PGP signature
Writing large build logs to NFS extremely slow?
Hi all, I use a -CURRENT bhyve vm for testing port builds with poudriere. As this vm is only running when needed, but I want to always have access to the build logs, I use NFS to mount /usr/local/poudriere/data/logs from the host. I noticed some few ports take ridiculously long to build while barely using any CPU time at all. On a closer look, that's all ports producing a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, … So I assume appending to a large file via NFS gets slower and slower. Is there any mount option I could try to fix this? Right now I only have `nolockd`, I also tried `noncontigwr` which didn't change anything. Thinking about alternatives to NFS, are there any news for client-side 9p virtfs? I found <https://github.com/swills/virtfs-9p-kmod> which still builds with a few minor adaptions, but trying to mount a 9p share freezes the machine. Would you suggest a different mailing list to ask? BR, Felix -- Dipl.-Inform. Felix Palmen ,.//.. {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A signature.asc Description: PGP signature
Re: Is there any OS builtin git command like svnlite ?
* Guido Falsi via freebsd-current [20210314 21:36]: > The git port has flavors. The full port can be excessive, git@lite looks > good, if one only wants basic functionality there is also git@tiny, but I > don't know what limitations that entails. git@tiny has all options disabled except for curl, which is needed to access http(s) repos. git@lite also has iconv, pcre, git-subtree and git-send-email. So, the tiny flavor is perfectly suitable for cloning and working with the FreeBSD repos. -- Dipl.-Inform. Felix Palmen ,.//.. {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A signature.asc Description: PGP signature
iwn(4) crashing when wlan device is brought up, CA-N-6200
Hi all, I just bought a Centrino Advanced N-6200 mini-pcie card because it should be supported by iwn(4) -- unfortunately it leads to a kernel panic the instant I try to do # ifconfig wlan0 up The creation of wlan0 on top of iwn0 works. Here are the (I hope) most relevant exerpts from core.txt: FreeBSD photon.home.palmen-it.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r275075: Wed Nov 26 11:06:23 CET 2014 r...@photon.home.palmen- it.de:/usr/obj/usr/src/sys/NODEBUG amd64 dmesg: [...] iwn0: Intel Centrino Advanced-N 6200 mem 0xf020-0xf0201fff at device 0.0 on pci1 wlan0: Ethernet address: 00:27:c1:03:a0:89 iwn0: iwn_read_firmware: ucode rev=0x09dd0401 iwn0: iwn_intr: fatal firmware error iwn_fatal_intr: bad firmware error log address 0x iwn0: iwn_panicked: controller panicked, iv_state = 0; resetting... iwn0: iwn_read_firmware: ucode rev=0x09dd0401 iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 iwn0: iwn5000_post_alive: could not configure WiMAX coexistence, error 35 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffe0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x809a300a stack pointer = 0x28:0xfe0107cdda70 frame pointer = 0x28:0xfe0107cddaa0 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 = 0 (iwn0 net80211 taskq) trap number = 12 stacktrace: (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:219 #1 0x80962918 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80962e40 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x80dae65f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x80dae9ac in trap_pfault (frame=0xfe0107cdd9c0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x80dadfce in trap (frame=0xfe0107cdd9c0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x80d90342 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x809a300a in firmware_put (p=0x0, flags=1) at /usr/src/sys/kern/subr_firmware.c:367 #8 0x82638c58 in iwn_init_locked (sc=0xfe0002599000) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:8646 #9 0x82633e3c in iwn_ioctl (ifp=value optimized out, cmd=value optimized out, data=value optimized out) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:4924 #10 0x809b4975 in taskqueue_run_locked (queue=0xf80005efe900) at /usr/src/sys/kern/subr_taskqueue.c:356 #11 0x809b5788 in taskqueue_thread_loop (arg=value optimized out) at /usr/src/sys/kern/subr_taskqueue.c:623 #12 0x8092aa8a in fork_exit ( callout=0x809b56c0 taskqueue_thread_loop, arg=0xfe0001de70f0, frame=0xfe0107cddc00) at /usr/src/sys/kern/kern_fork.c:977 #13 0x80d9087e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #14 0x in ?? () I pasted the complete core.txt here: http://pastebin.com/KipkYx1y Best regards, Felix ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) crashing when wlan device is brought up, CA-N-6200
Hi Adrian, Am Mittwoch, 26. November 2014, 09:27:32 schrieb Adrian Chadd: Oh! Please file a PR for this. Done, https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=195433 This is two problems: * the NIC isn't being setup fully correctly - I'll see if i have an Intel 6200 in my pile-o-nics; * .. and the re-initialise path is slightly broken it seems and it's panicing. :) I thought so, the page fault leading to the panic happens during a re- initialization attempt. A single PR is still ok? I guess further conversation should take place through the PR now ... just in case, if it helps debugging, I could build the kernel with full debugging capabilities and provide the dumped core. Thanks for your reply! BR, Felix ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org