Am 22.09.21 um 18:45 schrieb Julian Sikorski:
W dniu 22.09.2021 o 18:42, Julian Sikorski pisze:
> W dniu 22.09.2021 o 18:34, Julian Sikorski pisze:
>> W dniu 21.09.2021 o 23:12, Richard W.M. Jones pisze:
>>> On Tue, Sep 21, 2021 at 10:16:17PM +0200, Julian Sikorski wrote:
>>>> W dniu 21.09.2021 o 11:00, Richard W.M. Jones pisze:
>>>>> On Mon, Sep 20, 2021 at 11:45:39AM -0600, Jerry James wrote:
>>>>>> On Mon, Sep 20, 2021 at 10:49 AM Julian Sikorski
>>>>>> <belegdol(a)gmail.com> wrote:
>>>>>>> my local kernel rebuilds have started failing for no apparent
>>>>>>> reason - I
>>>>>>> was using a similar command successfully for several months.
>>>>>>> /mnt/openmediavault is a samba share. This is what gets
output
>>>>>>> into the log:
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>>
/mnt/openmediavault/kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm:
>>>>>>>
>>>>>>> (39, fsync failed: Permission denied)
>>>>>>
>>>>>> I suspect that ^^^^ is the real problem, and the incorrect
>>>>>> checksum is
>>>>>> a result of not being able to read or write the filesystem. Can
you
>>>>>> verify correct ownership and permissions on every directory in
that
>>>>>> path?
>>>>>
>>>>> If fsync(2) failed then that would be happening after the file
>>>>> descriptor was open, so it wouldn't be filesystem permissions
but
>>>>> probably SELinux.
>>>>>
>>>>> Rich.
>>>>>
>>>>
>>>> I am seeing no errors in setroubleshoot and setting selinux to
>>>> permissive does not help either. Can it be the selinux of the
>>>> bootstrapped instance, and if so, how can I control it? There is
>>>> nothing obvious in the logs of the host:
>>>
>>> AFAIK mock only ever uses one kernel (the host) so disabling SELinux
>>> on the host rules out my SELinux theory.
>>>
>>> Rich.
>>>
>> This is all super strange. If I delete the pesign result dir, it is
>> built without issues. Moreover, repodata folder is also created, with
>> the sha256 checksum in the file matching the one of the pesign rpm.
>> What is odd though, is that even after mock fails, gedit is claiming
>> that repomd.xml and the data file extracted from primary.xml.gz keep
>> changing on disk. Can it be some odd system clock issue between my
>> desktop an my NAS?
>>
>> Best regards,
>> Julian
>
> This "file changed on disk" issue affects every single file in the
> folders the last mock run touched, so e.g.
> /mnt/openmediavault/kernel/results/fedora-34-x86_64/kernel-5.14.6-300.s0ix03.fc34
> is affected, but
> /mnt/openmediavault/kernel/results/fedora-34-x86_64/kernel-5.14.5-300.s0ix01.fc34
> is not. What does gedit use to determine that the file changed?
> Timestamps shown by ls -l stay constant.
>
> Best regards,
> Julian
This is what stat shows:
$ LANG=C stat repomd.xml
File: repomd.xml
Size: 3098 Blocks: 2048 IO Block: 1048576 regular file
Device: 34h/52d Inode: 27918863 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ julas) Gid: ( 1000/ julas)
Context: system_u:object_r:cifs_t:s0
Access: 2021-09-22 18:26:02.683957700 +0200
Modify: 2021-09-22 18:25:59.823561400 +0200
Change: 2021-09-22 18:25:59.823561400 +0200
Birth: 2021-09-22 18:25:59.793960700 +0200
I tried running chronyc makestep on both the NAS and the builder, it did
not help either.
Best regards,
Julian