| View previous topic :: View next topic |
| Author |
Message |
pste
Tux's lil' helper
Joined: 14 Dec 2004
Posts: 106
|
 Posted: Tue Dec 10, 2024 6:32 pm Post subject: [Solved] Only for dev-libs/glib: extended attributes failure |
 |
|
Hi everyone, I've recently got an odd problem that I haven't yet found out what's causing it and I would sincerely appreciate if someone can point me in the right direction to investigate.
What I have is two fairly similar gentoo systems, both intel x86_64 and both on ~arch, both on openrc sporting cinnamon desktops and almost the same set of use flags and both on nvme-drives. The malfunctioning one is a stationary i5-9600K on an AsRock micro ITX motherboard and the working one is an i7-1260P Asus ExpertBook laptop, if that has something to do with it.
Since I while ago, after a regular sync a couple of weeks ago (I usually update at least once a week, often once every day), the stationary i5-system cannot emerge dev-libs/glib (introspection) and therefore neither dev-libs/gobject-introspection any longer. All other packages compile and install just fine! On the ExpertBook also these two packages install as expected.
What happens is (on the AsRock i5, after compilation, during install):
| Quote: | Installing symlink pointing to libgirepository-1.0.so.1 to /var/tmp/portage/dev-libs/glib-2.82.2/temp/usr/lib64/libgirepository-1.0.so
Failed to copy file: _parsed_options=Namespace(group=-1, owner=-1, mode=420, preserve_timestamps=False), source=b'README.rst', dest_dir=b'/var/tmp/portage/dev-libs/glib-2.82.2/image/usr/share/doc/glib-2.82.2'
Traceback (most recent call last):
File "/usr/lib/portage/python3.12/doins.py", line 200, in run
movefile._copyxattr(source, dest, exclude=self._xattr_exclude)
File "/usr/lib/python3.12/site-packages/portage/util/movefile.py", line 99, in _copyxattr
raise OperationNotSupported(
portage.exception.OperationNotSupported: Filesystem containing file '/var/tmp/portage/dev-libs/glib-2.82.2/image/usr/share/doc/glib-2.82.2/README.rst' does not support extended attribute 'security.SMACK64' |
I haven't changed any settings at all, no use flags and no kernel settings are changed, and certainly not any file system attributes. So, what on earth is happening?
I've spent some time comparing system and kernel settings between my two systems, but haven't found anything that could explain the difference in behavior...
So, anyone, any clues?
Best regards,
/pste
Last edited by pste on Fri Dec 20, 2024 2:02 pm; edited 1 time in total |
|
| Back to top |
|
 |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1832
Location: South America
|
| Posted: Tue Dec 10, 2024 7:23 pm Post subject: |
|
|
Are you using simplified mandatory access control?
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pste
Tux's lil' helper
Joined: 14 Dec 2004
Posts: 106
|
| Posted: Tue Dec 10, 2024 9:00 pm Post subject: |
|
|
Well, not intentionally explicit.
Apparently I missed the fact that some smack configs are ENABLED in the MALfunctioning system's kernel, and DISABLED in the kernel of the working system which, by the way, for me seems somewhat counterintuitive.
(How come, that a system with smack support ENabled in the kernel can NOT handle the extended attribute 'security.SMACK'?)
I must have enabled these kernel settings in my older system as a reaction to some emerge message for a package I don't have had reason to install on the working system.
Naturally, I'll try recompile the kernel with these settings DISABLED, hopefully it will work (however, this have to wait a few days..). I'll mark this as closed if it do work, which I'm confident it will!
Thank you @GDH-gentoo for making me look in that corner again!
As a side note: Does anyone have any idea about what package that could have called for enabling smack kernel support?
/pste |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1832
Location: South America
|
| Posted: Tue Dec 10, 2024 10:03 pm Post subject: |
|
|
| pste wrote: | | How come, that a system with smack support ENabled in the kernel can NOT handle the extended attribute 'security.SMACK'? |
It's the filesystem here who lacks support needed by a kernel with Smack enabled.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pste
Tux's lil' helper
Joined: 14 Dec 2004
Posts: 106
|
| Posted: Fri Dec 20, 2024 2:47 pm Post subject: |
|
|
The removal of kernel support for smack obviously did the trick, thanks!
| Quote: | | As a side note: Does anyone have any idea about what package that could have called for enabling smack kernel support? |
It's not very important, but if anyone happens to have the experience of getting an emerge message from some package stating that smack is required, I'd be obliged to become reminded because I can't simply remember why I enabled it, and only on one of my systems...
/pste |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
