Re: Possible issue with linux xattr support?
On Tue, Sep 05, 2023 at 07:52:52AM +0200, Felix Palmen wrote:
> * 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.
>
11e37048d
> 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
Re: Possible issue with linux xattr support?
On Tue, Sep 05, 2023 at 07:52:52AM +0200, Felix Palmen wrote: > * 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. > Thank you!
Re: Possible issue with linux xattr support?
On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> 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?
no,
+ if (error == EPERM)
+ break;
mean that listxattr will fail if user is unauthorized to access system
namespace, ie, listxattr will return ENOTSUP
>
> 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 :)
>
nice, thanks
> 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
Re: Possible issue with linux xattr support?
On Mon, Sep 04, 2023 at 04:03:54PM +0200, Felix Palmen wrote:
> * 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.
Thanks for the report,
please, try this: https://people.freebsd.org/~dchagin/lxattr.patch
Don't be surprised, there 2 fixes
>
> 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
Re: Possible issue with linux xattr support?
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: Possible issue with linux xattr support?
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?
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?
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?
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?
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
Re: Possible issue with linux xattr support?
On Tue, Aug 29, 2023 at 03:02:58PM -0400, 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. > Nice, thank you. I'd prefer to disable it by default, like on a host.
Re: Possible issue with linux xattr support?
On Tue, Aug 29, 2023 at 07:02:22PM +0200, Felix Palmen wrote:
> * 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.
>
As expected, the second patch intended to allow access to system
namespace in jailed env.
> 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?
>
fine, thanks. Gnu tools running under unprivileged user will fail, eg
ls, which uses getfattr() to get the posix acl
> 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
Re: Possible issue with linux xattr support?
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.
> 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
Re: Possible issue with linux xattr support?
On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote: > * 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. > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
Re: Possible issue with linux xattr support?
On Sun, Aug 27, 2023 at 09:55:23PM +0200, 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. > It might sense to allow this priv (PRIV_VFS_EXTATTR_SYSTEM) for linux jails by default? What do think, James?
Re: Possible issue with linux xattr support?
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()
I can fix this completely disabling exttatr for jailed proc,
however, it's gonna be bullshit, though
> 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
Re: Possible issue with linux xattr support?
On Sun, Aug 27, 2023 at 07:15:57PM +0200, Felix Palmen wrote:
> * 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
Hi,
1. which fs are you using?
2. jailed?
>
> --
> 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
Re: change in compat/linux breaking net/citrix_ica
On Wed, Apr 26, 2023 at 09:01:00AM +0200, Jakob Alvermark wrote: > Hi, > > > I use net/citrix_ica for work. https://cgit.FreeBSD.org/src/commit/?id=76f8584e49cf7eedaa2e1312593bf46c7225d79a > > After a recent change to -current in compat/linux it no longer works. > The binary just segfaults. > > I have bisected and it happened after this commit: > > commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 > Author: Dmitry Chagin > Date: Sat Apr 22 22:17:17 2023 +0300 > > linux(4): Export the AT_RANDOM depending on the process osreldata > > AT_RANDOM has appeared in the 2.6.30 Linux kernel first time. > > Reviewed by: emaste > Differential Revision: https://reviews.freebsd.org/D39646 > MFC after: 1 month > > sys/compat/linux/linux_elf.c | 3 ++- > sys/compat/linux/linux_mib.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > > If I revert the change, citrix_ica works again. > > > Thanks, > > Jakob Alvermark >
Re: change in compat/linux breaking net/citrix_ica
On Wed, Apr 26, 2023 at 09:01:00AM +0200, Jakob Alvermark wrote: > Hi, > > > I use net/citrix_ica for work. > > After a recent change to -current in compat/linux it no longer works. > The binary just segfaults. > > I have bisected and it happened after this commit: > > commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 > Author: Dmitry Chagin > Date: Sat Apr 22 22:17:17 2023 +0300 > > linux(4): Export the AT_RANDOM depending on the process osreldata > > AT_RANDOM has appeared in the 2.6.30 Linux kernel first time. > > Reviewed by: emaste > Differential Revision: https://reviews.freebsd.org/D39646 > MFC after: 1 month > > sys/compat/linux/linux_elf.c | 3 ++- > sys/compat/linux/linux_mib.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > > If I revert the change, citrix_ica works again. > Hi, thanks, I'll commit fix today after some testing > > Thanks, > > Jakob Alvermark >
Re: Kernel panic on jail start
On Tue, Apr 04, 2023 at 02:31:20AM +0200, Goran Mekić wrote:
> > > > > exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\"
> > > > > >/etc/rc.conf.d/network";
> > > >
> > > > ah, I see where the problem is,
> > > > until its fixed you can try to set compat.linux.use_real_ifnames to 1,
> > > > or
> > > > s/eth0/to some oyhe if name/
> > >
> > > You are correct, that was the problem. Sorry for long delay, but I'm not
> > > the only user of this machine, swap is too little for core dump, I
> > > couldn't
> > > make dumping to ZVOL work nor using USB key as a swap device. I don't
> > > know what I'm doing wrong with the code dumps as it works like a charm
> > > on a laptop. Thank you for looking into this.
> > >
> >
> > Hi, could you please try 7ae0972c7b ?
>
> Hello,
>
> I confirm it works on my machine. Thank you very much for working on
> this with little info I could provide!
Thank you!
>
> Regards,
> meka
Re: Kernel panic on jail start
On Mon, Apr 03, 2023 at 02:08:09PM +0200, Goran Mekić wrote:
> On Fri, Mar 31, 2023 at 12:20:47PM +0300, Dmitry Chagin wrote:
> > On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote:
> > > exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\"
> > > >/etc/rc.conf.d/network";
> >
> > ah, I see where the problem is,
> > until its fixed you can try to set compat.linux.use_real_ifnames to 1, or
> > s/eth0/to some oyhe if name/
>
> You are correct, that was the problem. Sorry for long delay, but I'm not
> the only user of this machine, swap is too little for core dump, I couldn't
> make dumping to ZVOL work nor using USB key as a swap device. I don't
> know what I'm doing wrong with the code dumps as it works like a charm
> on a laptop. Thank you for looking into this.
>
Hi, could you please try 7ae0972c7b ?
> Regards,
> meka
Re: Kernel panic on jail start
On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote:
> Hello,
>
> I get the kernel panic when starting jail. With git bisect I found out
> the offending commit is 0b56641cfcda30d06243223f37781ccc18455bef. After
> reverting it, everything is back to normal. For completeness, this is my
> jail.conf:
>
> network {
> $id = 1;
> $base = /var/jails;
> persist;
> vnet;
> path = "${base}/${name}";
> mount.devfs;
> host.domainname = "example.com";
> host.hostname = "${name}.${host.domainname}";
> vnet.interface = "epair${id}b";
> devfs_ruleset = 8;
> allow.raw_sockets;
>
> mount += "/var/run/reggae ${path}/var/run/reggae nullfs ro 0 0";
>
> exec.prepare = "[ ! -e ${path}/var/run/reggae ] && mkdir
> ${path}/var/run/reggae || true";
> exec.prepare += "ifconfig epair${id}a && ifconfig epair${id}a destroy ||
> true";
> exec.prestart = "ifconfig epair${id} create up group $(echo ${name} | cut
> -b 1-15) || (ifconfig epair${id}a destroy && false)";
> exec.prestart += "ifconfig jails addm epair${id}a";
> exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\"
> >/etc/rc.conf.d/network";
ah, I see where the problem is,
until its fixed you can try to set compat.linux.use_real_ifnames to 1, or
s/eth0/to some oyhe if name/
> exec.start += "/bin/sh /etc/rc";
> exec.stop = "/bin/sh /etc/rc.shutdown";
> exec.poststop = "ifconfig epair${id}a destroy";
> exec.clean;
> exec.consolelog = "/var/log/jails/${host.hostname}";
> }
>
> The jail root is created with bsdinstall disinstall/distfetch and
> 14-CURRENT.
>
> Regards,
> meka
Re: Kernel panic on jail start
On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote:
> Hello,
>
> I get the kernel panic when starting jail. With git bisect I found out
> the offending commit is 0b56641cfcda30d06243223f37781ccc18455bef. After
> reverting it, everything is back to normal. For completeness, this is my
> jail.conf:
>
it would be better to see backtrace at least, thanks
> network {
> $id = 1;
> $base = /var/jails;
> persist;
> vnet;
> path = "${base}/${name}";
> mount.devfs;
> host.domainname = "example.com";
> host.hostname = "${name}.${host.domainname}";
> vnet.interface = "epair${id}b";
> devfs_ruleset = 8;
> allow.raw_sockets;
>
> mount += "/var/run/reggae ${path}/var/run/reggae nullfs ro 0 0";
>
> exec.prepare = "[ ! -e ${path}/var/run/reggae ] && mkdir
> ${path}/var/run/reggae || true";
> exec.prepare += "ifconfig epair${id}a && ifconfig epair${id}a destroy ||
> true";
> exec.prestart = "ifconfig epair${id} create up group $(echo ${name} | cut
> -b 1-15) || (ifconfig epair${id}a destroy && false)";
> exec.prestart += "ifconfig jails addm epair${id}a";
> exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\"
> >/etc/rc.conf.d/network";
> exec.start += "/bin/sh /etc/rc";
> exec.stop = "/bin/sh /etc/rc.shutdown";
> exec.poststop = "ifconfig epair${id}a destroy";
> exec.clean;
> exec.consolelog = "/var/log/jails/${host.hostname}";
> }
>
> The jail root is created with bsdinstall disinstall/distfetch and
> 14-CURRENT.
>
> Regards,
> meka
fresh world
Hi, fresh world, installed today, fails to builds: make[2]: "/home/dchagin/freebsd/Makefile.inc1" line 442: The src.conf WITHOUT_CLEAN option can now be used instead of NO_CLEAN. >>> Deleting stale dependencies... sh /home/dchagin/freebsd/tools/build/depend-cleanup.sh /home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64 0,17 real 0,06 user 0,11 sys -- >>> stage 2.3: build tools -- cd /home/dchagin/freebsd; time env INSTALL="sh /home/dchagin/freebsd/tools/install.sh" TOOLS_PREFIX=/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp PATH=/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp/legacy/usr/sbin:/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp/legacy/usr/bin:/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp/legacy/bin:/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp MAKEFLAGS="-m /home/dchagin/freebsd/tools/build/mk -D NO_CLEAN -j 1 -J 15,16 -m /home/dchagin/freebsd/share/mk" make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 DESTDIR= BOOTSTRAPPING=1400079 BWPHASE=build-tools -DNO_CPU_CFLAGS -DNO_LINT MK_ASAN=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FORMAT=no MK_CLANG_FULL=no MK_LLDB=no MK_RETPOLINE=no MK_SSP=no MK_TESTS=no MK_UBSAN=no MK_WERROR=no build-tools make[2]: "/home/dchagin/freebsd/Makefile.inc1" line 442: The src.conf WITHOUT_CLEAN option can now be used instead of NO_CLEAN. ===> bin/csh (obj,build-tools) cc -o gethost -Wl,-zrelro -pie -L/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp/legacy/usr/lib -ferror-limit=1 -g -fno-common -I. -I/home/dchagin/freebsd/bin/csh -I/home/dchagin/freebsd/contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -fPIE -g -gz=zlib -MD -MF.depend.gethost -MTgethost -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Wno-error=array-parameter -Wno-error=deprecated-non-prototype -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -I/home/dchagin/tmp/obj/home/dchagin/freebsd/amd64.amd64/tmp/legacy/usr/include /home/dchagin/freebsd/contrib/tcsh/gethost.c ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:314 (/home/dchagin/freebsd/lib/libc/gen/tls.c:314) >>> tls.o:(_rtld_free_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:314 (/home/dchagin/freebsd/lib/libc/gen/tls.c:314) >>> tls.o:(_rtld_free_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:315 (/home/dchagin/freebsd/lib/libc/gen/tls.c:315) >>> tls.o:(_rtld_free_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:335 (/home/dchagin/freebsd/lib/libc/gen/tls.c:335) >>> tls.o:(_rtld_allocate_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:335 (/home/dchagin/freebsd/lib/libc/gen/tls.c:335) >>> tls.o:(_rtld_allocate_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:336 (/home/dchagin/freebsd/lib/libc/gen/tls.c:336) >>> tls.o:(_rtld_allocate_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:342 (/home/dchagin/freebsd/lib/libc/gen/tls.c:342) >>> tls.o:(_rtld_allocate_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC >>> defined in /usr/lib/libc.a(tls.o) >>> referenced by tls.c:348 (/home/dchagin/freebsd/lib/libc/gen/tls.c:348) >>> tls.o:(_rtld_allocate_tls) in archive /usr/lib/libc.a ld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC >>> defined
Re: STABLE/13: src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a prototype
On Sat, Feb 11, 2023 at 10:18:52AM +0100, FreeBSD User wrote: > Hello, > > compiling most recent FreeBSD 13-STABLE (as of today) with a custom kernel > with disabled 'an' > driver in the wireless section (nodevice an), compiling kernel now fails with > the error: > > 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] > > How can this be fixed? > git cherry-pick -x 663b174b5b5 > Kind regards, > > oh > -- > O. Hartmann
Re: linsysfs on /usr/src/sys (linsysfs, local)
On Mon, Nov 07, 2022 at 03:03:25AM +, Graham Perrin wrote: > On 29/10/2022 21:30, Graham Perrin wrote: > > > Subject: poudriere jail update from source: syscall.mk does not exist > > > After updating to yesterday's > > aba921bd9e1869dae9ae4cc6e0c048f997401034, I aimed for a routine update > > of the jail that I used for poudriere. > > > > > > poudriere jail -u -J 1 -j main > > … > > ===> lib/libc (install) > > make[5]: "/usr/src/lib/libc/sys/Makefile.inc" line 9: Cannot open > > /usr/src/sys/sys/syscall.mk > > make[5]: Fatal errors encountered -- cannot continue > > make[5]: stopped in /usr/src/lib/libc > > *** Error code 1 > > … > > > bdrewery and others in IRC helped me to realise an offending mount. > > > With linux_enable: YES, > > root@mowa219-gjp4-8570p-freebsd:~ # mount | grep sys > linsysfs on /usr/src/sys (linsysfs, local) > root@mowa219-gjp4-8570p-freebsd:~ # exit > logout > % grep linsysfs /etc/fstab > # linsysfs /compat/linux/sys linsysfs > rw 0 0 > # linsysfs /compat/ubuntu/sys linsysfs > rw,late 0 0 > % > > > After linux_enable: NO and a reboot, > > % sysrc -f /etc/rc.conf linux_enable > linux_enable: NO > % mount | grep sys > % date ; uname -aKU > Wed 2 Nov 2022 19:06:01 GMT > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #24 > main-n258900-aba921bd9e18: Sat Oct 29 14:39:59 BST 2022 > grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > > amd64 1400073 1400073 > % sudo service linux onestart > grahamperrin's password: > kldload: an error occurred while loading module linux. Please check > dmesg(8) for more details. > /etc/rc.d/linux: WARNING: Unable to load kernel module linux > kldload: an error occurred while loading module linux64. Please check > dmesg(8) for more details. > /etc/rc.d/linux: WARNING: Unable to load kernel module linux64 > % mount | grep sys > linsysfs on /compat/linux/sys (linsysfs, local) assume linux_common failsed to load, as for now Linuxulator depends on netlink module on -current. > % sudo sysrc linux_enable="YES" > linux_enable: NO -> YES > % > > > With linux_enable: YES (re-enabled) and a reboot, the clobber of > /usr/src/sys recurred. > > > > Resolved through an OS update on 3rd November: > > % uname -aKU > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25 > main-n259004-2c10be9e06d4: Thu Nov 3 00:14:52 GMT 2022 > grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > > amd64 1400073 1400073 >
Re: FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img fails to boot on Haswell-based laptop.
On Thu, Apr 15, 2021 at 06:04:55PM +0300, Lev Serebryakov wrote: > > I'm trying to install CURRENT > (FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img) > snapshot onto Lenovo Thinkpad T540p, i7-4700 based laptop. > > Kernel traps on boot with "Fatal trap 9" and this stack trace (hand-copied): > > calltrap() > --- trap 0x9 > run_interrupt_driven_config_hooks() > boot_run_interrupt_driven_config_hooks() > mi_startup() > > It is 100% reproducible, and I cannot issue commands to kernel debugger, > keyboard is dead. > > Enabling verbose boot helps, with verbose boot it boots to installer. > > Looks like some race condition. > > Is it known problem? try to boot verbose > > -- > // Lev Serebryakov > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Loading DRM kills computer
пн, 6 мая 2019 г. в 20:55, Hans Petter Selasky : > On 2019-05-06 19:48, Hans Petter Selasky wrote: > > On 2019-05-06 19:20, Thomas Laus wrote: > >> Farias Martinez [aaronfar...@att.net] wrote: > >>> I’m using current on both of my laptop one with the module i915kms > >>> and the other laptop uses radeonkms both work fine without a problem > >>> on my laptop. Which module are you having issues with. > >>> > >> The i915kms on both. > > > > Hi, > > > > Can you try updating the kernel to the latest revision and build DRM > > firmware+kmods from source. Some regression issues were introduced in > > r346645 and were not fixed before r347089, but I cannot see that your > > revision lies between those. > > > > Hi, > > Some sanity checking: > > Kernel sources are in /usr/src > > And latest version DRM module is built from > /usr/ports/graphics/drm-current-kmod ? > > Can you check that /boot/modules gets cleaned after you deinstall > drm-current-kmod and gpu-firmware-kmod (both needs to be rebuilt). > > r347181, dchagin@mordor> sudo pkg info | grep drm ~ drm-current-kmod-4.16.g20190430 DRM modules for the linuxkpi-based KMS components libdrm-2.4.96,1Userspace interface to kernel Direct Rendering Module services dchagin@mordor> dchagin@mordor> sudo kldstat ~ Id Refs AddressSize Name 1 24 0x8020 1d52f18 kernel 21 0x81f53000 11e8 acpi_call.ko 31 0x82021000 12c530 i915kms.ko 41 0x8214e000760d0 drm.ko 54 0x821c5000119f0 linuxkpi.ko 63 0x821d700012f30 linuxkpi_gplv2.ko 72 0x821ea000 4a34 pseudofs.ko 82 0x821ef000 6d8 debugfs.ko dchagin@mordor> works fine ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dblfault panic r277611
2015-01-25 15:06 GMT+03:00 Konstantin Belousov kostik...@gmail.com: On Sat, Jan 24, 2015 at 10:42:45PM +0300, Chagin Dmitry wrote: On Sat, Jan 24, 2015 at 12:35:19PM +0200, Konstantin Belousov wrote: On Sat, Jan 24, 2015 at 12:46:33PM +0300, Chagin Dmitry wrote: Hi, dchagin.static.corbina.net dumped core - see /var/crash/vmcore.7 Sat Jan 24 01:02:20 MSK 2015 FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r277611+c41ef74(lemul): Sat Jan 24 00:53:45 MSK 2015 r...@dchagin.static.corbina.net:/home/rootobj/home/git/head/sys/YOY amd64 panic: double fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: ffs_syncvnode+0x3b0/frame 0xfe033c22bd50 ffs_truncate() at ffs_truncate+0xc6a/frame 0xfe033c22c150 ufs_direnter() at ufs_direnter+0xde5/frame 0xfe033c22c280 ufs_mkdir() at ufs_mkdir+0xb07/frame 0xfe033c22c4a0 Fatal double fault rip = 0x807a8d03 rsp = 0xfe033c228e60 rbp = 0xfe033c229000 cpuid = 5; apic id = 05 panic: double fault cpuid = 5 KDB: enter: panic Reading symbols from /boot/kernel/if_tap.ko.symbols...done. Loaded symbols for /boot/kernel/if_tap.ko.symbols Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. Loaded symbols for /boot/kernel/if_bridge.ko.symbols Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. Loaded symbols for /boot/kernel/bridgestp.ko.symbols Reading symbols from /boot/kernel/usb.ko.symbols...done. Loaded symbols for /boot/kernel/usb.ko.symbols Reading symbols from /boot/kernel/xhci.ko.symbols...done. Loaded symbols for /boot/kernel/xhci.ko.symbols Reading symbols from /boot/kernel/vmm.ko.symbols...done. Loaded symbols for /boot/kernel/vmm.ko.symbols Reading symbols from /boot/kernel/nmdm.ko.symbols...done. Loaded symbols for /boot/kernel/nmdm.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/pseudofs.ko.symbols...done. Loaded symbols for /boot/kernel/pseudofs.ko.symbols Reading symbols from /boot/kernel/linux_common.ko.symbols...done. Loaded symbols for /boot/kernel/linux_common.ko.symbols Reading symbols from /boot/kernel/procfs.ko.symbols...done. Loaded symbols for /boot/kernel/procfs.ko.symbols Reading symbols from /boot/kernel/ukbd.ko.symbols...done. Loaded symbols for /boot/kernel/ukbd.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols #0 doadump (textdump=771179792) at /home/git/head/sys/kern/kern_shutdown.c:262 262 dumptid = curthread-td_tid; (kgdb) #0 doadump (textdump=771179792) at /home/git/head/sys/kern/kern_shutdown.c:262 #1 0x803c1b08 in db_fncall_generic (addr=-2139713712, rv=0xfe032df744a0, nargs=0, args=0xfe032df744b0) at /home/git/head/sys/ddb/db_command.c:568 #2 0x803c17d3 in db_fncall (dummy1=-2185367173664, dummy2=0, dummy3=0, dummy4=0xfe032df745e0 \n) at /home/git/head/sys/ddb/db_command.c:616 #3 0x803c142b in db_command (last_cmdp=0x810fd6a8, cmd_table=0x0, dopager=1) at /home/git/head/sys/ddb/db_command.c:440 #4 0x803c0f9d in db_command_loop () at /home/git/head/sys/ddb/db_command.c:493 #5 0x803c58d9 in db_trap (type=3, code=0) at /home/git/head/sys/ddb/db_main.c:251 #6 0x807cc704 in kdb_trap (type=3, code=0, tf=0xfe032df74cc0) at /home/git/head/sys/kern/subr_kdb.c:654 #7 0x80c94e1d in trap (frame=0xfe032df74cc0) at /home/git/head/sys/amd64/amd64/trap.c:546 #8 0x80c9655f in trap_check (frame=0xfe032df74cc0) at /home/git/head/sys/amd64/amd64/trap.c:645 #9 0x80c691a2 in calltrap () at /home/git/head/sys/amd64/amd64/exception.S:235 #10 0x807cbf15 in breakpoint () at cpufunc.h:63 #11 0x807cbaff in kdb_enter (why=0x80dcd635 panic, msg=0x80dcd635 panic) at /home/git/head/sys/kern/subr_kdb.c:443 #12 0x80769768 in vpanic (fmt=0x80e24597 double fault, ap=0xfe032df74ec0) at /home/git/head/sys/kern/kern_shutdown.c:740 #13 0x80769820 in panic (fmt=0x80e24597 double fault) at
