Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 527636

Summary: sys-apps/install-xattr should warn and not die if filesystem doesn't support extended attributes
Product: Gentoo Linux Reporter: Richard Li <admin>
Component: [OLD] Core systemAssignee: Anthony Basile <blueness>
Status: RESOLVED FIXED    
Severity: normal CC: alexander.puchmayr, alexander, base-system, dev-portage, nikoli
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 427888    
Attachments: Add btrfs.* to default PORTAGE_XATTR_EXCLUDE.

Description Richard Li 2014-10-31 16:10:59 UTC
I have a system with sys-apps/portage-2.2.12[xattr] and sys-apps/install-xattr-0.3 installed. Today I found app-emulation/virtualbox-modules-4.3.18 wouldn't install. The error message was as follows:

install-xattr: setxattr() failed: Operation not supported
!!! doins: /usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf does not exist


I looked into the error, and found the cause - something like this:

7362  listxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf", NULL, 0) = 18
7362  listxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf", "btrfs.compression\0", 18) = 18
7362  getxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf", "btrfs.compression", 0x0, 0) = 4
7362  getxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf", "btrfs.compression", "zlib", 4) = 4
7362  setxattr("/home/x/tmp//virtualbox.conf", "btrfs.compression", "zlib", 4, 0) = -1 EOPNOTSUPP (Operation not supported)
7362  write(2, "install-xattr: ", 15)   = 15
7362  write(2, "setxattr() failed", 17) = 17




Apparently, files under my /usr/portage have "btrfs.compression" set, and some of my other filesystems (including /var/tmp/portage) are not btrfs. I feel this should not be a hard error (at least when invoked by portage). Probably install-xattr should provide an option to ignore such errors and portage should use it. (Or just have install-xattr do so by default, if you feel appropriate.)
Comment 1 Anthony Basile gentoo-dev 2014-11-01 12:27:09 UTC
(In reply to Richard Li from comment #0)
> I have a system with sys-apps/portage-2.2.12[xattr] and
> sys-apps/install-xattr-0.3 installed. Today I found
> app-emulation/virtualbox-modules-4.3.18 wouldn't install. The error message
> was as follows:
> 
> install-xattr: setxattr() failed: Operation not supported
> !!! doins:
> /usr/portage/app-emulation/virtualbox-modules/files/virtualbox.conf does not
> exist
> 
> 
> I looked into the error, and found the cause - something like this:
> 
> 7362 
> listxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.
> conf", NULL, 0) = 18
> 7362 
> listxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.
> conf", "btrfs.compression\0", 18) = 18
> 7362 
> getxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.
> conf", "btrfs.compression", 0x0, 0) = 4
> 7362 
> getxattr("/usr/portage/app-emulation/virtualbox-modules/files/virtualbox.
> conf", "btrfs.compression", "zlib", 4) = 4
> 7362  setxattr("/home/x/tmp//virtualbox.conf", "btrfs.compression", "zlib",
> 4, 0) = -1 EOPNOTSUPP (Operation not supported)
> 7362  write(2, "install-xattr: ", 15)   = 15
> 7362  write(2, "setxattr() failed", 17) = 17
> 
> 
> 
> 
> Apparently, files under my /usr/portage have "btrfs.compression" set, and
> some of my other filesystems (including /var/tmp/portage) are not btrfs. I
> feel this should not be a hard error (at least when invoked by portage).
> Probably install-xattr should provide an option to ignore such errors and
> portage should use it. (Or just have install-xattr do so by default, if you
> feel appropriate.)


We can warn but not die on those errors, you're right its not that hard.  But I'm not sure if that's the right course of action here.  You have USE=xattr, which implies end-to-end xattr support.  In other words, if a step along the chain of ebuild phases can't copy xattrs, and you  are asking for xattrs, then the build should die.

Also, are you should that btrfs compression can't support xattrs?

Finally, there's more than just install-xattr that's a problem if you have USE=xattr.  I'm cc-ing the portage team to see if they have an opinion on this.
Comment 2 Zac Medico gentoo-dev 2014-11-01 12:35:46 UTC
Does install-xattr support PORTAGE_XATTR_EXCLUDE? It's probably safe for us to add btrfs.* to the default PORTAGE_XATTR_EXCLUDE. It would be weird for ebuilds to set btrfs.* attributes inside $D.
Comment 3 Anthony Basile gentoo-dev 2014-11-01 16:28:50 UTC
(In reply to Zac Medico from comment #2)
> Does install-xattr support PORTAGE_XATTR_EXCLUDE? It's probably safe for us
> to add btrfs.* to the default PORTAGE_XATTR_EXCLUDE. It would be weird for
> ebuilds to set btrfs.* attributes inside $D.

Yes, it does.

        portage_xattr_exclude = getenv("PORTAGE_XATTR_EXCLUDE");
        if (portage_xattr_exclude == NULL)
                exclude = xstrdup("security.* trusted.* system.nfs4_acl");
        else
                exclude = xstrdup(portage_xattr_exclude);
Comment 4 Zac Medico gentoo-dev 2014-11-01 21:02:11 UTC
Created attachment 388288 [details, diff]
Add btrfs.* to default PORTAGE_XATTR_EXCLUDE.

You can test if this helps by setting the following in make.conf:

PORTAGE_XATTR_EXCLUDE="btrfs.* ${PORTAGE_XATTR_EXCLUDE}"
Comment 5 Zac Medico gentoo-dev 2014-11-02 03:04:37 UTC
(In reply to Zac Medico from comment #4)
> Created attachment 388288 [details, diff] [details, diff]
> Add btrfs.* to default PORTAGE_XATTR_EXCLUDE.

This is in git now:

https://github.com/gentoo/portage/commit/2fcdb5f36face97b4a8ce74831d287bd1dd9c2bf
Comment 6 Anthony Basile gentoo-dev 2014-11-02 20:31:40 UTC
(In reply to Zac Medico from comment #5)
> (In reply to Zac Medico from comment #4)
> > Created attachment 388288 [details, diff] [details, diff] [details, diff]
> > Add btrfs.* to default PORTAGE_XATTR_EXCLUDE.
> 
> This is in git now:
> 
> https://github.com/gentoo/portage/commit/
> 2fcdb5f36face97b4a8ce74831d287bd1dd9c2bf

Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is empty, in the line:

    exclude = xstrdup("security.* trusted.* system.nfs4_acl");
Comment 7 Zac Medico gentoo-dev 2014-11-02 21:39:29 UTC
(In reply to Anthony Basile from comment #6)
>
> Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is
> empty, in the line:
> 
>     exclude = xstrdup("security.* trusted.* system.nfs4_acl");

Well, you should probably only provide defaults as a fallback if it's unset for some reason, and the fallback defaults should include btrfs.*.

Now I realize that I forget to update the fallback defaults inside portage's movefile function. Maybe it's best to remove them, and treat unset PORTAGE_XATTR_EXCLUDE the same as an empty setting.
Comment 8 Anthony Basile gentoo-dev 2014-11-02 22:01:45 UTC
(In reply to Zac Medico from comment #7)
> (In reply to Anthony Basile from comment #6)
> >
> > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is
> > empty, in the line:
> > 
> >     exclude = xstrdup("security.* trusted.* system.nfs4_acl");
> 
> Well, you should probably only provide defaults as a fallback if it's unset
> for some reason, and the fallback defaults should include btrfs.*.
> 
> Now I realize that I forget to update the fallback defaults inside portage's
> movefile function. Maybe it's best to remove them, and treat unset
> PORTAGE_XATTR_EXCLUDE the same as an empty setting.

Okay this will be out in the install-xattr 0.5 when i push it out.
Comment 9 Brian Dolbec (RETIRED) gentoo-dev 2014-11-03 04:12:02 UTC
(In reply to Zac Medico from comment #7)
> (In reply to Anthony Basile from comment #6)
> >
> > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is
> > empty, in the line:
> > 
> >     exclude = xstrdup("security.* trusted.* system.nfs4_acl");
> 
> Well, you should probably only provide defaults as a fallback if it's unset
> for some reason, and the fallback defaults should include btrfs.*.
> 
> Now I realize that I forget to update the fallback defaults inside portage's
> movefile function. Maybe it's best to remove them, and treat unset
> PORTAGE_XATTR_EXCLUDE the same as an empty setting.

That sounds reasonable.  If Anthony agrees, then do it please.
Comment 10 Anthony Basile gentoo-dev 2014-11-03 12:09:48 UTC
(In reply to Brian Dolbec from comment #9)
> (In reply to Zac Medico from comment #7)
> > (In reply to Anthony Basile from comment #6)
> > >
> > > Should I also add "btrfs.*" to exclude in case PORTAGE_XATTR_EXCLUDE is
> > > empty, in the line:
> > > 
> > >     exclude = xstrdup("security.* trusted.* system.nfs4_acl");
> > 
> > Well, you should probably only provide defaults as a fallback if it's unset
> > for some reason, and the fallback defaults should include btrfs.*.
> > 
> > Now I realize that I forget to update the fallback defaults inside portage's
> > movefile function. Maybe it's best to remove them, and treat unset
> > PORTAGE_XATTR_EXCLUDE the same as an empty setting.
> 
> That sounds reasonable.  If Anthony agrees, then do it please.

Sounds good.
Comment 11 Zac Medico gentoo-dev 2014-11-03 21:24:32 UTC
I've posted a portage patch which removes the redundant defaults:

	http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4739
Comment 12 Jeroen Roovers (RETIRED) gentoo-dev 2014-12-21 10:31:46 UTC
*** Bug 533168 has been marked as a duplicate of this bug. ***
Comment 13 Anthony Basile gentoo-dev 2015-08-03 09:04:26 UTC
(In reply to Zac Medico from comment #11)
> I've posted a portage patch which removes the redundant defaults:
> 
> 	http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4739

This has landed in the latest stable portage.  We're done.