Re: [OE-core] [PATCH] sanity: Require tar 1.35 or later on rhel9-alike distros

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Paul,

On 4/3/26 2:30 PM, Paul Barker wrote:
> On Fri, 2026-04-03 at 14:06 +0200, Quentin Schulz via
> lists.openembedded.org wrote:
>> Hi Paul,
>>
>> On 4/3/26 1:54 PM, Paul Barker via lists.openembedded.org wrote:
>>> tar 1.34 (and possibly earlier versions) is unable to extract tarballs
>>> containing read-only files with xattrs. This was fixed upstream, but
>>> it's unlikely at this point that the fix will be backported to RHEL9
>>> related distros (CentOS Stream 9, AlmaLinux 9, Rocky Linux 9). The issue
>>> affects these distros specifically because they have selinux enabled by
>>> default and this uses xattrs.
>>>
>>> The specific failure we've seen is with the /usr/lib/udev/hwdb.bin file
>>> installed by the systemd recipe - this file is chmod 0444. This leads to
>>> the following error, typically during do_image_wic (shortened and split
>>> to make it readable):
>>>
>>>       subprocess.CalledProcessError: Command
>>>       'tar --xattrs --xattrs-include='*' -cf - -S -C .../tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/rootfs -p . |
>>>       tar --xattrs --xattrs-include='*' -xf - -C .../tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs2'
>>>       returned non-zero exit status 2.
>>>
>>> That error message is likely to confuse users, and the fix is not
>>> obvious. So, error out if tar 1.34 or earlier is present on affected
>>> distros and recommend upgrading or using the buildtools tarball.
>>>
>>> Signed-off-by: Paul Barker <paul@pbarker.dev>
>>> ---
>>>    meta/classes-global/sanity.bbclass | 15 +++++++++++++++
>>>    1 file changed, 15 insertions(+)
>>>
>>> diff --git a/meta/classes-global/sanity.bbclass b/meta/classes-global/sanity.bbclass
>>> index b5d905399b73..2e486966a93b 100644
>>> --- a/meta/classes-global/sanity.bbclass
>>> +++ b/meta/classes-global/sanity.bbclass
>>> @@ -551,6 +551,21 @@ def check_tar_version(sanity_data):
>>>        except subprocess.CalledProcessError as e:
>>>            return "Unable to execute tar --help, exit code %d\n%s\n" % (e.returncode, e.output)
>>>    
>>> +    try:
>>> +        distro = oe.lsb.distro_identifier()
>>> +    except Exception:
>>> +        distro = None
>>> +
>>> +    if distro:
>>> +        rhel9_alike_prefixes = ("rhel-9", "centos-9", "rocky-9", "almalinux-9")
>>> +        rhel9_tar_minimum_version = "1.35"
>>> +        for prefix in rhel9_alike_prefixes:
>>
>> The commit log doesn't explain why that is specific to centos 9 and
>> derivatives.
>>
>> Did CentOS break tar only for themselves, or is it the only distro with
>> that specific broken tar version or is it the only distro with that old
>> of a version of tar?
>>
>> I'm asking because I am not sure we need to filter on the distro AND we
>> also probably should update the min version of tar listed in
>> documentation/poky.yaml.in in yocto-docs.
> 
> Hi Quentin, thanks for the feedback!
> 
> The issue exists in upstream tar, I'm unsure when it was introduced. It
> was fixed for 1.35 [1].
> 

This is **weird**, because we do have other distros with tar 1.34 and 
they don't seem to be failing (from what I could tell from our bugzilla 
ticket). Debian 12 (bookworm) has it for example according to pkgs.org. 
So either CentOS has a patch for 1.34 that others don't and it breaks 
stuff, or other distros have a patch that CentOS doesn't? I couldn't see 
anything obvious between CentOS-9/Debian-Bookworm so don't know :/

Can you please add this info to the commit log? That we do have other 
distros with 1.34 and they work fine, just the CentOS-9 and its 
derivatives that are failing, hence why we require this only for those 
distros?

Cheers,
Quentin